Live data from Hacker News

Debunking NIST's calculation of the Kyber-512 security level

blog.cr.yp.to

171–180 of 219 posts

Re: Debunking NIST's calculation of the Kyber-512 security level

#171
post #16

That's more of a diary than an article -- jargony, disorganized, running in circles, very hard to follow. But the information might be important regardless. There's a strong implication that NIST with help of the NSA intentionally standardized on a weak algorithm. We all know that's possible. But can someone who follows some of this stuff more closely explain what the play would be? I always assumed that weakening pu…

The general idea would be that they get a few years out of it before other nation/state factions discover it. The theory behind it is called “kleptography”, because the NSA is deluded enough to think that you can steal information “securely”.

Re: Debunking NIST's calculation of the Kyber-512 security level

#172
post #36

Earlier quoted context omitted.

Correct me if I'm wrong, everything is also being done out in the open for everyone to see. The NIST aren't using some secret analysis to make any recommendations.

> everything is also being done out in the open for everyone to see Well, everything apart from the secret stuff: "I filed a FOIA request "NSA, NIST, and post-quantum cryptography" in March 2022. NIST stonewalled, in violation of the law. Civil-rights firm Loevy & Loevy filed a lawsuit on my behalf. That lawsuit has been gradually revealing secret NIST documents, shedding some light on what was actually going on behi…

Thing is... no lawsuit will ever reveal documents directly against the USA's national interest.

Every single document will be reviewed by a court before being opened up, and any which say "We did this so we can hoodwink the public and snoop on russia and china" won't be included.

Re: Debunking NIST's calculation of the Kyber-512 security level

#173
post #136

> Discovering the secret workings of NISTPQC. I filed a FOIA request "NSA, NIST, and post-quantum cryptography" in March 2022. NIST stonewalled, in violation of the law. Civil-rights firm Loevy & Loevy filed a lawsuit on my behalf. As much as I generally loathe djb personally, professionally he will always have my support as he’s been consistently willing to take the federal government to task in court. It brings me…

Why do you dislike him personally?

Might be because he’s a bit of a “Linus” in crypto with the same ego and temper.

However, the man has done so much to advance privacy and cryptography I think he’s earned the right to be a bit snippy, especially when he’s discussing something so complex 99% of the comments are “too long to read” and “I read it but I still don’t understand it”.

Re: Debunking NIST's calculation of the Kyber-512 security level

#174
I'm not sure N(IST)SA has any credibility left. Polularity of curve 25519 over their P curves is encouraging and it would be great to see the community continue this direction and largely ignore them going forward. The government shouldn't be leading or deciding, it would be better organized around gathering current consensus and following when it comes to FIPS, regulation, etc.

Re: Debunking NIST's calculation of the Kyber-512 security level

#175
post #115

Earlier quoted context omitted.

Re: BLAKE2, I'm not sure it's fair to say that BLAKE2 is more widely used overall. But I do agree BLAKE2 is a bit of an outlier in terms of adoption. I think part of the reason is that SHA2 remains the go-to option, else I'd expect the ecosystem to consolidate around SHA3. Re: Serpent, there are many things to unpack here but, in summary, you don't know a priori how large of a security margin you need (given the prim…

> I'm not sure it's fair to say that BLAKE2 is more widely used overall Ah, maybe my experience is biased then. I keep coming across BLAKE2 implementations, but rarely hear so much as people considering to use SHA-3 somewhere. If anyone has actual numbers on this, that would be interesting. It would be good if SHA-3 is being used because then chip makers have a reason to bake it into their hardware, which is exactly…

> I didn't see actual benchmarks, but Serpent sounds at least three times slower than Rijndael

You can read the original report on the candidates: https://nvlpubs.nist.gov/nistpubs/jres/106/3/j63nec.pdf

To save you some time, one software evaluation is on page 531. Serpent performs worse in software than Rijndael (AES) just about everywhere (note they use categories rather than precise metrics, but you can dig into that if you want). By contrast, one hardware evaluation is on page 539. Serpent has the highest throughput for the lowest "area" i.e. required. These results repeat on p541.

So it depends on whether you are comparing a software or hardware implementation.

Re: Debunking NIST's calculation of the Kyber-512 security level

#176
post #16

That's more of a diary than an article -- jargony, disorganized, running in circles, very hard to follow. But the information might be important regardless. There's a strong implication that NIST with help of the NSA intentionally standardized on a weak algorithm. We all know that's possible. But can someone who follows some of this stuff more closely explain what the play would be? I always assumed that weakening pu…

Why the overwhelming benefit of the doubt in an organization that has repeatedly failed expectations? I don't understand why this is even a conversation. We don't need them any more. Export restrictions are gone. What we need is a consortium to capture the attention of the hardware vendors and limit NIST and the NSA to participant status. Then if the government decides to adopt their backdoored standards, they're the only ones.

Re: Debunking NIST's calculation of the Kyber-512 security level

#177
post #113

Earlier quoted context omitted.

Edit: Just realized the author is djb, Daniel Bernstein, which I guess is semi-ironic for me because I was recently praising him on HN for an old, well-read blog post on ipv6. Thus, I guess I may take back a bit of what I said below, or least perhaps it would be better to say that I can better understand the adversarial tone given djb's history with NIST recommendations (more info at https://en.wikipedia.org/wiki/Dan…

> I know people love to harp on "the Internet has killed our attention spans" Not just that. Give your parent or grandparent a 75-page booklet to read, full of accusations and snark, and let's say it's about something they care about and actually impacts their lives (maybe a local government agency, idk). What are the odds they are going to read that A-Z versus waiting for a summary or call-to-action to be put out? T…

People read it because of djb’s reputation. I’m the future, when someone smarter than you writes something it might benefit you to put aside your tone scolding and receive the information. It might be important.

Re: Debunking NIST's calculation of the Kyber-512 security level

#178

Earlier quoted context omitted.

> everything is also being done out in the open for everyone to see Well, everything apart from the secret stuff: "I filed a FOIA request "NSA, NIST, and post-quantum cryptography" in March 2022. NIST stonewalled, in violation of the law. Civil-rights firm Loevy & Loevy filed a lawsuit on my behalf. That lawsuit has been gradually revealing secret NIST documents, shedding some light on what was actually going on behi…

Thing is... no lawsuit will ever reveal documents directly against the USA's national interest. Every single document will be reviewed by a court before being opened up, and any which say "We did this so we can hoodwink the public and snoop on russia and china" won't be included.

> any which say "We did this so we can hoodwink the public and snoop on russia and china" won't be included

Ever since Snowdon we know it's actually "hoodwink the public and snoop on the public"

Russia and China are just an excuse.

Re: Debunking NIST's calculation of the Kyber-512 security level

#179
post #111
post #67

The unfortunate reality of this is that while he may be right , it is difficult to classify the responses (or non-response) from the NIST people as deceptive vs just not wanting to engage with someone coming from such an adversarial position. NIST is staffed by normal people who probably view aggressively worded requests for clarification in the same way that most of us have probably fielded aggressively worded bug r…

This is 100% in line my reading of the submission. Also noting that the page contains seventeen thousand words . That many words of harry potter take an average person 70 minutes to read. This text is no harry potter: it's chock-full of numbers, things to consider, and words and phrasings to weigh (like when quoting NIST), so you're not going to read it as fast as an average book, if you know enough about PQC to unde…

HN readers that don't want to read the piece in full can take solace in that PQC has not been proven viable. Thus, what algorithms we should use to protect ourselves once what we thought was intractable becomes tractable may be a moot point. Shor's algorithm is capable of factoring 21 into 7 x 3. That's a long way off from factoring the thousands of digits-long numbers used for modern cryptography.

Re: Debunking NIST's calculation of the Kyber-512 security level

#180
post #114

Earlier quoted context omitted.

I do know a few cryptographers who were suspicious of SHA-3 when it came out, but after some napkin math and no obvious hole was found, they were fine with it. The actual goal of that extra padding was to get extra one bits in the input to avoid possible pathological cases. My understanding of the Dual-EC problem may be different than yours. As I understand it, the construction is such that if you choose the two cons…

Even with a verifiably random key, Dual EC is still unacceptable. First, because its output has unacceptable biases [1,2]. Second, because its presence allows an attacker to create a difficult-to-detect backdoor simply by replacing the key, as apparently happened with Juniper NetScreen devices [3,4]. --- [1] Kristian Gjøsteen, Comments on Dual-EC-DRBG/NIST SP 800-90, draft December 2005. Online: https://web.archive.o…

> Even with a verifiably random key

What's a "verifiably random" key?

Post reply on HN