New RSA API #706

Merged

sjaeckel merged 14 commits from new-rsa-api into develop

2026-04-15 05:27:08 -05:00

sjaeckel commented

2025-11-18 17:24:09 -06:00

(Migrated from github.com)

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

Introduce the RSA API v2. Follow-up of #699 which already contains some comments regarding the new API. ### Checklist  * [x] documentation is added or updated * [x] tests are added or updated

levitte (Migrated from github.com) reviewed

2025-11-18 17:24:09 -06:00

karel-m (Migrated from github.com) reviewed

2026-04-11 15:39:15 -05:00

karel-m (Migrated from github.com) left a comment

I have committed my suggestions as separate commits.

karel-m commented

2026-04-11 15:58:18 -05:00

(Migrated from github.com)

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

sjaeckel (Migrated from github.com) reviewed

2026-04-13 04:20:45 -05:00

sjaeckel (Migrated from github.com) left a comment

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?

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 commented

2026-04-13 11:13:16 -05:00

(Migrated from github.com)

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)

sjaeckel commented

2026-04-14 06:31:18 -05:00

(Migrated from github.com)

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)

hmm, I guess we should think in light of "how would resp. could it work if there was no registry" ... which will be "interesting" ...

In that context I just had a look at #515 again and I'm still in favor of merging that one, but now I'm not so sure anymore whether we should go forward and remove all registries, since as @levitte put it "[...] it does cut away the possibility for more complex systems, where there's a part that needs to be able to find implementations by name [...]", which we currently see here.

Therefore let's keep this as it is now and we will see how it evolves.

> 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) hmm, I guess we should think in light of "how would resp. could it work if there was no registry" ... which will be "interesting" ... In that context I just had a look at #515 again and I'm still in favor of merging that one, but now I'm not so sure anymore whether we should go forward and remove all registries, since as @levitte put it "[...] it does cut away the possibility for more complex systems, where there's a part that needs to be able to find implementations by name [...]", which we currently see here. Therefore let's keep this as it is now and we will see how it evolves.

👍 1