[Ach] considering your experience in selecting the perfect config string, would you...

[Aaron Zauner]

Hi Ian,

ianG wrote:
> One proposal is to use odds&evens pairs.  Which is to say have an A
> suite accompanied by a B suite.  Then the next version upgrades to a B
> suite accompanies by a C suite.

That's actually not a bad idea, as long as it's mandated by protocol
design. Still the issue on how fast can you deploy a protocol upgrade on
the public internet. There are still tons of servers out there that
support SSLv3, though almost all of them also support TLS1.1+.

See: https://jve.linuxwall.info/blog/index.php?post/TLS_Survey

> 
> 
>> for example: ECDHE + (Ed25519(EdDSA) || RSA) + ((AES-GCM ||
>> AES-CTR-UMAC) || ChaCha20-Poly1305)
>> (Good job here from the OpenSSH team supporting all of that ;))
> 
> 
> Yes, if it were today, A would be RSA / AES / some Mac+mode and B should
> be Ed25519 / ECDHE / Chacha20-Poly1305.

I don't see any better candidates right now. Although there's a
competition on new AEAD block ciphers in process:
http://competitions.cr.yp.to/caesar.html

There's still the "quantum threat". Although we might not even be alive
when someone gets around to implementing shor's and grover's on a
quantum computer, an assumption would be that some of us - at least for
some communication - want their stuff to be still secure by then. Today
we use terms of security lifetime wenn it comes to choosing a certain
algorithm or key length. That concept is somewhat flawed. It might be OK
for government documents that need to be declassified 35 years from now
anyway but it might not be true for personal communication of people.
So: what's up on the post-quantum crypto front? I've not seen any real
candidate that you can implement without an overhead so great that the
whole idea is useless anyway. But I'm also not a expert in that
direction, so I'm very interested in new proposals and more information
in that direction.

Aaron

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.cert.at/pipermail/ach/attachments/20140629/71a51648/attachment.sig>