Re: Need help evaluating proposed encryption architecture.

From: Alek Davis (alek_xDOTx_davis_xATx_intel_xDOTx_com)
Date: 05/07/04 

Date: Thu, 6 May 2004 20:58:06 -0700

Just don't spend too much time there. The problem of data protection has
been researched extensively and it is not likely that you will come up with
an approach that hasn't been proposed before. Just use what is already
available, like DPAPI, integrated security, etc., whatever is most
appropriate for your application.

Alek

"dm_dal" <REMOVE_THIS.dmy75252@yahoo.com> wrote in message
news:O5POv82MEHA.3972@TK2MSFTNGP10.phx.gbl...
> Thanks for the input.
> I got a copy of Anakrino and opened up my assembly.....guess it's back to
> the drawing board.
>
> dmy
>
> "Alek Davis" <alek_xDOTx_davis_xATx_intel_xDOTx_com> wrote in message
> news:eo1E5ZhMEHA.3380@TK2MSFTNGP11.phx.gbl...
> > David,
> >
> > 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.
> >
> > Alek
> >
> > "dm_dal" <REMOVE_THIS.dmy75252@yahoo.com> wrote in message
> > news:e7rZPWgMEHA.3052@TK2MSFTNGP12.phx.gbl...
> > > 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
> > fill
> > > 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
> > fill
> > > 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
> > IV_SEED.
> > > We then take 16 bytes of the resultant hash (I won't tell you which 16
> > bytes
> > > we use, but we store the starting position in IV_SEED_START ) to use
as
> > the
> > > IV.
> > > 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
> > and
> > > 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
> > own
> > > byte[]
> > > 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++
> > > library)
> > >
> > > The good points are:
> > > a) each encryption uses a different key and every key is randomly
> > generated.
> > > 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
> > >
> > >
> >
> >
>
>

Loading