Skip to content

Add TurboSHAKE XOF functions. #692

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

Open
wants to merge 2 commits into
base: develop
Choose a base branch
from

Conversation

MarekKnapek
Copy link

@MarekKnapek MarekKnapek commented Jun 4, 2025

TurboSHAKE128 and TurboSHAKE256 as described in https://keccak.team/files/TurboSHAKE.pdf.

#691

Checklist

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

@levitte
Copy link
Collaborator

levitte commented Jun 12, 2025

That PDF refers to https://datatracker.ietf.org/doc/draft-irtf-cfrg-kangarootwelve/, which also describes the algo, and provides test vectors. Might I suggest adding some tests, based on those test vectors?

@sjaeckel
Copy link
Member

And TBH I'd prefer to have this only merged once the RFC is finalized.
I've been burned too often by standards changing in some future version before release.

@MarekKnapek
Copy link
Author

I updated my branch, I added some unit tests. Regarding the standard being in draft stage. It seems to be draft since 2019-08-06 until 2025-02-21 and continuing to be draft until today, not sure what changed in the meantime. How would you like to continue? I have few ideas:

  • Keep the TurboSHAKE functions in the library, but behind some #ifdef that clearly communicates to the user that this feature is "beta" or "standard not finished yet" and that it might change in the future or something like that.
  • Do not add this functionality to your product until the RFC standardization is done. (You seem to like this approach.)
  • Add this functionality to your product and if it breaks in the future, say to your customers "bad luck" your problem using unfinished standard, not mine. (You seem to don't like this approach.)
  • Any more ideas?

@levitte
Copy link
Collaborator

levitte commented Jun 14, 2025

I could go with having this as an unstable feature, only to be enabled on demand... especially if libtomcrypt already have infrastructure for that sort of thing (er, I forget if it has). If that ends up too hard, I'd go with keeping this PR as is until the standard is finalized.

I was a bit involved in the addition of TLS 1.3 in OpenSSL, and we did hold off a release with that until the RFC was actually published... and we did see some changes very late in the RFC process. So that is to say, there's quite some precedence to @sjaeckel's worries.

@sjaeckel
Copy link
Member

Thanks for adding the tests and thanks for your input!

So a long lived PR this will be, until cfrg comes to a conclusion ...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants