Hacker News new | past | comments | ask | show | jobs | submit login
A discretization attack [pdf] (cr.yp.to)
78 points by Kubuxu 37 days ago | hide | past | favorite | 14 comments



Once again, a reminder that for more than a decade, we've been living in a djb monoculture. I fear the day djb is retired (or compromised .... hopefully that hasn't yet happened).


If it brings you some relief, he's a teacher for multiple universities (at the very least one in Chicago and one in Eindhoven). He's passing on his knowledge in this way as well.


This paper is surprisingly accessibly written given the complexities involved and depth of expertise of the author, DJB, who has made great contributions to many fields.

Unfortunately nearly all decision making processes are vulnerable to this kind of attack: processes are never clear, selection criteria always up for debate, and generally people pick a special option to present preferentially.

This generally just leads to suboptimal decision making - we're lucky to have DJB's focus here to improve this one.


I've said it elsewhere, but...

If I were carrying out this attack against NIST, and it had failed up to now (i.e. they chose 'wrong' from my perspective), my next step would surely be to publish something which calls into question the conclusion they came to. This would cause everyone involved to start second guessing, loose confidence in the process, and make it easier to re-mount the attack either now, or in the future.

N.b. I assume this document has been written in good faith and with the best of intentions. It's just hard not to see some contradictions mixed up in there.


"We're susceptible to process attacks" plus "pointing it out might be an attack on the process" is much much better than not being aware of attacks on the process.

Supposing this is DJB attacking the process, well, the other participants can simply find the fly in his ointment, point it out, and stop the attack. It's hard to argue that DJB's paper doesn't represent progress then since we can both, reason about its claims and reason about it being an instance of an attack on the process, whereas prior to this we weren't seriously considering attacks on the process at all.


Interesting... Attacking the standards process. Poor NIST, besieged on all sides. They should just give up on cryptography, they are fatally compromised by their connection to NSA.


This is another reason it's entirely reasonable for people to be concerned about social attacks on software design pipelines (e.g. entryists making social demands on software developers). That sort of thing detracts from serious engineering concerns and can provide cover for weakening or undermining a standard.


One could suggest they were under attack, even breached, but their refusal to reveal details of their analysis suggests a worse conclusion.


Again. Stop us if you've heard this before.

https://www.math.columbia.edu/~woit/wordpress/?p=7045


Very interesting. But one part confuses me. It claims NIST was manipulated via discretization to favor Kyber over NTRU. But when I look at Figure 4.5 (which hasn't been discretized), it seems to say that Kyber is in fact better. Draw a line connecting the Kyber points (open red squares) and a line connecting the NTRU points (solid green circles). The Kyber line is slightly more up and the the left (better).


For perhaps some background behind this paperthere's some lively official discussion here [0] by many participants after the round 3 candidates were announced.

[0] https://groups.google.com/a/list.nist.gov/forum/m/#!forum/pq...



Excellent paper. Aside from the main points, I notice that the key phrase "category theory" is in the abstract, to aid indexing, but there's no category theory here. I don't think djb's unaware of abstract algebra, so I wonder why he chose this otherwise-irrelevant phrase for indexing.


It's not only in the abstract - "category" occurs all over the document. Possibly he's poking fun at category theory/theorists.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: