[Cryptography] The paranoid approach to crypto-plumbing

Bill Frantz frantz at pwpconsult.com
Mon Sep 16 20:47:11 EDT 2013

On 9/16/13 at 4:02 PM, leichter at lrw.com (Jerry Leichter) wrote:

>The feeling these days among those who do such work is that 
>unless you're going to use a specialized combined encryption 
>and authentication mode, you might as well use counter mode 
>(with, of course, required authentication).  For the encryption 
>part, counter mode with multiple ciphers and independent keys 
>has the nice property that it's trivially as strong as the 
>strongest of the constituents.  (Proof:  If all the ciphers 
>except one are cracked, the attacker is left with a 
>known-plaintext attack against the remaining one.

Let me apply the ideas to the E communication protocol 
<http://www.erights.org/elib/distrib/vattp/index.html>. The code 
is available on the ERights site <http://www.erights.org/>.

Cutting out the details about how IP addresses are resolved, the 
initiator sends a series of messages negotiating the details of 
the connection and uses Diffie-Hellman for session key 
agreement.  --  Change the protocol to use both discrete log and 
elliptic curve versions of Diffie-Hellman, and use the results 
of both of them to generate the session key. I would love to 
have a key agreement algorithm other than Diffie-Hellman to use 
for one of the two algorithms to get a further separation of 
failure modes.

Authentication is achieved by signing the entire exchange with 
DSA.  --  Change the protocol to sign the exchange with both RSA 
and DSA and send and check both signatures.

In all cases, use algorithm bit lengths acceptable by modern standards.

The current data exchange encryption uses SHA1 in HMAC mode and 
3DES in CBC mode with MAC then encrypt. The only saving grace is 
that the first block of each message is the HMAC, which will 
make the known plain text attacks on the protocol harder. -- I 
would replace this protocol with one that encrypts twice and 
MACs twice. Using one of the modes which encrypt and MAC in one 
operation as the inner layer is very tempting with a different 
cypher in counter mode and a HMAC as the outer layer.

>The need for independent keys is clear since if I use two 
>copies of the same cipher with the same key, I end up sending 
>plaintext!  You'd need some strong independence statements 
>about the ciphers in the set if you want to reuse keys.  
>Deriving them from a common key with a one-way hash function is 
>probably safe in practice, though you'd now need some strong 
>statements about the hash function to get any theoretical 
>result.  Why rely on such things when you don't need to?)

I'm not sure you can avoid that one-way hash function in 
practice. Either it will be distilling randomness in your RNG or 
it will be stretching the "pre-master secret" in your key/IV/etc 
generation. You could use several and XOR the results if you can 
prove that their outputs are always different.

>It's not immediately clear to me what the right procedure for multiple authentication is.

The above proposal uses two different digital signature 
algorithms, sends both, and checks both. I think it meets the 
"no worse than the best of the two" test.

Cheers - Bill

Bill Frantz        |"We used to quip that "password" is the most common
408-356-8506       | password. Now it's 'password1.' Who said 
users haven't
www.pwpconsult.com | learned anything about security?" -- Bruce Schneier

More information about the cryptography mailing list