<div dir="ltr"><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">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.)<br><br>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. <br><br>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.  <br><br>If B is compromised but not A, we pick C and upgrade to A and A*C. <br><br>In the unlikely event both A and B are compromised simultaneously there is still a good chance A*B will remain strong. <br><br>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. <br><br>Arnold Reinhold<br></blockquote><div><br><br></div><div>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?)<br><br></div><div>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).<br></div><div><br></div><div>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.<br><br></div><div>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. <br><br></div><div>Because for most files exchanged over the internet, authentication is more important.<br><br></div><div>I mean, for instance. Do you think this email should be encrypted, or simply authentificated?<br></div></div>