Subject: Re: Diffs for next draft

From: Jon Callas <[email-masked]>
Date: Thu, 23 Aug 2001 21:53:55 -0700

>>The correct solution would be to introduce a version 5 of the secret
>>key packet - this is a major change as we may also want to also
>>introduce a v5 public key packet for symmetry reasons.  I guess this
>>will break a lot of code.
>>
>>The hackish solution is to define a new S2K type identical to type 3
>>(iterated and salted) which would then trigger the use of the new
>>SHA-1 checksum.  It should be made clear that this S2K type is only to
>>be used for the protection of the secret key and not for conventional
>>encryption.
>>
>>I don't like any of these solutions but the latter one is easier to
>>implement. Any other ideas?

I think an S2K that includes a hash is only mildly hackish, myself. I'd
support this. I'd even support an additional one that is merely salted with
a hash.

	Jon

---

From: Edwin Woudt <[email-masked]>
Date: Fri, 24 Aug 2001 14:35:01 +0200

Werner Koch <[email-masked]> wrote>

Jon Callas <[email-masked]> replied:
> support this. I'd even support an additional one that is merely salted
> with a hash.

I disagree. As Werner Koch already pointed out, the 'correct' solution is 
to introduce version 5 of the secret key packet. I however do not think 
that there is any real reason for introducing a v5 public key packet, given 
that nothing changed for public key packets.

Keeping v4 public key packets will make sure nothing is broken with regard 
to exchanging public keys. Exchanging secret keys with older 
implementations will be broken in both cases anyway, because of the new s2k 
type.

Edwin

---

From: "Michael Young" <[email-masked]>
Date: Fri, 24 Aug 2001 09:07:01 -0400

-----BEGIN PGP SIGNED MESSAGE-----

Back in March, I opined that an S2K bit was out of place,
noting that the S2K itself isn't broken, and that it is
used in other contexts.

Hal Finney offered the following alternative, which I like
much better than tweaking the S2K itself:

> Another place we could represent the alternative format is the byte
> which comes shortly before the S2K in the secret key packet.  This
> byte is fixed at a value of 255 to flag that an S2K is in use.  We
> could perhaps use some alternate value for this byte to flag that the
> private key is using a different form of checksum protection.

Perhaps a value of 254?

...

On a slightly related note, could we also add placeholders
to the spec for the NAI-specific things that have come into
practice?  One example is the S2K bits for raw and split keys,
which is why it came to mind now.  Hal mentioned an X.509
certificate signature subpacket, and a CRL packet type.  The
PhotoID packet is yet another that was discussed recently.

---

From: Ingo Luetkebohle <[email-masked]>
Date: Fri, 24 Aug 2001 15:41:12 +0200

> implementations will be broken in both cases anyway, because of the new s2k 

I second Edwins opinion and would be in favor of a v5 secret key
format to solve the issue.

Ingo

---

From: Edwin Woudt <[email-masked]>
Date: Fri, 24 Aug 2001 16:36:54 +0200

> noting that the S2K itself isn't broken, and that it is

I agree.

>> private key is using a different form of checksum protection.

I assume that you still want to change the version number to 5 as in your 
March posting?

In that case, I do not really see a reason to bother with changing this 
value at all, because there is no real reason to support the old checksum 
protection for version 5 keys anyway.

> PhotoID packet is yet another that was discussed recently.

This would indeed be helpful.

Edwin

---

From: Werner Koch <[email-masked]>
Date: 24 Aug 2001 16:49:21 +0200

> Perhaps a value of 254?

I certainly support this. So what about this:

     - One octet indicating string-to-key usage conventions.  0
|      indicates that the secret key data is not encrypted.  Values 1
|      to 127 are symmetric-key encryption algorithm specifiers.
|      Values 128 to 253 are reserved. A value of 254 indicates that
|      that a string-to-key specifier is being given, 255 indicates
|      the same but makes use of the deprecated two-octet checksum.

|    - [Optional] If string-to-key usage octet was 254 or 255, a
       one-octet symmetric encryption algorithm.

|    - [Optional] If string-to-key usage octet was 254 or 255, a
       string-to-key specifier.  The length of the string-to-key
       specifier is implied by its type, as described above.

|    - [Optional] If secret data is encrypted, eight-octet Initial
       Vector (IV).

     - Encrypted multi-precision integers comprising the secret key
       data. These algorithm-specific fields are as described below.

|    - If the string-to-key usage octet was 254 a 20 byte SHA-1 digest
|      of the algorithm-specific portion.  Otherwise a two-octet
       checksum of the plaintext of the algorithm-specific portion
       (sum of all octets, mod 65536).

   [....]

|  The 20 byte SHA-1 digest that follows the algorithm-specific
|  portion is computed by hashing the plaintext of all the
|  algorithm-specific octets (including MPI prefix and data). It is
|  always encrypted like the algorithm-specific data. The deprecated 
   16-bit checksum that follows the algorithm-specific portion is
   the algebraic sum, mod 65536, of the plaintext of all the algorithm-
   specific octets (including MPI prefix and data).  With V3 keys, the
   checksum is stored in the clear.  With V4 keys, the checksum is
   encrypted like the algorithm-specific data.  This value is used to
