[Cryptography] upgrade mechanisms and policies

[ianG]

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.


> 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.


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


You're betraying your CIA bias ;)  I'm guessing you mean here that for 
most business models, auth is more interesting.

For most traffic on the net, I'd say auth is highly dependent.  For some 
things we want auth.  But for other things we want the opposite of auth, 
call it anti-auth or unauth.  This is the notion of sexchat, snapchat, 
OTR, etc in principle, not in implementation.



> I mean, for instance. Do you think this email should be encrypted, or
> simply authentificated?


These emails should be un-auth, moderated and encrypted.

The fact that they are not encrypted now means we have a podium at which 
we can tell the NSA that we don't agree, and we didn't start the fire 
... but I'd still rather it was encrypted and unattributed and we could 
talk with complete confidence.



iang