Some improvements #699
Some improvements #699
Conversation
Signed-off-by: Steffen Jaeckel <[email protected]>
Signed-off-by: Steffen Jaeckel <[email protected]>
Signed-off-by: Steffen Jaeckel <[email protected]>
To be able to do a bit more, add an optional handler callback function. Additional to that, also make it possible to mark elements as optional. Signed-off-by: Steffen Jaeckel <[email protected]>
(and you should do that too) Signed-off-by: Steffen Jaeckel <[email protected]>
Signed-off-by: Steffen Jaeckel <[email protected]>
Update PKCS#1-PSS and RSA APIs that allow passing a separate hash index for the MGF1 hash. Signed-off-by: Steffen Jaeckel <[email protected]>
Signed-off-by: Steffen Jaeckel <[email protected]>
Signed-off-by: Steffen Jaeckel <[email protected]>
Signed-off-by: Steffen Jaeckel <[email protected]>
Slightly minimize both space and time when importing a
SubjectPublicKeyInfo. Time for ECC keys stays the same.
Those tests were done with X.509 support already available, but later these
commits were split up to be independent of the X.509 feature.
Running the entire set of pem files through `x509_verify` via [0]
resp. the timing app via [1] resulted in the following data:
Before this patch:
[0]
```
==1031519== HEAP SUMMARY:
==1031519== in use at exit: 0 bytes in 0 blocks
==1031519== total heap usage: 424,057 allocs, 424,057 frees, 73,527,730 bytes allocated
```
[1]
```
x509 cert-rsa-pss.pem : 50021 cycles
x509 LTC_CA.pem : 10335 cycles
x509 LTC_S0.pem : 47284 cycles
x509 LTC_SS0.pem : 36687 cycles
x509 secp384r1.pem : 1985416 cycles
x509 secp521r1.pem : 3287773 cycles
x509 LTC_SSS0.pem : 25086 cycles
x509 secp224r1.pem : 775807 cycles
```
After this patch:
[0]
```
==1043548== HEAP SUMMARY:
==1043548== in use at exit: 0 bytes in 0 blocks
==1043548== total heap usage: 337,244 allocs, 337,244 frees, 65,047,463 bytes allocated
```
[1]
```
x509 cert-rsa-pss.pem : 32568 cycles
x509 LTC_CA.pem : 5478 cycles
x509 LTC_S0.pem : 36093 cycles
x509 LTC_SS0.pem : 23351 cycles
x509 secp384r1.pem : 1984030 cycles
x509 secp521r1.pem : 3303396 cycles
x509 LTC_SSS0.pem : 13220 cycles
x509 secp224r1.pem : 781534 cycles
```
[0] find tests/x509 -name '*.pem' -exec valgrind --leak-check=full --show-leak-kinds=all './x509_verify' {} \+
[1] ./timing x509
Signed-off-by: Steffen Jaeckel <[email protected]>
|
I have just quickly changed the libtomcrypt in my CryptX perl bindings for the branch "some-improvements" from this PR. It failed to build (which is probably expected) https://github.com/DCIT/perl-CryptX/actions/runs/18219248768/job/51875345151 I will try to adopt CryptX to the new changes (after that we will see whether CryptX test suite reveals something). |
sjaeckel
force-pushed
the
some-improvements
branch
from
7d89cda to
24f8a2f
Compare
Signed-off-by: Steffen Jaeckel <[email protected]>
... in order of likelihood of usage and/or strength. Signed-off-by: Steffen Jaeckel <[email protected]>
Only go once through `hash_descriptor[]` when calling `register_hash()` Signed-off-by: Steffen Jaeckel <[email protected]>
Before this patch it silently didn't work, now it errors out. Signed-off-by: Steffen Jaeckel <[email protected]>
Signed-off-by: Steffen Jaeckel <[email protected]>
Signed-off-by: Steffen Jaeckel <[email protected]>
The NULL is optional. Signed-off-by: Steffen Jaeckel <[email protected]>
Signed-off-by: Steffen Jaeckel <[email protected]>
sjaeckel
force-pushed
the
some-improvements
branch
from
24f8a2f to
787e5c1
Compare
Cool, thanks!
If I'm not mistaken there are two errors [148] ff. is already caused by #524 [187] ff. is indeed caused by the API change of Both are expected, so thanks already in advance for fixing this in CryptX and testing those changes [148] https://github.com/DCIT/perl-CryptX/actions/runs/18219248768/job/51875345151#step:7:149 |
|
I have updated my perl bindings and it seems to work fine. Just one minor suggestion: please add |
I've reordered and refactored some of the commits of #697 in order to limit its scope and simplify the merge and a potential faster release of 2.0
With these changes merged I currently don't see any planned ABI or API breakage (besides #515, but that's an entirely different discussion).
This should be the last PR with intentional changes before a v2.0.0-rc1, c.f. #568