On Wed, Nov 04, 2009 at 02:26:47PM -0600, Doug Bailey wrote: > > > Are there any glaring flaws in this approach? > > > > Generally it is a bad idea to hard-wire data-encryption keys. > > Standard > > practice is burn-in a "key-encryption-key" (KEK), and each encrypted > > object uses a random unique key, with that key encrypted under one or > > more KEKs. Each party that needs to access the data, decrypts the > > random key via its KEK, and then decrypts the data object. > > > > The KEK need not be symmetric, with smime(1) for example, the KEK is > > typically an RSA key-pair, which makes it much easier to publish the > > keys necessary to generate content for a particular recipient. > > So this means that I need to decrypt a key using a public key encryption > mechanism. I still only want to run in my microprocessor's authenticated > mode which means I need to decrypt the key in a code space of around 32 KB.
You don't "have to use" a public key algorithm, but that would be best practice. Otherwise the systems that generate encrypted content need all the device (symmetric) keys, which are presumably somewhat sensitive. You can use symmetric KEKs, but then (just as you would with a non-ephemeral symmetric DEK) you have to store these securely in a lot more places, which is often difficult. > Does anyone have suggestions for a small footprint, public-key > decryption source code library? I don't have any experience with small footprint devices, hopefully someone else can recommend a suitable library. I know that http://www.cs.auckland.ac.nz/~pgut001/cryptlib/ is well reputed as a high quality crypto library. If it supports your device footprint, you may do well to consider it. -- Viktor. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
