Skip to content
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

Streamlined NTRU Prime: sntrup761 #23

Open
epoberezkin opened this issue Nov 1, 2023 · 5 comments
Open

Streamlined NTRU Prime: sntrup761 #23

epoberezkin opened this issue Nov 1, 2023 · 5 comments

Comments

@epoberezkin
Copy link

We will be adopting it for both remote access protocol and for double ratchet, it's here for now:

https://github.com/simplex-chat/simplexmq/tree/xrcp/cbits
https://github.com/simplex-chat/simplexmq/blob/xrcp/src/Simplex/Messaging/Crypto/SNTRUP761/Bindings.hs

The source code for sntrup761 KEM and for hybrid shared secret construction are from referenced Internet drafts, so we could drop them into crypton if you want. All we did was Haskell bindings and newtypes. That would also help addressing the hack with DRG state, as crypton doesn't make it available, so we have to create closure with atomic access to DRG. If it's in crypton it could use some more efficient locking mechanism (although it probably won't make a huge difference).

@epoberezkin
Copy link
Author

cc @kazu-yamamoto

@kazu-yamamoto
Copy link
Owner

I'm neutral on this.
So,it's up to you.
If you kindly send a PR, I would also like to have test cases for maintenance purposes.

@mouse07410
Copy link

mouse07410 commented Nov 2, 2023

I'd much rather see the NIST-selected algorithms added to and supported by the library.

@epoberezkin
Copy link
Author

epoberezkin commented Nov 10, 2023

@mouse07410 There are some legitimate concerns in relation to NIST selected KEM algorithm:

As much as I can process all the available information, sntrup is the only post-quantum KEM that should be used (and it's used in SSH, btw), and that NIST-selected algorithm as standardised should not be used, at least not until the story gets resolved one way or another.

EDIT: key sizes can vary, of course, but 761 seems to be the correct balance of performance/security for the majority of cases, and it's in public domain / submitted in Internet drafts - so no licensing limitations, like the one selected by NIST has.

@mouse07410
Copy link

mouse07410 commented Nov 10, 2023

As a cryptographer, I respectfully disagree with the above post, and think that most of the info it's based on is, sadly, nothing but FUD.

For example. Say, your RNG is broken or predictable. Is hash of a predictable/known value any less predictable/known?

Re. Patent claims and other "allegations": first, the proponent of that concern has a horse in this race, which might impact his objectivity, just a tiny bit... Second, I've seen claims on NTRU too... Also, there are many other scientists that aren't on NIST payroll - shouldn't it bother you that there's only one, and likely biased, person voicing "legitimate concerns"?

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

No branches or pull requests

3 participants