Subject: Re: Sample Twofish message

From: Werner Koch <[email-masked]>
Date: Mon, 5 Apr 1999 21:56:58 +0200

[email-masked] writes:

> Note also that the special CFB "sync" operation (after processing these 10
> bytes) is not to be done with block ciphers whose block size is greater
> than 8 bytes, hence is not done for Twofish.

Hmmm, section 5.7 states that encryption is done in PGP's special CFB
mode and there is no exception mentioned.  

If I remember correct, we discussed this 128 bit block cipher issue
last year and changed the draft accordingly. 

-- 
Werner Koch at guug.de           www.gnupg.org           keyid 621CC013

---

From: [email-masked]
Date: Fri, 9 Apr 1999 15:45:02 -0700

Werner Koch, <[email-masked]>, writes:
> [email-masked] writes:
>
> > I believe Uri was referring to the passphrase-protected secret key
> > data, which does use an IV in the conventional sense.
>
> Hmmm, from the pgp 2.6.3 documentation about secret key certificates:
>
> |  and the checksum is used to tell if the password was good.  The CFB
> |  IV field is just encrypted random data, assuming the "true" IV was
> |  zero.
>
> This is what is done in GnuPG too and I have checked interoperability
> against pgp 5.0beta.

This is actually pretty funny.  We're both interpreting it differently,
but we interoperate.

By my interpretation, the first 8 bytes are an IV.  We encrypt those
with the key, and XOR into the next 8 bytes to get the first 8 bytes
of plaintext.

With your interpretation, the IV is zero.  You encrypt that with the
key and XOR into the first 8 bytes to get 8 random bytes, which you
discard.  You then take the first block of ciphertext, whiich is the
first 8 bytes of data, encrypt it with the key, and XOR into the next
8 bytes to get the first 8 bytes of plaintext.

The result is exactly the same.  That's why it interoperates.  With
CFB mode, each ciphertext block acts like an "IV" for the next block.

The situation is different for encrypted data blocks, because there we
have the extra two bytes of check data which must be compared against the
decrypted form of the first 8 bytes.  So we must use the convention of
a zero IV to successfully decrypt that.  But with the encrypted secret
keys there are no check bytes and the two descriptions are equivalent
(as long as the IV size == the block size).

Sorry I have not yet sent out Phil's proposal, I've been having
connectivity problems today.

Hal Finney