Skip to content

New RSA API#706

Open
sjaeckel wants to merge 15 commits intodevelopfrom
new-rsa-api
Open

New RSA API#706
sjaeckel wants to merge 15 commits intodevelopfrom
new-rsa-api

Conversation

@sjaeckel
Copy link
Copy Markdown
Member

@sjaeckel sjaeckel commented Nov 18, 2025

Introduce the RSA API v2.

Follow-up of #699 which already contains some comments regarding the new API.

Checklist

  • documentation is added or updated
  • tests are added or updated

@sjaeckel sjaeckel requested review from karel-m and levitte November 18, 2025 23:24
@sjaeckel sjaeckel added this to the next milestone Nov 18, 2025
@sjaeckel sjaeckel force-pushed the new-rsa-api branch 4 times, most recently from 71d72b2 to 9e47b3a Compare November 26, 2025 10:44
sjaeckel and others added 12 commits April 11, 2026 20:07
Update PKCS#1-PSS and RSA APIs that allow passing a separate hash index for
the MGF1 hash.

Signed-off-by: Steffen Jaeckel <s@jaeckel.eu>
Signed-off-by: Steffen Jaeckel <s@jaeckel.eu>
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 <s@jaeckel.eu>
This also:
a) deprecates the old RSA and PKCS#1 API.
b) reverts the changes done to them in order to make the now deprecated API
   compatible again with the last release.

The fixes commit mentioned below 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 <s@jaeckel.eu>
Copy link
Copy Markdown
Member

@karel-m karel-m left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have committed my suggestions as separate commits.

@karel-m
Copy link
Copy Markdown
Member

karel-m commented Apr 11, 2026

The updated version with my changes not only passes all libtomcrypt tests, but also my perl CryptX test suite.

@karel-m karel-m marked this pull request as ready for review April 11, 2026 21:44
Copy link
Copy Markdown
Member Author

@sjaeckel sjaeckel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a lot for picking this up and working on it! Very much appreciated :)

For now just one question regarding your latest changes.

Why the switch back to the resolved index instead of using the hash name? I like the string-based "way of working" a bit better nowadays, even though it complicates the internal implementation a bit. (Which could certainly be improved by some nifty helpers.)

I still hope we get rid of the descriptors at one point, so I thought we could already future-proof the implementation, but maybe there's another reason I'm not aware of?

@karel-m
Copy link
Copy Markdown
Member

karel-m commented Apr 13, 2026

ad hash idx vs hash name - it's just that I didn't like those extra round-trips name>>idx>>name (I have no problem with reverting it)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants