CFB Mode

[Michael Halcrow]

On Mon, Aug 30, 2004 at 09:57:15AM -0500, Michael Halcrow wrote:
> In order to have OpenPGP compatibility in cryptfs, I need CFB mode
> right away in the kernel, so I'm implementing it this week.

Just to make life interesting, CFB can handle a data segment size that
is not an even multiple of the cipher block size.  That does not work
at all with pretty much the entire kernel crypto API.  Is there a
recommended approach to dealing with this, or can I go ahead and make
some invasive changes that will process data sizes that are not even
multiple of the block size, given certain cipher modes?

To be specific, what I need to do is described in detail in RFC 2440
(w/ a 16-octet block algorithm):

   1.  The feedback register (FR) is set to the IV, which is all zeros.

   2.  FR is encrypted to produce FRE (FR Encrypted).  This is the
       encryption of an all-zero value.

   3.  FRE is xored with the first 8 octets of random data prefixed to
       the plaintext to produce C1-C8, the first 8 octets of
       ciphertext.

   4.  FR is loaded with C1-C8.

   5.  FR is encrypted to produce FRE, the encryption of the first 8
       octets of ciphertext.

   6.  The left two octets of FRE get xored with the next two octets
       of data that were prefixed to the plaintext.  This produces
       C9-C10, the next two octets of ciphertext.

   7.  (The resync step) FR is loaded with C3-C10.

   8.  FR is encrypted to produce FRE.

   9.  FRE is xored with the first 8 octets of the given plaintext,
       now that we have finished encrypting the 10 octets of prefixed
       data.  This produces C11-C18, the next 8 octets of ciphertext.

   10.  FR is loaded with C11-C18

   11.  FR is encrypted to produce FRE.

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

In step 12, if the remaining plaintext size (n) is less than 8 octets,
than those n bytes are x'ored against n bytes of the encrypted FR, and
everybody is happy.

Mike
.___________________________________________________________________.
                         Michael A. Halcrow                          
       Security Software Engineer, IBM Linux Technology Center       
GnuPG Fingerprint: 05B5 08A8 713A 64C1 D35D  2371 2D3C FDDA 3EB6 601D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.logix.cz/pipermail/cryptoapi/attachments/20040830/cd9231b2/attachment.bin