[cryptography] Repeated Encryptions Considered.... ?

Nico Williams nico at cryptonector.com
Sun Jun 19 18:29:54 EDT 2011

On Sat, Jun 18, 2011 at 10:44 PM, Tom Ritter <tom at ritter.vg> wrote:
> There are legitimate reasons for *not* doing it, but they're more
> about the engineering. Twice as much code, twice as many possibilities
> for bugs.  Twice the key material, twice the key storage.  More work,
> no practical security gained.  None of these address the idea that the

Those reasons matter.  If you want people to use your
application/protocol/whatever, it'd better not be too slow nor
inefficient.  Even today people complain that TLS is too slow.  So the
fastest possible crypto that also provides the desired level of
protection is kinda desirable.  Granted, cutting it close all the time
may not be the best policy, but if no one would use crypto due to its
being slow... it'd be better to cut it close.

> double encryption aids any sort of
> chosen-plaintext/known-plaintext/chosen-ciphertext/or other attack.
> (Although the exposure of a oracle enabling an attack in such a system
> *would* be system-specific, and there's no standardized system for
> this to my knowledge - so it may be a case of 'Create one, and give an
> incentive to break it.')

Related key attacks would be a concern, so you'll want to at least
derive different keys for each cipher, if you really must combine

> I got in a discussion recently about this, in the specific case of
> encrypting something in javascript, and then again in SSL.  Trying to
> avoid the argument over javascript crypto I thought it was absurd that
> NOT using SSL was a reasonable decision.  The response was the 'don't
> double encrypt' argument, without any real facts to back it up.

Tell them to use channel binding instead.  That way you use TLS for
everything except authentication, and use whatever app-layer crypto
you have to authenticate the user and service and bind the TLS channel
into the authentication -- this will minimize the use of crypto while
maximizing security.

The alternative you mention of NOT using TLS and doing all crypto at
the app layer seems likely to be buggy (e.g., there likely will be
plaintext left unprotected that later turns out to create a
vulnerability).  For example, chances are the app wouldn't encrypt the
actual URIs referenced in HTTP requests, and if the app wanted to do
that then... it'd have to either not be RESTful or create a tunnel --
i.e., recreate TLS.  Sounds like a mess to me.

(Also, you'd have to know that you trust the JS scripts, no?  If you
rely on TLS itself to authenticate the services serving the scripts
then the scripts can't add strength to the authentication of the
service to the user, so nothing gets added regarding protection
against phishing.)


More information about the cryptography mailing list