On 9/16/13 at 4:02 PM, leich...@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
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
