Hal Finney wrote:
Ben Laurie writes:
OK, I had to resort to reading the PGP 2 source to find out what was
going on here.
In essence its fairly simple, but is _definitely_ no explained by the I-D.
Firstly, v3 CFB does not use the IV in a standard way. Instead, what it
does instead is set the IV to all zeroes and then decrypt the IV and
throw away the result.
This is not correct. The IV is used in the standard way. You may be
thinking of symmetrically encrypted data packets, which work as you
say here. V3 private keys are standard.
Experiment and code reading/running says it is correct.
Secondly, as I think was correctly explained by someone here (but I
didn't get it, sorry), when "resynchronisation" occurs it means "set the
IV to the last 8 bytes of ciphertext".
Right.
Note that for any standard-sized key resynchronisation does _not_ occur,
so people who think they've implemented it from AC are in for a surprise
one day.
This will usually be the case; p and q will be forced to be a multiple
of 8 bytes (64 bits) for keys of usual sizes. But d, which is e inverse
mod lambda(n) would be shorter sometimes. lambda(n) is lcm(p-1,q-1) so
lambda will be at least 1 bit shorter (since p-1 and q-1 are both even)
and perhaps 2 bits shorter with probability about 1/2 (in case p-1 and
q-1 have other small common factors). Independently, d may be shorter
than lambda. Put it all together and maybe one key in 70 or so would
have a d value which is 1 byte shorter, requiring resynchronization.
OK, well, I haven't see one yet. As I mentioned before, test
vectors/packets in the I-D would be _really_ nice.
Obviously the I-D should be updated to reflect this (and clearly no-one
has ever implemented v3 keys from it).
The current text is not inaccurate, but does rely on knowing what
"resynchronized" means. Since this is a non-standard term we should
explain it better. Here is the current text:
Encryption/decryption of the secret data is done in CFB mode using
the key created from the passphrase and the Initial Vector from the
packet. A different mode is used with V3 keys (which are only RSA)
than with other key formats. With V3 keys, the MPI bit count prefix
(i.e., the first two octets) is not encrypted. Only the MPI
non-prefix data is encrypted. Furthermore, the CFB state is
resynchronized at the beginning of each new MPI value, so that the
CFB block boundary is aligned with the start of the MPI data.
The last sentence is the one which is problematic. What if we changed
it to:
Furthermore, at the beginning of each MPI value after the first,
the CFB state is re-synchronized to its initial state, with the IV
for that MPI taken as the last 8 octets of the ciphertext of the
previous MPI value.
Note that V3 keys only support ciphers with a block size of 8 bytes, so
I think it is OK to explicitly say "8 octets" here.
"re-synchronised to its initial state" is perhaps not entirely clear -
wouldn't it better to just say the IV is set to the last 8 octets of the
previous ciphertext and not mention initial state?
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff