[Cryptography] upgrade mechanisms and policies

[Ryan Carboni]

>
> My approach to providing alternative cypher suites would be to use
> superencryption for the alternates. (Here  superencryption is meant broadly
> for each primitive, eg dual sigs & hashes.)
>
> So if one has a primary ciphersuite A and backup suite B, the protocol
> would offer a choice of A or A*B, where * denotes superencryption.
>
> If A is ever compromised we kill A, switch to A*B as an interim, select a
> new backup, C, perhaps based on lessons learned from the break in A. We
> then upgrade as many systems as possible to a new protocol version that
> supports B, B*C and, for backwards compatibility, A*B.
>
> If B is compromised but not A, we pick C and upgrade to A and A*C.
>
> In the unlikely event both A and B are compromised simultaneously there is
> still a good chance A*B will remain strong.
>
> The switch from primary to backup is always safe for end users and of
> little use to attackers. It imposes a performance hit, but mainly on
> servers which can be beefed up temporarily until most clients upgrade.
> Switching ciphersuites then becomes more of an "in case of emergency break
> glass" situation.
>
> Arnold Reinhold
>


Cryptography is a mature science. Cipher algorithms degrade far more
gracefully than you think.  Linear and differential cryptanalysis are much
more difficult using modes other than ECB or CTR. And even if there is a
full round break, brute force is usually faster and easier, as is currently
the case for DES and AES. (anyone have any idea how much a differential
attack against single-key DES would cost in monetary terms?)

Hash algorithms have also improved to the point that I do not think there
ever will be a malicious collision with SHA-256 (although I'm sure in
twenty years there'd be some form of full round break).

My approach is this: media files are large in volume and much of their
computation overhead is from encryption, when encrypted. In some cases,
there is overhead from compression, but if you're running your own
optimized servers, you're probably disabling compression served from files
from servers that work under a certain subdomain.

I believe there should be a flag called importance. If it is or isn't
important, that should be set on the server end. If the flag is set,
browsers should be fine in accepting low-secure ciphers... including NULL
encryption and RC4.

Because for most files exchanged over the internet, authentication is more
important.

I mean, for instance. Do you think this email should be encrypted, or
simply authentificated?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20150415/8ba4ebca/attachment.html>