|  check that the passphrase was correct.  Implementations SHOULD only
|  use the 20 byte SHA-1 digest.

-- 
Werner Koch        Omnis enim res, quae dando non deficit, dum habetur
g10 Code GmbH      et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions                                        -- Augustinus

---

From: "Michael Young" <[email-masked]>
Date: Fri, 24 Aug 2001 11:09:35 -0400

-----BEGIN PGP SIGNED MESSAGE-----

> I assume that you still want to change the version number to 5 as in your 

No, I don't want both changes.  Originally, I liked a version
change, but I've been convinced that its implications are a mess.

It seemed that others were uncomfortable with having the the public
and secret key versions out of sync, and I can appreciate that.  The
version number is included in the hashes for fingerprints and for
signatures, so one would either have to map "secret version 5" to
"public version 4", or include the public-key version number in the
secret-key packet.  The latter is cleaner, but it still may be
a little disruptive.

So, Hal Finney's suggestion (change the pre-S2K byte) sounded like
a fair alternative, as it wouldn't require changing the version number,
but it also doesn't disrupt the S2K (which is used elsewhere).

...

By the way, this hash would include *all* the key material, including
the public part, right?

---

From: "Michael Young" <[email-masked]>
Date: Fri, 24 Aug 2001 11:58:38 -0400

-----BEGIN PGP SIGNED MESSAGE-----

I like most of Werner Koch's edits.

> |  always encrypted like the algorithm-specific data. The deprecated 

I strongly recommend hashing the entire contents, including the public
key material.  If you wanted to leave out the material between the
public-key and secret-key parameters (that is, the pre-S2K byte,
the S2K, and the IV), I could accept that, but I think it would
be more convenient and consistent to include them.

Here's my stab at a description, based on Werner's draft:

| The 20 byte SHA-1 digest that follows the algorithm-specific portion
| is computed by hashing:
|     the public key contents (exactly as for fingerprints,
|       see "KeyIDs and Fingerprints");
|     followed by the secret key packet contents,
|       including the plaintext of the algorithm-specific data
|       (including any MPI prefixes and data).
| The digest is appended to the secret-key parameters, and is
| encrypted along with them, without any CFB resynchronization.

---

From: Ingo Luetkebohle <[email-masked]>
Date: Fri, 24 Aug 2001 18:42:17 +0200

> change, but I've been convinced that its implications are a mess.

Well, associating all sorts of special meanings to the pre-S2K byte is
somewhat of a mess, too, isn't it?

IMHO, it would have been a lot cleaner to *always* use an S2K
specifier and then have a 0 symmetric algorithm value for "no
encryption". Then, I would have liked a length byte to precede the
public key data so that you can just skip it entirely without having
to parse all of the MPI's. Additionally, the differences between the
different session key packets could have been reduced and aligned to
be similiar to the encrypted data packet so that the same header
fields are aligned at the same offsets for all packet types and only
thes differing fields are at different offsets.

*phew*. Excuse the rant. I have just been through implementation of a
key parser and will calm down any minute now.

Regards

-- 
	Ingo Luetkebohle / [email-masked] / Student of Bioinformatics
/
| Cross-Platform OpenPGP: http://xpg.sourceforge.net/
|
| Fargonauten.DE sysadmin; Gimp Registry maintainer;
| FP: 3187 4DEC 47E6 1B1E 6F4F  57D4 CD90 C164 34AD CE5B

---

From: Werner Koch <[email-masked]>
Date: 24 Aug 2001 18:51:28 +0200

> key material.  If you wanted to leave out the material between the

I agree with your proposal.

  Werner

---

From: "Michael Young" <[email-masked]>
Date: Fri, 24 Aug 2001 13:44:45 -0400

-----BEGIN PGP SIGNED MESSAGE-----

> specifier and then have a 0 symmetric algorithm value for "no

Of course.  But we already have a pre-S2K byte, for compatibility
with PGP2, which won't go away.

> public key data so that you can just skip it entirely without having

If you plan to do any consistency checking on the parameters,
you'll need parse it anyway.  If you include them in the hash,
then you might be willing to skip the checks sometimes, but
then you'd at least need to digest the material (but admittedly
not interpret it).

Rather than put in a length, I'd just put in the whole public
key packet.  That would also allow the secret key packet to have
its own (independent) version number.

> thes differing fields are at different offsets.

Sure, a clean-slate design might do all of these things.  But our
slate is well-used.  On the whole, that's a good thing ;-).

Most implementations will want to support older formats anyway.
Adding a substantially new format, even if it alone is easier to
parse, means more code than an isolated tweak on the old one.
I wouldn't open the door to any old hack, but this one feels good.