On 17/09/2009 21:42, David Wagner wrote:
Kevin W. Wall wrote:
So given these limited choices, what are the best options to the
questions I posed in my original post yesterday?

Given these choices, I'd suggest that you first encrypt with AES-CBC mode.
Then apply a message authentication code (MAC) to the whole ciphertext
(including the IV).  You then send the ciphertext followed the MAC digest.

SHA1-HMAC would be a reasonable choice of algorithm for message

I have to add vote+1 on this selection. For various reasons, today's safe choice seems to be:

  * CBC
  * AES-128
  * HMAC-SHA-1 on the outside of the ciphertext

What is left is padding so that the message is clearly deliminated. I suggest you treat this as a software engineering thing, not a crypto thing, and make sure that you have a length in your packet layout so that it is totally clear what is the packet and what is not.

If you want to see such a design exercise, following Dave's prescription, have a look at SDP1 which Zooko and I did a few years back.


It's a straight forward secret-key encrypted packet layout. It has one novelty in it, which is how it solves the padding / IV issues. Other than that it should be boring.


PS: you are on the right track in trying to avoid any sensitivity to JCE. As long as you can design your layout without any dependency on JCE it should work. JCE is basically a slock design that was put in place for market- and crypto-control reasons, it has no place in software engineering. I speak from experience, I managed the Cryptix project, which was the first Java crypto engine.

PPS: you haven't said enough about the application (or I missed it) to be able to comment on keys. Generally, try to separate the protocol around the key: every good protocol divides into two parts, the first of which says to the second, "trust this key completely". Software engineering ...


The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Reply via email to