tzeruch(_at_)ceddec(_dot_)com wrote:
On Thu, 26 Mar 1998, Hal Finney wrote:
The purpose of a checksum is to tell you whether you've entered the
right passphrase. That's not necessary here because after decrypting the
session key (SK) it will immediately use that SK to decrypt the message,
and there is a check which is done in the first 10 bytes of the message
to see if the SK is correct.
It also says CFB mode with an IV of all zeros. I didn't know the 10 byte
with cfb reset (if the algorithm has a block size of 8 or less) was
supposed to be there (see next).
I may not have been clear. The symmetric-key ESK packet does not have
a 10 byte prefix for the encrypted SK. It is the next packet, the
symmetrically encrypted data packet (section 5.7), which has the prefix.
That prefix allows you to know if the passphrase is good, so there is no
need for a checksum in the ESK packets.
It is true that the public key ESK packet has a checksum anyway, but it
is not strictly necessary since the SK gets checked in the very next step
when we decrypt the message proper.
It is true that the public key ESK packets do have this checksum, so you
are correct that it would be more consistent to have them for the symmetric
ESK as well, but functionally they are not needed.
The ESK packets DO NOT have the 10 byte prefix but "is done in CFB
mode..." And there are resets between the secret values in RSA keys.
ESK packets do not have the 10 byte prefix, that is correct. Neither
does the symmetric ESK, as I hope I have made clear above. The 10 byte
prefix is only used in the symmetrically encrypted data packet (tag 9).
I'm not sure what the relevance is of the resets between secret values
in RSA keys. That only occurs within secret key packets, while we have
been discussing encrypted messages.
Wouldn't it be better to use both the key and iv from the S2K and add the
checksum instead of creating yet another mode?
S2K objects do not have IVs. They know how to convert passphrases into
keys, that's it. We do get the key from the S2K object and the passphrase,
but there is no IV there.
Has anyone else implemented this yet? (PGP5.0ib8 doesn't).
PGP 5.0 does not create such packets, but it does read and handle them.
PGP 5.5 creates conventionally encrypted messages using these packet
formats.
Hal