Hacker News new | past | comments | ask | show | jobs | submit login

I did some "OpenPGP Best Practices" work for a client recently. They don't have a choice, because a third party requires it. The goal was to make sure it was as safe as possible. One thing that struck me is that I have a simplified mental model for the PGP crypto, and reality is way weirder than that. The blog post says it's CFB, and in a sense that's right, but it's the weirdest bizarro variant of CFB you've ever seen.

In CFB mode, for the first block, you take an IV, encrypt it, XOR it with plaintext. Second block: you encrypt the first ciphertext block, encrypt that, XOR with second plaintext block, and so on. It feels sorta halfway between CBC and CTR.

Here's the process in OpenPGP, straight from the spec because I can't repeat this without being convinced I'm having a stroke:

   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 BS octets of random data prefixed to
        the plaintext to produce C[1] through C[BS], the first BS octets
        of ciphertext.

   4.   FR is loaded with C[1] through C[BS].

   5.   FR is encrypted to produce FRE, the encryption of the first BS
        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 C[BS+1]
        and C[BS+2], the next two octets of ciphertext.

   7.   (The resynchronization step) FR is loaded with C[3] through
        C[BS+2].

   8.   FRE is xored with the first BS octets of the given plaintext,
        now that we have finished encrypting the BS+2 octets of prefixed
        data.  This produces C[BS+3] through C[BS+(BS+2)], the next BS
        octets of ciphertext.

   9.   FR is encrypted to produce FRE.

   10.  FR is loaded with C[BS+3] to C[BS + (BS+2)] (which is C11-C18
        for an 8-octet block).

   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.
Yeah so CFB except your IV isn't your IV and randomly do something with two bytes as... an... authenticator? And then everything after that is off by two? This isn't the only case where OpenPGP isn't just old, it's old and bizarre. I don't have a high opinion of PGP to begin with, but even my mental model is too charitable.

(Disclaimer: I'm a Latacora partner, didn't write this blog post but did contribute indirectly to it.)




I think this is called Plumb CFB. It was invented by Colin Plumb back in the day. I first saw it in their FDE products which didn’t have a good IV generation process (kind of acting like a replacement for XTS or a wide block cipher) and no, I don’t know what it’s for.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: