From tzeruch(_at_)ceddec(_dot_)com:
I am using the SSLeay call as:
BF_set_key(&bfkey, 16, key);
key is the key material from the iterated salted hash, 16 is the length
(i.e. 128 bits), then the BF_cfb64_encrypt call with the wierd reset.
It works against itself - anyone have a test case? Or do I have the first
implmentation?
I am not aware of any other implementations of Blowfish within the
OpenPGP framework.
Is the plaintext put through the cfb system, i.e. xored with the iv?
(I assume I would discard any key material, but not the iv).
Or is it intended to be completely unencrypted?
I don't follow you here. In CFB mode, the ciphertext is fed back through
the cipher (Blowfish in this case), and the result of that is xored with
the plaintext to produce the next block of ciphertext.
For the first block, the IV is encrypted with the cipher, and the output
is xored with the first block of plaintext to produce the first block
of ciphertext.
PGP's implementation uses an IV of all zeros, and prepends ten bytes
of random data (such that bytes 9 and 10 match bytes 7 and 8) to the
plaintext. It does a CFB "resync" after encrypting those ten bytes.
Let me explain that step by step.
1. The feedback register (FR) is set to the IV, which is all zeros.
2. FR is encrypted to produce FRE (FR Encrypted). This will be the
encryption of an all-zero value.
3. FRE is xored with the first 8 bytes of random data which have been
prepended to the plaintext to produce C1-C8, the first 8 bytes of
ciphertext.
4. FR is loaded with C1-C8.
5. FR is encrypted to produce FRE, the encryption of the first 8 bytes of
ciphertext.
6. The left two bytes of FRE get xored with the next two bytes of data
which were prepended to the plaintext. This produces C9-C10, the next
two bytes 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 bytes of the given plaintext, now that we
have finished encrypting the 10 bytes of prepended data. This produces
C11-C18, the next 8 bytes of ciphertext.
10. FR is loaded with C11-C18
11. FR is encrypted to produce FRE.
12. FRE is xored with the next 8 bytes of plaintext, to produce the next
8 bytes of ciphertext. These are loaded into FR and the process is
repeated until the plaintext is used up.
Hopefully this will help you verify that your code is following this logic.
Hal Finney