[145375] in cryptography@c2.net mail archive
Re: Encryption and authentication modes
daemon@ATHENA.MIT.EDU (Chris Palmer)
Sat Jul 24 12:53:20 2010
Date: Fri, 23 Jul 2010 13:19:18 -0700
From: Chris Palmer <chris@noncombatant.org>
To: Florian Weimer <fweimer@bfk.de>
Cc: David McGrew <mcgrew@cisco.com>, dj@deadhat.com,
Cryptography List <cryptography@metzdowd.com>,
Justin Troutman <justin@extorque.com>
In-Reply-To: <82r5iupqcj.fsf@mid.bfk.de>
Florian Weimer writes:
> I just want to create a generic API which takes a key (most of the time, a
> randomly generated session key) and can encrypt and decrypt small blobs.
> Application code should not need to worry about details (except getting
> key management right, which is difficult enough). More popular modes such
> as CBC lack this property, it's too easy to misuse them.
I wrote such a thing for web developers, and other people have too.
I can't see a reason to do anything other than
ciphertext = aes_cbc(enc-key, random-iv, plaintext)
sealed-blob = hmac(mac-key, ciphertext + timestamp) +
ciphertext + timestamp
You wrap this magic up in a trivial interface:
byte [] seal(byte [] macKey, byte [] encKey, byte [] plaintext)
throws GeneralSecurityException
{ ... }
byte [] unseal(byte [] macKey, byte [] encKey, byte [] ciphertext,
long expirationInterval)
throws UnexplodedCowException
{ ... }
You can find my Java code with a google search, but it's not special. You
can write it yourself in your favorite language with small effort.
This gives you expiration, integrity, and confidentiality. You can make the
keys implicit by getting them from the server config variables or something.
In case of mangled or expired ciphertext, the checking function can fail
fast (no need to decrypt, since you do the hmac check first).
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
