Re: [pac] Re: Using keys not generated by your module ...

Actually, Crypt::CBC uses a static IV of "RandomIV" - a holdover from
Eric Young's stuff. (to verify this, encrypt the same plaintext numerous
times . . you'll find that the ciphertext never changes. [use
encrypt_hex() just to make comparisons easy])

I currently have two alternatives available to Crypt::CBC (the static IV
bothers me terribly).  The first is Crypt::CBC_R (random IV), which can
read older Crypt::CBC messages, but not write them; the other is
Crypt::CBC_IL, a 4-way interleaved cipher block chaining mode.  And yes,
I've been trying to work with LDS to change the current Crypt::CBC to
have a 'compat' mode which would be 'SSLeay-compatible'.

If anyone is interested in either of the modules I have available,
please drop me a note with your request.

Thanks~
--dave

Vipul Ved Prakash wrote:
> 
> On Sat, Apr 07, 2001 at 10:17:50PM -0700, Benjamin Trott wrote:
> >
> > After patching these bits, it looks like there's more (unfortunately). One
> > thing is that Crypt::CBC takes the last byte of the last block in the
> > decrypted data and treats it as an integer telling it how much of the last
> > block to cut off. Crypt::CBC was apparently designed for compatibility w/
> > SSLeay; this must be one of the features of that software.
> >
> > Another is that, even if you set the starting IV to a value in the
> > constructor, Crypt::CBC generates a random IV when encrypting, then prepends
> > the encrypted data with that IV.
> >
> > So it's looking like the differences are more than a few simple changes to
> > the constructor, in which case I'm thinking it may be best to break out some
> > of the functionality into a separate module (a subclass, perhaps).
> 
> > Best of all would be to break out the SSLeay-specific functionality into
> > a different subclass as well, then have the main Crypt::CBC implement
> > just the shared (core CBC) functionality.
> 
> A very good idea, indeed. IMO, anything that aids interoperability and
> future extensibility is a big win. I would wholeheartedly suggest
> following through with it.
> 
> To make sure this does break any old code, you could design Crypt::CBC to
> take on the shape of the subclass that is passed to its constructor. (In
> much the same way Crypt::RSA behaves like ::ES::* and ::SS::*.) I have
> found this model to be more flexible than plain inheritance in most cases.
> The subclass could then default to Crypt::CBC::SSL.
> 
> best,
> vipul.
> 
> PS: Folks on perl-crypto might be interested in this discussion, so I'm
>     CCing to the list address.