Hi Tom,
First things first. I very much regret breaking compatibility with
the OpenSRS system, which I am only learning about now. I made the
changes to Crypt::CBC only after a lengthy discussion with the OpenSSL
folks who had discovered a flaw in our implementations of CBC
encryption. One should not use the secret key to generate the
initialization vector because it exposes the ciphertext to chosen
plaintext attacks. This is spelled out clearly in Bruce Schneier's
book and I was remiss in my first implementation of the module.
We (the OpenSSL team and myself) made the difficult choice to break
compatibility with existing applications in order to provide products
that are secure. We were able to maintain backward compatibility to
the extent that old encrypted messages can be decrypted with the new
software, but the reverse is not the case.
If it helps, I could provide a "compatibility mode" in which you can
throw a switch and have the IV's generated the old way. However,
you'll still have to make server source code changes. It might be
easier for you to stick with the old version of the module.
It seems as if you're only using Crypt::CBC to generate a session
hash. The CBC algorithm wasn't intended for this purpose, but rather
to encrypt and decrypt streams of variable-length data. May I suggest
that you use plain-old MD5 or SHA to do this instead? Alternatively,
you could use the underlying DES or IDEA block ciphers instead. This
will be faster, and is guaranteed to give you the same result each
time.
In regards to the clearing of the IV following each encryption or
decryption cycle, this isn't a bug, it's a feature. If you are
encrypting, the IV is generated randomly each time you start
encrypting a new message. If you are decrypting, the IV is recovered
from a short header that precedes the encrypted message. You don't
want the same IV to proceed each message, because that would make
messages that have similar initial data (such as e-mail headers)
encrypt to the same ciphertext.
Lincoln
Tom Brown writes:
>
> there's the text below, and I believe the 2nd last delete in "sub finish"
> is an error...
>
> #TAB delete $self->{'civ'};
> delete $self->{'buffer'};
> return $result;
> }
>
> You're wiping out your initialization vector, which seems to me to be a
> bad thing if folks use one object to do multiple encrypt()/decrypt()
> operations... It's certainly a radical change from previous versions...
> and considering that the new behaviour can be obtained by calling new()
> again, it doesn't seem necessary....
>
> However, that change is still not sufficient to make the OpenSRS client
> app work, but as I mentioned below, one of the problems is that they're
> basically using encrypt() as a hash function to generate a shared secret
> for use as a session key ... which doesn't work at all now that you throw
> extra randomness into it :-[
>
> Feel free to forward this to the dev-list if you want to reply there ...
>
> p.s. appreciate your great work on CGI.pm, the mod_perl list, and the
> mod_perl book ;-)
>
> ----------------------------------------------------------------------
> tbrown@BareMetal.com | Drive thy business, or it will drive thee.
> http://BareMetal.com/ | - Benjamin Franklin
> web hosting since '95 |
>
> ---------- Forwarded message ----------
> Date: Mon, 31 Jan 2000 19:50:43 -0800 (PST)
> From: Tom Brown <tbrown@baremetal.com>
> To: Matthew D. Fong <matt@adsl-216-103-215-200.dsl.snfc21.pacbell.net>
> Cc: John Burgess <john.burgess@fastex.net>, dev-list@opensrs.org
> Subject: Re: FYI: Lessons Learned on Client Installs
>
> On Mon, 31 Jan 2000, Matthew D. Fong wrote:
>
> > I experienced the same problem with the Crypt::CBC 1.22 perl mod. It
> > stumped me since today. We should really add something to the FAQ about
> > this. It's always first instinct to install the latest version(s).
> >
> > Matthew Fong
> > Refract LLC
> >
> ------------
>
> Revision history for Perl extension Crypt::CBC.
>
> 1.22 Wed Jan 26 19:07:30 EST 2000
> - Added support for Crypt::Blowfish (available from www.cryptix.org)
> - Fixed failure to encrypt data files < 8 bytes
> - Fixed -w warning when decrypting data files < 8 bytes
>
> 1.21 Mon Nov 29 17:11:17 EST 1999
> - Generate random initialization vector.
> - Use same encryption format as Ben Laurie's patches to OpenSSL
> (versions >= 0.9.5)
>
> 1.20 Sun Dec 20 3:58:01 1998 MET
>
> --------------
>
> The first listed change under 1.21 looks very troublesome... The
> worst part is that the opensrs folks can't automatically adapt to
> both versions of the code (at least not without getting really
> ugly)...
>
> Hmm, maybe there is a simple fix... since it looks like Lincoln
> went to reasonable pains to make 1.22 backward compatible with
> previous versions...
>
> No... it doesn't look like it to me... Lincoln made the
> assumption that he could create a random initialization vector
> for encryption and store it in the data stream, and thus the decoder
> could pick it up from the data stream... This doesn't work for
> two reasons in the OpenSRS case...
>
> 1) you can't count on the decoder being smart enough to pick it
> out of the data stream... (I THINK)
>
> 2) the encryption algorithm is being used to generate a session
> key... since this needs to be shared by both ends, it must not
> include any 'new' randomness, since there will be _no way_ for
> the server to pick up the session key.
>
> This is bad... really bad. I suppose the argument could be made
> that the encryption and decryption routines should be used for
> just that, and not used as hash functions for creating session
> keys... but even so, I THINK we're still left with the fact that
> 1.20 can't read 1.22 data streams ...
>
-- ======================================================================== Lincoln D. Stein Cold Spring Harbor Laboratory lstein@cshl.org Cold Spring Harbor, NY ========================================================================
This archive was generated by hypermail 2.1.3 : Tue Oct 19 2004 - 23:35:18 EDT