Re: Cipher advice
- From: daw@xxxxxxxxxxxxxxxxxxxxxxxx (David Wagner)
- Date: Tue, 5 Sep 2006 19:55:45 +0000 (UTC)
The cipher will be used to encrypt data that is moving between a a
client and a server. It is a case where SSL would generally be employed
but cannot in this case for a few technical reasons. We can, however,
use SSL (more specifically HTTPS) to do a key exchange. This key will
then be used to encrypt data travelling between the client and server.
Care to share the technical reasons, in case we can suggest anything
you can do to stick to SSL/TLS? It's always best to use an existing
protocol or mode of operation, rather than inventing one of your own.
It is important that an attacker cannot view the plain text (although
the data in question loses relevance quick quickly so after a few weeks
the value of the plain text drops significantly). It is also important
that an attacker cannot modify the data in a way that would mean the
plain text would still adhere to the application protocol but have a
I'd use any IND-CCA2 /\ INT-PTXT symmetric-key mode of operation.
These are also known as authenticated encryption.
For instance, any of the following should do the trick:
- generic composition of a secure encryption scheme plus
a secure message authentication scheme
(e.g., ciphertext = C || AES-OMAC(Ka, C), where
C = AES-CBC-Encrypt(Ke, plaintext) and Ke,Ka are two
independent AES keys exchanged using the SSL protocol)
- any AEAD scheme (e.g., GCM, CWC, EAX, CCM, etc.)
Include a sequence number or timestamp if you want to prevent replay
attacks, and check at the receiver to make sure that they never repeat.
Use independent keys in each direction (don't re-use the same keys
for both directions of the channel), or include a "direction bit" or
"destination address" to the plaintext and check it at the receiver.
- Prev by Date: Re: Worst encryption software ever
- Next by Date: Re: Cipher advice
- Previous by thread: Re: Cipher advice
- Next by thread: Re: Cipher advice