paper "A discretization attack", specifically Section 5, for various concrete examples of mysteries regarding the NIST process.
https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/Jbgap-eOVSo https://cr.yp.to/papers/categories-20200918.pdf https://eprint.iacr.org/2020/1370 A discretization attack Daniel J. Bernstein Abstract This paper presents an attack against common procedures for comparing the size-security tradeoffs of proposed cryptosystems. The attack begins with size-security tradeoff data, and then manipulates the presentation of the data in a way that favors a proposal selected by the attacker, while maintaining plausible deniability for the attacker. As concrete examples, this paper shows two manipulated comparisons of size-security tradeoffs of lattice-based encryption proposals submitted to the NIST Post-Quantum Cryptography Standardization Project. One of these manipulated comparisons appears to match public claims made by NIST, while the other does not, and the underlying facts do not. This raises the question of whether NIST has been subjected to this attack. This paper also considers a weak defense and a strong defense that can be applied by standards-development organizations and by other people comparing cryptographic algorithms. The weak defense does not protect the integrity of comparisons, although it does force this type of attack to begin early. The strong defense stops this attack. https://news.ycombinator.com/item?id=24520781 A discretization attack [pdf] (cr.yp.to) 78 points by Kubuxu on Sept 18, 2020 | hide | past | favorite | 14 comments beagle3 on Sept 18, 2020 | next [–] 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). Fnoord on Sept 19, 2020 | parent | next [–] 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. vii on Sept 18, 2020 | prev | next [–] 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. bem94 on Sept 18, 2020 | prev | next [–] 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. cryptonector on Sept 18, 2020 | parent | next [–] "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. jeffrallen on Sept 18, 2020 | prev | next [–] 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. centimeter on Sept 18, 2020 | parent | next [–] 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. ncmncm on Sept 18, 2020 | parent | prev | next [–] One could suggest they were under attack, even breached, but their refusal to reveal details of their analysis suggests a worse conclusion. imglorp on Sept 18, 2020 | root | parent | next [–] Again. Stop us if you've heard this before. https://www.math.columbia.edu/~woit/wordpress/?p=7045 Thorrez on Sept 19, 2020 | prev | next [–] 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). DarthGhandi on Sept 19, 2020 | prev | next [–] 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... Sniffnoy on Sept 19, 2020 | parent | next [–] Non-mobile link: https://groups.google.com/a/list.nist.gov/forum/#!forum/pqc-... Kednicma on Sept 18, 2020 | prev [–] 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. kurlberg on Sept 18, 2020 | parent [–] It's not only in the abstract - "category" occurs all over the document. Possibly he's poking fun at category theory/theorists.