> One reason for the bloat is that the named parameter passing scheme causes
the Integer stuff to be linked in, even if you don't use the Integer class
or ciphers that use it. You can work around this by editing algparam.cpp
to remove any references to Integer. That should be sufficient for the
linker to strip out the Integer code.

I'll try that out later and report back with stats.

> That's true, but it doesn't answer gl's question. In CTR and OFB modes,
encryption and decryption are exactly the same operation, because they
both generate a keystream that's independent of the plaintext, and then
XOR the plaintext with it. In CFB mode, encryption and decryption are
different, but they both only use the block cipher's encrypt operation

Thanks for clearing that up Wei.
--
gl

----- Original Message -----
From: "Wei Dai" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, February 03, 2003 11:57 PM
Subject: Re: Decrypting with Encryptor objects?


> On Sun, Feb 02, 2003 at 05:32:07PM -0500, Jonathan Brandmeyer wrote:
> > On Sun, 2003-02-02 at 15:11, gl wrote:
> > > Another question - it seems that I can _de_crypt with
> > > CTR_MODE<>::_En_cryption objects, just as you could (well, needed to)
in
> > > 4.2.  Is this algorithm dependent or mode dependent?  I'm trying to
reduce
> > > code size for a self-extractor, so sharing my encryption class code is
> > > desirable.
> >
> > I am still learning the API for this library, but ifI recall the theory
> > correctly, CTR, OFB, and CFB all use the underlying block cipher in
> > encyrption mode for both encryption and decryption.
>
> That's true, but it doesn't answer gl's question. In CTR and OFB modes,
> encryption and decryption are exactly the same operation, because they
> both generate a keystream that's independent of the plaintext, and then
> XOR the plaintext with it. In CFB mode, encryption and decryption are
> different, but they both only use the block cipher's encrypt operation.
>
>
>

Reply via email to