Re: Need help evaluating proposed encryption architecture.
From: Alek Davis (alek_xDOTx_davis_xATx_intel_xDOTx_com)
Date: Tue, 4 May 2004 13:29:14 -0700
I hate to tell you this, but your proposition is not significantly better
than storing the key in the source code. The only difference here is that
you store the key generating parameters as part of encrypted data and key
generation logic in the application. In essence, your data is protected by
the source code, because you rely on inability of a hacker to reverse
engineer the decryption logic. Well, assuming that you are using .NET
languages, reverse engineering is not a hard to do as most of us would want
it to be. If you haven't done this yet, try opening your assembly and check
the decryption routine in Anakrino. After reverse engineering your
application logic, a hacker can figure out in which bytes you store IV,
seed, and implement same logic as your application. This type of attack is
really trivial, so you need something better than that (assuming that your
data worth the effort). Although, it is probably not as bad as just storing
the private key in assembly. Sorry, buddy.
"dm_dal" <REMOVE_THIS.email@example.com> wrote in message
> I'd like to bounce an idea off of you. Please, Please..feel free to tear
> this apart.
> We're looking at building a new encryption/decryption component to be used
> internally/externally in WinForms and WebForms applications. (Not for
> resale) Our previous component used a private key that was stored in the
> source (yuk). That has to change. I was thinking of using the following.
> Please tell me your thoughts.
> 1) Use RNGCryptoServiceProvider to generate a random number of bytes to
> SEED byte[n].
> 2) SEED byte[n] is used as a seed to generate a new 256 bit key. (or
> whatever size key we decide to use)
> 3) Use RNGCryptoServiceProvider to generate a random number of bytes to
> IV_SEED byte[n].
> 4) IV_SEED byte[n] is used to generate a random Initilization Vector for
> RijndaelManaged. This is done by generating a 256-SHA hash of the
> We then take 16 bytes of the resultant hash (I won't tell you which 16
> we use, but we store the starting position in IV_SEED_START ) to use as
> 5)Encrypt the plain text using the derived Key and IV
> 6)Add the "SEED", "IV_SEED" and the "IV_SEED_START" to the byte produced
> in step 5 (We won't give the order in which they are added)
> 7) The entire byte (cipher-text, seed and iv_seed) are base64 encoded
> stored in the db.
> To decrypt, we just reverse the order.
> Strip out the SEED, IV_SEED and CIPHERTEXT bytes and store them in their
> Regenerate the Key from the SEED
> Regenerate the IV from the IV_SEED
> Decrypt the CIPHERTEXT using the derived Key and IV
> I currently have this up and running as a prototype. From a speed
> standpoint, it runs pretty quick, much faster than the old component (C++
> The good points are:
> a) each encryption uses a different key and every key is randomly
> b) each encryption uses a different/random IV
> c) neither the key nor the IV are stored anywhere, in any system.
> Please send me your feedback.
> David Young