2 ms·
current crypto is not stable. at all. challenges for new standards are underway, AEAD standardization is relatively new, ECC is no longer quantum proof, we sti
by Luker88 6y ago
current crypto is not stable. at all.
challenges for new standards are underway, AEAD standardization is relatively new, ECC is no longer quantum proof, we still have no definite idea on lattice and so on.
Even CHAHCA has multiple evolutions.
DJB, famous and influential cryptographer worked on MinimaLT, a protocol that only uses one primitive and has no negotiation. go check how widespread it is, then think on your ability to convince the world on how good your choice is.
> one just can not keep support for broken clients, however practical it is to update them
In an ideal world I would agree. Not in this one
BTW, I see no difference in version negotiation and primitive negotiation. You can't say "primitive negotiation is bad!" and "protocol negotiation is not bad!". Especially since negotiating protocol versions without crypto primitives is just screaming for downgrade attacks.
If done correctly, it's the same mechanism. if not, both can have the same flaws.
This distinction between protocol version support and primitive support reeks of lack of knowledge in the field (both crypto and protocols), insecurity of the product, and sounds just like an impractical philosophy (especially due to the article renaming many common names of common fields).
Code reuse is a (big) thing. If a software supports multiple "ages", those will be handled with a "registry".
Evolution is another. People have taken huge pains to extend features and capabilities of existing protocols. QUIC is winning probably not only due to google, but also due to its internal versioning of various features.
TLS history showed us that upgrading the cipher list and deprecating the old ones is incredibly faster than trying to update the TLS protocol version. I can really see no reason why anyone would want to go back to the days of unupgreadable protocols and their nightmares
- some_furry 6y ago> BTW, I see no difference in version negotiation and primitive negotiation. You can't say "primitive negotiation is bad!" and "protocol negotiation is not bad!". Especially since negotiating protocol versions without crypto primitives is just screaming for downgrade attacks. Primitive negotiation involves primitives being decided at runtime. This means you can, for example, tell a system that normally does RSA verification to switch to HMAC-SHA256 instead (but using the RSA public key as a HMAC shared key). This is what bit many JWT implementations. Protocol negotiation involves primitives being decided at the time that a protocol version is defined, and then you can only select the version to use. You don't get to tell the server "use this encryption algorithm in this mode", you can only say "use v2" or "use v3". There is no mix-n-match potential. You can't use v2 age with RSA. This isn't a subtle difference. Most cryptography vulnerabilities occur at the joinery between primitives. See also: https://paragonie.com/blog/2019/10/against-agility-in-cryptography-protocols https://paragonie.com/blog/2019/10/against-agility-in-crypto...