[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Cryptography] IPsec DH parameters, other flaws



On 11/16/2020 12:57 AM, Stephan Neuhaus wrote:



On 11/14/20 1:17 AM, iang wrote:
The NIST AES process showed one way: a knock down competition. Set the requirements, invite open submissions. Only one proposal wins. Set a schedule. Stick to it. Thunderdome. 30 proposals enter, 1 leaves.

The killer to this approach will be, I suggest, interoperability.

The nice thing about symmetric crypto is that everyone agrees that there is just one basic building block, the block cipher[1], that from an interop perspective only has two design parameters: block size and key size. Compare that with, say, a protocol that does all the things that TCP does (which was one thing the OP wanted to replace). There are dozens of design parameters, and there will even be dozens of mutually incompatible *sets* of design parameters, depending on your architecture.

Also, if you want interoperability, you have to get the vendors on board. With block ciphers, we know that you can't really roll your own. With network protocols, there are many different, viable designs that are not interoperable. Vendors can, and, before the Internet took over, did, roll their own network protocols.

So let's say that NIST organises a competition and "TCPng" wins. So what? Why on Earth should anyone implement that thing when it cannot give them an edge? (I realise that this is an argument from incredulity, so I'd be happy to hear counterarguments.)


Do you mean something like QUIC, which does all of TCP and embeds TLS, plus HTTP3, which subsumes HTTP2?

-- Christian Huitema

_______________________________________________
The cryptography mailing list
cryptography AT metzdowd.com
https://www.metzdowd.com/mailman/listinfo/cryptography