Re: Section 5.2.3 of latest draft: bis14.

[[e-mail] ("Hal Finney")]

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