Subject: Re: Low-level question about OpenPGP - why CFB mode?

From: [email-masked]
Date: Wed, 30 Apr 2003 16:26:44 -0500

> The second advantage of CFB relates to block padding.  It is easy and
> natural in CFB to handle messages which are not a multiple of the cipher
> block length (8 bytes for the early ciphers).  You simply truncate the
> ciphertext so it is the same length as the plaintext, and apply the same
> rule in reverse for decryption.

I know that CFB can encode one byte (or even one bit) at a time, rather
than waiting for the whole block or requiring a multiple of the blocksize.
But in PGP the step is performed on a size that's equal to the block size.
Are you saying that for the last block, you can change that to a size equal
to how much you have left?  I don't think that was clear in the OpenPGP
spec section 12.  It says it loads BlockSize at a time until the plaintext
is used up, implying that the "given plaintext" is a multiple of the
blocksize.

I see that it will work, though: step 12 consumes the remainder of the
plaintext if there are ferwer than BS octets remaining, and it never has to
encode again so the truncation doesn't matter when decoding.

An issue with the document (I'm reading bis-07): step 12 includes "the
process is repeated...".  It doesn't say "this process" means steps 10
through 12 (only 10 must contain n*BS+3 etc instead of BS+3, etc.).  And is
that really part of step 12?

--John

---

From: Derek Atkins <[email-masked]>
Date: 30 Apr 2003 18:10:30 -0400

> is used up, implying that the "given plaintext" is a multiple of the

I think you've got it backwards.  Due to the way PGP uses the IV,
you've always got a full blocksize of pre-encrypted (ready to X-OR)
data waiting for your plaintext.  In other words, the IV is used to
seed the CFB pipeline with enough data so you don't have to wait for
plaintext before you turn the crypto-crank that first time.

And I see no such implication in the text.  It does load the CFB
buffer a full blocksize at a time when it needs to turn the crank, but
the final "block" of plaintext does not need to be a blocksize.
That's because the crank is never turned at that point.  Think about
it this way for a plaintext that is > 2 blocksizes but < 3:

IV --+   +----+   +----+
     |   |    |   |    |
    Ciph |   Ciph |   Ciph
     |   |    |   |    |
   P0+---+  P1+---+  P2+
     |        |        |
     C0       C1       C2

Note that you do perform 3 cipher cycles, but they are performed BEFORE
you feed the plaintext into the cipher.  In other words:

        Ci = Pi XOR Ciph(Ci-1)  where C-1 = IV

so
        C0 = P0 XOR Ciph(IV)
        C1 = P1 XOR Ciph(C0)
        C2 = P2 XOR Ciph(C1)

> encode again so the truncation doesn't matter when decoding.

Or when ENCODING.  Remember, the CFB chain works the exact same way
when encoding or decoding.

> that really part of step 12?

I need to look at the document again to answer this question

> --John

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com

---

From: Derek Atkins <[email-masked]>
Date: 30 Apr 2003 18:20:45 -0400

> that really part of step 12?

Having just looked at -07, I agree that step 12 should be re-worded
to make it more clear.  Right now it says:

  11.  FR is encrypted to produce FRE.

  12.  FRE is xored with the next BS octets of plaintext, to produce
       the next BS octets of ciphertext.  These are loaded into FR and
       the process is repeated until the plaintext is used up.

I would suggest:

  12.  FRE is xored with the next BS (or fewer) octets of plaintext,
       to produce the next BS (or fewer) octets of ciphertext.  If
       this step has used all the remaining plaintext, the process is
       complete.  Otherwise, the BS octets of ciphertext are loaded
       into FR and the process is repeated (go back to step 11).

Is this more clear?  It makes it clear that the final block can be
smaller than BS octets, and it's explicit about what part of the
process is repeated (for those who couldn't intuit it from what to do
after 'these are loaded into FR' ;).

-derek