[Cryptography] IPsec DH parameters, other flaws

Christian Huitema huitema at huitema.net
Mon Nov 16 15:28:23 EST 2020


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20201116/aa3aeda4/attachment.htm>


More information about the cryptography mailing list