-
Notifications
You must be signed in to change notification settings - Fork 484
Some improvements #699
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: develop
Are you sure you want to change the base?
Some improvements #699
Conversation
|
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). |
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 |
5b5fec8 to
c760347
Compare
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]>
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 `X_descriptor[]` when calling `register_X()` 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]>
|
FYI current branch |
* The oldest supported Ubuntu Version is 22.04 which comes with CMake 3.22. * Refactor demos/CMakeLists.txt to set the list of binaries only once. Signed-off-by: Steffen Jaeckel <[email protected]>
This reverts commit 93f5348. You should use the CMake flag `-DCMAKE_CXX_COMPILER_LAUNCHER=ccache` instead. Sibling-to: libtom/libtommath#577 Signed-off-by: Steffen Jaeckel <[email protected]>
This closes #354 Signed-off-by: Steffen Jaeckel <[email protected]>
Change the default behavior of `LTC_ARGCHK()` for Release, resp. Release+Shared Library builds to be non-fatal. This closes #458 Signed-off-by: Steffen Jaeckel <[email protected]>
Fixes #700 Signed-off-by: Steffen Jaeckel <[email protected]>
One can now define them on a per-case basis to disable them. Signed-off-by: Steffen Jaeckel <[email protected]>
7ff585a to
3f05dbf
Compare
Signed-off-by: Steffen Jaeckel <[email protected]>
3f05dbf to
747b9c1
Compare
it is a segfault (memory corruption) related to |
hmm At least the tests can't reproduce it for AARCH64 with Qemu ... |
|
on cywin it fails inside |
|
The fix DCIT/perl-CryptX@cccc52b now passes tests also on cygwin + arm |
It expects a pair of type `(unsigned char*,unsigned long)` and not `(unsigned char*,unsigned int)`. Fixes: 46fa363 ("Finish up RFC6979 ECDSA keygen") Reported-via: #699 (comment) ff. Signed-off-by: Steffen Jaeckel <[email protected]>
Thanks for triaging it and proposing the fix. Seeing it like that it's obvious now ...
The last patch should be an equivalent solution to your proposed fix, could you please check again? |
checked, it is good |
This also: a) deprecates the old RSA and PKCS#1 API. b) reverts the changes done to them in order to make them API compatible again with the last release. The fixes commit mentioned is the testcase for the Bleichenbacher attack, which works now again as expected. Fixes: 9d03c38 ("add flags to `der_decode_sequence()`") Signed-off-by: Steffen Jaeckel <[email protected]>
4e9ce08 to
4ed864a
Compare
Signed-off-by: Steffen Jaeckel <[email protected]>
Signed-off-by: Steffen Jaeckel <[email protected]>
```
src/ciphers/aes/aesni.c:150:7: warning: Value stored to 'temp' is never read [deadcode.DeadStores]
150 | temp = temp_invert(rk);
| ^ ~~~~~~~~~~~~~~~
1 warning generated.
```
Signed-off-by: Steffen Jaeckel <[email protected]>
This can be disabled by defining `LTC_NO_AES_NI`. Signed-off-by: Steffen Jaeckel <[email protected]>
Fixes: fe8e4bf ("Use more builtin functions if available") Signed-off-by: Steffen Jaeckel <[email protected]>
With `LTC_FAST` enabled test to read from different offsets. Signed-off-by: Steffen Jaeckel <[email protected]>
Signed-off-by: Steffen Jaeckel <[email protected]>
4ed864a to
b78da6e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you're fine with those latest changes [0] I'll add the same macro trickery for the deprecated RSA APIs as well, properly deprecate all the remaining APIS, and then we'll only have to update the docs...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any comments on the new RSA API?
| unsigned long lparamlen; | ||
| } crypt; | ||
| /* let's make space for potential future extensions */ | ||
| ulong64 dummy[8]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would allow us to extend functionality without breaking API&ABI in the future.
Is this really necessary for RSA?
Should some ECC struct get something like that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've searched through GH and couldn't find anyone using those APIs, so I thought we can simply remove them resp. make them private. People can still speak up and the deprecation can be reverted in the future.
Fine like that?
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