2019.04.07 19:14:19 (1114939473341685761) from Daniel J. Bernstein, replying to "Kostas Kryptos (@kostascrypto)" (1114717968909234177):
There's always pressure on these projects to support more cryptographic functions; I'll be the first to agree that we need some post-quantum functions. To allocate verification effort sensibly, one has to understand how the cost of verification depends on the choice of function.
2019.04.07 19:28:35 (1114943061107400709) from Daniel J. Bernstein:
Regarding pre-quantum ECC, the issue isn't that implementations of the NSA primes, NSA curves, etc. are impossible to verify. It's that they're unnecessarily difficult---and of no real value for end users. Meanwhile more important projects are in desperate need of verification.
2019.04.06 13:17:53 (1114487386191343617) from Daniel J. Bernstein:
Another example of how easy it's becoming to deploy cryptographic software formally verified to be bug-free: https://www.microsoft.com/en-us/research/blog/evercrypt-cryptographic-provider-offers-developers-greater-security-assurances/ As in NaCl, the only public-key option is ECC, and the only curve is Curve25519. Asking for RSA-2048 for "algorithm agility" = asking for bugs.
2019.04.06 13:32:43 (1114491119763693568) from Daniel J. Bernstein:
It's unfortunate that Microsoft's EverCrypt advertising doesn't highlight the impact of design choices in cryptographic functions. (They even pick a picture with special cases that 25519 eliminates!) This is even more important for verifying more complex post-quantum software.
2019.04.07 04:34:08 (1114717968909234177) from "Kostas Kryptos (@kostascrypto)":
hm... but they still mention “we plan to support NIST P curves”