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:
* 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
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com