[Cryptography] upgrade mechanisms and policies

[alex at alten.org]

Quoting ianG <iang at iang.org>:

> On 16/04/2015 05:37 am, Ryan Carboni wrote:
>>    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.)
> ...
>> 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).
>
>
> I agree with this.  I'm surprised it isn't celebrated more.  In all  
> our time on the net, the crypto has been unfathomably rock solid as  
> far as algorithms go.  The protocols have also been pretty good  
> compared to the rest of it.
>
>

Quoting from the last page of David Kahn's book "The Codebreakers", 1967,
1996.

"The war of the cryptographer against cryptanalyst has been won by
the cryptographers.  The only way properly encrypted messages can be
read nowadays is by theft or betrayal--that is, noncryptologic means."


>> 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.
>
>
> I think encryption has become so good and so fast, and will become  
> faster still, that encrypting everything with a good-enough cipher  
> is probably ... good enough.  For everything in general.
>
>

Agreed, now AES is shipping with almost every Intel processor (the AES-NI
instruction set).  The only problem is most programmers don't want to deal
with the extra headache of managing the crypto data keys.

- Alex
-- 
Alex Alten
alex at alten.org