I know someone in this field and sent him this article. He said the “NIST isn’t being transparent” claim isn’t true
https://tsapps.nist.gov/publication/get_pdf.cfm?pub_id=927303 https://nvlpubs.nist.gov/nistpubs/ir/2020/NIST.IR.8309.pdf https://tsapps.nist.gov/publication/get_pdf.cfm?pub_id=934458
He also responded with “of course the NSA would try and mess with it, but if it’s peer reviewed properly I don’t see how they would be successful”
We know for a fact that they have done it in the past and managed to hide it until it was too late, what makes you think they can’t do it again?
peer reviewed properly
Is the important bit here. The timeline from that Wikipedia article shows it was published in 2005 and work disproving it’s claim came around in 2006.
If a scientists work is retracted it really kills any more funding they receive. They use examples like the DRBG one as what not to be.
Did you send him Bernstein’s original blog post?
https://blog.cr.yp.to/20231003-countcorrectly.html
Unless he’s just making all of this up, it does seem pretty damning. I would love to see an in-depth rebuttal.
Yeah you can observe this with letsencrypt failing to generate a certificate if you change the elliptic curve from an NSA generated curve to a generic/known safe one. Changing between different NSA curves are functionally fine. Forces all signed certificates to use curves that are known to have issues, deliberate or otherwise - i.e. backdoored.
That’s worrying if true. However I couldn’t find a source. Even if true Let’s encrypt is probably the most secure option
You can’t use arbitrary curves with certificates, only those which are standardized because the CA will not implement anything which isn’t unambiguously defined in a standard with support by clients.
My point is that there is a documented listed of supported curves for ECDSA but attempting to use any other safe curve in the list results in a failure. I am not trying to use some arbitrary curve.
If your point is that no safe curve is permitted because the powers that be don’t permit it, TLS is doomed.
https://eff-certbot.readthedocs.io/en/latest/using.html#using-ecdsa-keys
The default is a curve widely believed to be unsafe, p256, with no functioning safe alternative.
That’s Bernstein’s website if anyone was wondering, showing p256 is unsafe.
I run a cryptography forum, I know this stuff, and the problem isn’t algorithmic weakness but complexity of implementation.
All major browsers and similar networking libraries now have safe implementations after experts have taken great care to handle the edge cases.
It’s not a fault with let’s encrypt. If they allowed nonstandard curves then almost nothing would be compatible with it, even the libraries which technically have the code for it because anything not in the TLS spec is disabled.
https://cabforum.org/baseline-requirements-certificate-contents/
CAB is the consortium of Certificate Authorities (TLS x509 certificate issuers)
With that said curve25519 is on its way into the standards
Can you elaborate on this? Which curves does it happen with? Is there some source that you’ve seen?
Before, elliptical curve encryption has been hailed as the new golden standard, only too bad there is a serious weakness where if you know the seed you can crack the code. And guess who has the seed? Starts with N and ends with SA.
And here I thought it was the National Emergency Services Academy.
#Bitcoin
Interesting article and discussion.
The way Signal is addressing post-quantum encryption is by layering Crystals-KYBER over their current encryption. I initially thought it was overkill, but it’s a great decision.