Jon Callas writes:
On 15 Jul 2005, at 4:47 PM, Hal Finney wrote:
This definition could be interpreted to mean that the data set includes
the two-octet scalar count. In fact, in the layout in 5.2.3 the data
set does not include the scalar count. 5.2.3.1 could be reworded to
say
"A subpacket data set consists of zero or more signature subpackets,
AND IS preceded by a two-octet scalar count..."
Personally, I'd just remove the comma. I also removed a semicolon:
A subpacket data set consists of zero or more signature subpackets
preceded by a two-octet scalar count of the length in octets of all the
subpackets. A pointer incremented by this number will skip over the
subpacket data set.
This seems to say that a subpacket data set includes the two-octet
count field. That is inconsistent with how it is used in 5.2.3.
This got dropped:
Section 5.9 on literal packets:
- File name as a string (one-octet length, followed by a file
name). This may be a zero-length string. Commonly, if the source
of the encrypted data is a file, this will be the name of the
encrypted file. An implementation MAY consider the file name in
the literal packet to be a more authoritative name than the
actual file name.
I know we discussed this here, but I'm not sure this is right yet.
What is the "actual file name"? And what does it mean for a name to
be authoritative? This is making some assumptions about processing flow
which may not be correct. I think "actual file name" means the name of
the file being decrypted, assuming that the encrypted data actually came
from a file. But then, usually the encrypted file name is not used for
the decrypted data, rather some modification of that file name is used,
so perhaps that is the "actual file name"?
Maybe we could change the last sentence to "When decrypting, an
implementation MAY use this name as the name of an output file."
That would hint what we mean it to be used for. Or maybe just leave the
last sentence off entirely and just say that this is commonly the name
of the encrypted file, let the implementor figure out what if anything
he wants to do with it.
Section 13, Security Considerations:
Here's the final edit I have:
Many implementers have taken this advice to heart for any data that is
symmetrically encrypted and for which the session key is public-key
encrypted. In this case, the quick check is not needed as the public
key encryption of the session key should guarantee that it is the right
session key. In other cases, the implementation should use the quick
check with care.
On the one hand, there is a danger to using it if there is a random
oracle that can leak information to an attacker. In plainer language,
there is a danger to using the quick check if timing information about
the check can be exposed to an attacker, particularly via an automated
service that allows rapidly repeated queries
On the other hand, it is inconvenient to the user to be informed that
they typed in the wrong passphrase only after a petabyte of data is
decrypted. There are many cases in cryptographic engineering where the
implementer must use care and wisdom, and this is one.
Well, I'm still not that comfortable with the wisdom and heart business,
but after recently seen another showing of the Wizard of Oz I'd suggest
throwing in a reference to courage and then we'll be done...
Seriously, it's not that big a deal, it's not how I would write it but
I think the information is fine, if everyone else is comfortable with it.
Hal