Subject: Re: Some suggestions
From: Jon Callas <[email-masked]>
To: Werner Koch <[email-masked]>, [email-masked]
Cc: [email-masked]
Date: Thu, 30 Apr 1998 16:54:39 -0700

At 02:57 PM 4/28/98 +0200, Werner Koch wrote:

    1) The comment packets are gone.
       Ooops.  How can write code when the specification is changed at 
       will.  I was lucky to find a solution for the moved comment packet
       number from 14 to 16 - and now there is no comment packet at all.
       So what shall I do?  Go back to RFC1991 or stay with comment packet
       of type 16?
   
       Comment packets are very useful:  I use them to store the factorization
       of the ElGamal prime (in case someone wants to check it), store
       a program version number to make debugging easier.  Another use is
       to transport additional informations to other programs in a pipeline.
   
       *Please put the comment packets back into OpenPGP*

The comment packet is gone at the area director's request. The uses you
give for it are good ones, but other protocols with similar features have
also had them removed. However, if you want to carry meta-data in a
pipeline, there's no reason why you can't use packets 60-63 for this. They
are specifically reserved for private or experimental use. 
   
    3) 4 new signature classes 0x14 to 0x17
       which are like 0x10..0x13 but do a hash over all preceding
       user id packets.  This has the advantage of keeping a public
       key certificate small but a signator is still able to sign
       more than one user-id.

    4) A signature class which can used to sign the complete
       public key certificate would be very nice - or is there
       already one which can be used for this purpose?
    
These are both good features for post-V1. Presently, the packets in a
certificate can be re-ordered. Not arbitrarily, but sigs under a given user
id can be reordered, and the user names themselves can be reordered.
Because of this, there's no way to specify what it means for a user id to
be preceding, or what order to hash the whole thing. I think this is a
wonderful use for the extension mechanism -- you could write into an
extension (notation) the values of the other user names you wanted to sign.

	Jon

   

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 4200 Bohannon Drive
Network Associates, Inc.                    Menlo Park, CA 94025
(650) 473-2860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Thu, 30 Apr 1998 16:55:55 -0700
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-openpgp-formats-02.txt
Sender: [email-masked]

The minutes from LA aren't out yet, so I'm going to relate my portion of
them. My apologies for not getting this note out sooner. I wrote 80% of it
last week, and then forgot to finish. I had been wondering why I hadn't
seen it on the list.

The draft I released is one that I'd like to make the "penultimate call."
Think of it as dress rehearsal for last call, or my admitting that there
will be minor things to change.

As you've no doubt seen, the significant changes are some more re-ordering
of sections, and a new section of notes on algorithms, and the new
"five-octet" definite lengths (which actually hold a four-octet number).

I've also done a few other things with algorithms.

Rot-N is gone. There is an algorithm identifier for Elgamal
encrypt-and-sign keys. I have a question on this -- we wanted to deprecate
the usage-types on RSA keys (i.e. separate algorithm numbers for, but the
issues surrounding Elgamal signatures make it apparent that it's good to
have a separate algorithm ID for an encrypt-and-sign Elgamal key. See the
algorithm notes for details. Does this mean, then, that we should
de-deprecate the RSA usage-types? I'd just as soon keep them deprecated
because there are real cryptographic reasons for a separate Elgamal ID.

I added in MD2 as a hash algorithm. There are people who want to do
PGP/X.509 interoperability, and they need an identifier for MD2.

We still don't have an OID for HAVAL. Can someone get one? Having HAVAL in
there is nice, but I'm a lazy SOB and it's easier for me to remove HAVAL
than to get it an OID. I also think that if having HAVAL is important to
the community, then there oughta be one person who would stand up and take
it upon themself to get an OID.

I'm going to go over comments on this draft over the next week or three and
produce a last-call draft. Early revisions will go to the usual gang. If
you have something you really, really want done, let me know. I'll make
sure you get an early revision. I want last call to be quiet, so we can
call this a wrap and then get on to the *real* discussions of what's good
to have in OpenPGP.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 4200 Bohannon Drive
Network Associates, Inc.                    Menlo Park, CA 94025
(650) 473-2860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Tue, 28 Apr 1998 09:21:39 -0800
To: Werner Koch <[email-masked]>, [email-masked]
From: Bill Frantz <[email-masked]>
Subject: Re: Some suggestions
Cc: [email-masked]
Content-MD5: wF/G1p48SbL7xGpW4gXxyw==
Content-MD5-Origin: gizmo.lut.ac.uk
Sender: [email-masked]

At 4:57 AM -0800 4/28/98, Werner Koch wrote:
> 2) We need a new compression algorithm.
>    The ZIP algorithm with id 1 is not described in a RFC and
>    the support in zlib is not documented. I suggest a ZIP
>    algorithm with id 2 which complies to RFC1950.

The version of ZIP in Java 1.1.3 has memory leaks and isn't thread safe.  I
don't know about other implementations using zlib.

-------------------------------------------------------------------------
Bill Frantz       | If hate must be my prison  | Periwinkle -- Consulting
(408)356-8506     | lock, then love must be    | 16345 Englewood Ave.
[email-masked] | the key.     - Phil Ochs   | Los Gatos, CA 95032, USA

Date: Wed, 29 Apr 1998 12:05:34 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: implementing backwards compatibility
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Adam Back <[email-masked]> writes:

> So backwards compatibility with what pgp-2.6.x does I think should be
> viewed as more important than backwards compatibility with
> rfc-1991.txt.

That's okay for apps which support RSA and IDEA. For all others 
backwards compatibilty is only useful for packet formats (and maybe
for command line switches), so that keyservers are able to process 
these messages.

> verify a signature (which is say DSA or Elgamal) rather than refusing
> to process the whole message.  In any case pgp-2.6.x doesn't do either
> of these things generally, I think.

It should be easy to add this to pgp 2.6.3in ( Lutz ? ).

Werner

Date: Wed, 29 Apr 1998 10:38:04 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: implementing backwards compatibility
Sender: [email-masked]

Werner Koch <[email-masked]> writes:
> Adam Back <[email-masked]> writes:
> > you to draw the line at this kind of thing.  It seems that pgp-2.6.x
> > formats were not designed with enough forward compatibility in mind to
> > allow doing this kind of thing without resorting to overloading
> 
> This is true for the implemenations of pgp2.x but not for the
> packet format as described in the rfc.

Ah yes, but PGP 2.6.x isn't quite RFC 1991 compliant, in that it falls
over in a heap when it should report that a new version is required,
or that a particular signature can not be checked, or whatever other
graceful recovery is specified in the circumstances.

Your g10 implementation appears to be the only implementation which is
paying much attention to rfc1991, and pgp-2.6.x is by far the largest
deployed base -- larger than pgp-5.x and g10, and Tom's
implementation.

So backwards compatibility with what pgp-2.6.x does I think should be
viewed as more important than backwards compatibility with
rfc-1991.txt.

> This format is as extensible as OpenPGP (see algorithm identifiers
> and reserved values in the header) although there are some problems
> with the grammar of the packet sequence.  There is no reason for a
> PGP 2 program not to work with other rfc1991 implementations, it
> should just print a warning that that and that algorithm is not
> supported and decryption/verification is not possible.  

There are other implications I think, such as saying that it can not
verify a signature (which is say DSA or Elgamal) rather than refusing
to process the whole message.  In any case pgp-2.6.x doesn't do either
of these things generally, I think.

Adam
-- 
print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

Date: Wed, 29 Apr 1998 09:47:43 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: implementing backwards compatibility
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Adam Back <[email-masked]> writes:

> you to draw the line at this kind of thing.  It seems that pgp-2.6.x
> formats were not designed with enough forward compatibility in mind to
> allow doing this kind of thing without resorting to overloading

This is true for the implemenations of pgp2.x but not for the
packet format as described in the rfc.  This format is as
extensible as OpenPGP (see algorithm identifiers and reserved values
in the header) although there are some problems with the grammar
of the packet sequence.  There is no reason for a PGP 2 program not
to work with other rfc1991 implementations, it should just print
a warning that that and that algorithm is not supported and 
decryption/verification is not possible.  The new packet formats 
for packet types > 15 are a problem but as long as they are put
at the end of a message, a pgp 2 app should print a warning that 
a newer version is needed (pgp2 does so in some cases).

Werner

> comment fields.
> 
> In summary IF the openPGP application chooses to implement the MAY
> cipher RSA and the MAY cipher IDEA, then you can have backwards
> compatibility with pgp-2.6.x.
> 
> This doesn't necessarily work with multiple crypto recipients, but we
> already have problems with that: when one recipient can only cope with
> IDEA because he has a pgp-2.6.x client, and another recipient has
> implemented only the MUST options of openPGP you have no overlap in
> cipher suite.  (ie using 3DES no longer works because pgp-2.6.x can't
> understand it, etc).
> 
> 
> As a comment to Hal and Jon, I think that the PGP implementation could
> use some improvement in the area of auto-detecting pgp-2.6.x and
> reacting accordingly -- I receive messages from people using pgp-5.x
> with RSA implemented, and the message is RSA and IDEA encrypted but
> has (I think) DSA signatures contained even though the user also has
> an RSA key.  (Either that or is inserting a pgp5.x only packet which
> otherwise throws pgp-2.6.x).
> 
> Adam
> -- 
> print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`
> 

Date: Tue, 28 Apr 1998 18:47:33 -0400
From: [email-masked]
To: Adam Back <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: implementing backwards compatibility (Re: Some suggestions)
Sender: [email-masked]

On Tue, 28 Apr 1998, Adam Back wrote:

> An implementor is able within the OpenPGP spec I think to write an
> openPGP implementation which is largely backwards compatible with
> pgp-2.6.x.

Actually there are enough enumerated points to allow it to be completely
compatible.

> Then, in addition you need to interpret a pgp-2.6.x formatted public
> key as an implicit encoding of the fact that the sending application
> can only cope with pgp-2.6.x packets, and only cope with algorithms
> IDEA, MD5, and RSA.
> 
> I think this should work.

It would, but you might want to update your RSA key to v4 (though that
would bring in the keyid problem) to say that you can do all of the new
stuff.

> It gets tricky when your application is creating clear signed
> signatures -- you don't know who the message is targetted at -- so to
> follow the backwards compatibility reasoning to it's logical
> conclusion this implies that all clear signed messages (or at least
> those where you don't know who will later wish to verify them) should
> only use MD5, and RSA.

Just doing multiple signatures is an issue.

> <why not MD5...>

> It would have been possible I think to hide an Elgamal/DSA key in a
> pgp2.6.x format packet (for example in a comment field); using this
> method we could have had full backwards compatibility.  (A similar
> trick is used in the move from SSLv2 to SSLv3.)  (Similar kinds of
> packet upgrades would have allowed backwards compatiblity for
> signatures and encrypted information for multiple recipients with some
> recipients being openPGP new algorithms over pgp-2.6.x).

There is nothing within the V3 packet format precluding DSA keys.  They
can be output with 3 as the version, and the creation time and valid days
fields:

BEGIN PGP PUBLIC KEY BLOCK-----
Version: OpenPrivacy 0.9

=jl4k
END PGP PUBLIC KEY BLOCK-----

> As a comment to Hal and Jon, I think that the PGP implementation could
> use some improvement in the area of auto-detecting pgp-2.6.x and
> reacting accordingly -- I receive messages from people using pgp-5.x
> with RSA implemented, and the message is RSA and IDEA encrypted but
> has (I think) DSA signatures contained even though the user also has
> an RSA key.  (Either that or is inserting a pgp5.x only packet which
> otherwise throws pgp-2.6.x).

The problem is that there are problems with 2.6.x and that is why it is
being dumped in favor of OpenPGP.  My V3 handling does "the right thing"
most places, so a 2.6.1998 is possible, but why bother?  If you are going
to move at all, OpenPGP is not that much of a jump.  If you can't move,
then there is no reason to do partial stuff

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Tue, 28 Apr 1998 22:05:30 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: implementing backwards compatibility (Re: Some suggestions)
Sender: [email-masked]

Werner Koch <[email-masked]> writes:
> Lindsay Mathieson <[email-masked]> writes:
> 
> > break existing implementations and compatibility is one of the objectives
> > for the spec.
> 
> and why do we have identifiers for ElGamal, HAVAL or ECC ?  This
> would break existing implementations too.

An implementor is able within the OpenPGP spec I think to write an
openPGP implementation which is largely backwards compatible with
pgp-2.6.x.

I think the trick is to use the algorithm capability information in
the public keys for people you are sending encrypted messages to to
decide which algorithms you can use in your message, and which packet
formats they will understand.

Then, in addition you need to interpret a pgp-2.6.x formatted public
key as an implicit encoding of the fact that the sending application
can only cope with pgp-2.6.x packets, and only cope with algorithms
IDEA, MD5, and RSA.

I think this should work.

It gets tricky when your application is creating clear signed
signatures -- you don't know who the message is targetted at -- so to
follow the backwards compatibility reasoning to it's logical
conclusion this implies that all clear signed messages (or at least
those where you don't know who will later wish to verify them) should
only use MD5, and RSA.

This last option is not that attractive because:

a) RSA is a MAY cipher in openPGP due to patents; 

b) MD5 is mildly depracted because of Dobbertins partial attack on it
being read as indicating the increased likelihood of stronger future
attacks; 

c) MD5 has smaller output size than SHA1 the main alternative;

d) to use the approach it requires that the open PGP user HAS an RSA
key and several PGP Inc 5.x implementations do not support RSA, and
those that do support it do not automatically generate one at the same
time as the ElGamal/DSA keyset.

It would have been possible I think to hide an Elgamal/DSA key in a
pgp2.6.x format packet (for example in a comment field); using this
method we could have had full backwards compatibility.  (A similar
trick is used in the move from SSLv2 to SSLv3.)  (Similar kinds of
packet upgrades would have allowed backwards compatiblity for
signatures and encrypted information for multiple recipients with some
recipients being openPGP new algorithms over pgp-2.6.x).

However at this stage, doing this could not be made compatible with
existing PGP 5.x implementations, and it is kind of ugly, and the
directive of `limited backwards compatibility' it seems to me allows
you to draw the line at this kind of thing.  It seems that pgp-2.6.x
formats were not designed with enough forward compatibility in mind to
allow doing this kind of thing without resorting to overloading
comment fields.

In summary IF the openPGP application chooses to implement the MAY
cipher RSA and the MAY cipher IDEA, then you can have backwards
compatibility with pgp-2.6.x.

This doesn't necessarily work with multiple crypto recipients, but we
already have problems with that: when one recipient can only cope with
IDEA because he has a pgp-2.6.x client, and another recipient has
implemented only the MUST options of openPGP you have no overlap in
cipher suite.  (ie using 3DES no longer works because pgp-2.6.x can't
understand it, etc).

As a comment to Hal and Jon, I think that the PGP implementation could
use some improvement in the area of auto-detecting pgp-2.6.x and
reacting accordingly -- I receive messages from people using pgp-5.x
with RSA implemented, and the message is RSA and IDEA encrypted but
has (I think) DSA signatures contained even though the user also has
an RSA key.  (Either that or is inserting a pgp5.x only packet which
otherwise throws pgp-2.6.x).

Adam
-- 
print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

Date: Tue, 28 Apr 1998 21:18:46 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-openpgp-formats-02.txt
Mail-Followup-To: [email-masked]
Sender: [email-masked]

[email-masked] writes:

> jump to V4.  Otherwise you create a PGP 2.6.2-plus implicit within OpenPGP
> and I think this is a bad idea.  When there is a V3 way of doing things,
> it should meet the old RFC completely since the single reason to do things
> that way is to be backward compatible.  Otherwise things should be done

I did this for GNUPG because when I started, I didn't know any 
description of PGP 5 packet formats so I had to to use RFC1991
with only one extension (partial header length); this implementation
is pretty compliant to RFC1991, due to the fact that this rfc is not
specific in some parts :-)

This isn't a perfect solution and so I plan to migrate to v4 as soon
as OpenPGP is stable (actually I can already process v4 packets).

Werner

Date: Tue, 28 Apr 1998 20:44:46 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: OID for TIGER/192 ?
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Hi,

Does anyone know whether there is an registered ASN OID for
TIGER/192 or a way to register this algorithm?

Werner

Date: Tue, 28 Apr 1998 20:33:13 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Cc: IETF OpenPGP <[email-masked]>
Subject: Re: Some suggestions (zlib info, and a correction)
Mail-Followup-To: [email-masked], IETF OpenPGP <[email-masked]>
Sender: [email-masked]

[email-masked] writes:

> gzip(?) style header in front and crc at the end.  This is undocumented
 
 zip header, gzip is just another header in front of it.

> It would be reasonable to use a new algorithm ID to add a direct zlib
> feature. 

That's what I'm requesting.

Werner

Date: Tue, 28 Apr 1998 14:06:28 -0400
From: [email-masked]
To: Werner Koch <[email-masked]>
cc: IETF OpenPGP <[email-masked]>
Subject: Re: Some suggestions (zlib info, and a correction)
Sender: [email-masked]

On Tue, 28 Apr 1998, Werner Koch wrote:

> Lindsay Mathieson <[email-masked]> writes:
> 
> > Why not just document the usage of zlib - A new compression algorithm would
> > break existing implementations and compatibility is one of the objectives
> > for the spec.
> 
> PGP used an early version of zlib which was limited to a 13 bit
> compression window, the RFC documented zlib does not have this
> limitation.  It's okay to support the old version, but why should
> I not use a newer (and documented) one as an option?

The other zlibism is that I still need to pass the value -15 in
inflateInit2 instead of using InflateInit since the latter will place a
gzip(?) style header in front and crc at the end.  This is undocumented
(except maybe in inflate.c)

It would be reasonable to use a new algorithm ID to add a direct zlib
feature. 

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Tue, 28 Apr 1998 13:33:02 -0400
From: [email-masked]
Reply-To: [email-masked]
To: Werner Koch <[email-masked]>
cc: IETF OpenPGP <[email-masked]>
Subject: Re: Some suggestions
Sender: [email-masked]

On Tue, 28 Apr 1998, Werner Koch wrote:

> Lindsay Mathieson <[email-masked]> writes:
> 
> > Why not just document the usage of zlib - A new compression algorithm would
> > break existing implementations and compatibility is one of the objectives
> > for the spec.
> 
> PGP used an early version of zlib which was limited to a 13 bit
> compression window, the RFC documented zlib does not have this
> limitation.  It's okay to support the old version, but why should
> I not use a newer (and documented) one as an option?

They actually used infozip's original inflate code when they were cloning
PKzip on unix.  Because DOS and other machines had memory limitations, the
window size was limited to 8K.

One of these days I am going to get a palm pilot and port my lib.  Enough
of SSLeay and zlib are there.  If this works with 5.x, there should be no
reason to continue the limit. 

Also, the algorithm is *not* different, just that PGP 2.6.2's compression
is not strictly compliant with the RFC.  It takes about two minutes to
change this in the PGP 2.6.2 code (at least the decompression side). 

To quote from RFC 1951:

   3.3. Compliance

      A compressor may limit further the ranges of values specified in
      the previous section and still be compliant; for example, it may
      limit the range of backward pointers to some value smaller than
      32K.  Similarly, a compressor may limit the size of blocks so that
      a compressible block fits in memory.

      A compliant decompressor must accept the full range of possible
      values defined in the previous section, and must accept blocks of
      arbitrary size.

around line 141 of src/zinflate.c (in one of the PGP 2.6.2 dists):

#ifndef WSIZE
#  define WSIZE 8192
/* window size--must be a power of two, <= 32K, and equal to that of zip.
 * On 16 bit machines (MSDOS), WSIZE must be <= 16K (32K is possible
 * with a few hacks, see the zip archiver.
 */
#endif

2.6.2 should be fixed (including hacking the DOS version if needed).

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Tue, 28 Apr 1998 13:17:37 -0400
From: [email-masked]
To: Hal Finney <[email-masked]>
cc: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-openpgp-formats-02.txt
Sender: [email-masked]

(this might be a resend).

On Fri, 24 Apr 1998, Hal Finney wrote:

> > > V3 keys can switch to using the new iterated/salted passphrase hashing,
> > > which is a major security improvement.
> >
> > The spec says V4 uses the new, V3 uses the old.  Note that there are only
> > two differences between V3 and V4 secret key packets, and the other is the
> > version number at the head of the packet.  It would be easy to modify
> > things to use V4 S2K protection on V3 keys, but the spec should say this
> > is permitted on a V3 key.
> 
> Does the spec say that V3 keys cannot use string-to-key specifiers,
> and/or that it must use only the Simple S2K?  I don't see that, but maybe
> I am not looking in the right place.  Neither 3.6.X nor 5.5.3 say that.
> 5.5.3 describes the difference in terms of what is encrypted, but doesn't
> prevent you from using the new S2K packets.  Is there someplace else
> where it is mentioned?

Not directly, but the reason for using V3 keys is for backwards
compatibility.  When I import them, they will be in the old passphrase
format if they are encrypted.  If in needed to export them, and wanted to
retain the passphrase protection, they would need to be in the old format.
I can use the new S2K passphrase protection with a V3, but is there then
any reason to still leave it as a V3 key (other than keyid issues)?  If I
am going to use V4 passphrase encryption is there any reason I would not
want to change the version number to 4?

One thing I keep getting stuck on is that there are many places I can keep
V3 as V3, but add extensions, when it seems to make more sense simply to
jump to V4.  Otherwise you create a PGP 2.6.2-plus implicit within OpenPGP
and I think this is a bad idea.  When there is a V3 way of doing things,
it should meet the old RFC completely since the single reason to do things
that way is to be backward compatible.  Otherwise things should be done
using purely V4 methods.

I can hack V3 keyids of new keys (LSBs of the public_key parts of
DSA/DSS).  I can use a one pass signature prefix with a V3 format
signature.  And I can go on.  But these shouldn't be done unless there are
plans to extend some version of PGP 2.6.2 to PGP 2.7.x that might
incorporate some Open PGP features.  Since a PGP 2.7 would be undesirable,
I would think doing anything to extend V3 instead of moving to V4 would be
equally undesirable. 

> > Get a copy of the PKCS-1 spec and try writing something from it.  Without
> > looking at the preformatted number I challenge you to determine the other
> > bytes in the packet.  Even given SSLeay's ASN1 support it takes about 10
> > lines (optimizing more than is proper).  Unless I haven't seen a good
> > version of the spec (is there one beyond that on RSA.com?).
> 
> It is true that you have to be able to read ASN.1 to understand this part
> of PKCS-1.  The actual code requirements are very simple, and perhaps we
> should put them into the spec as you suggest.  Our SHA-1 prefix looks like:

(ASN1 breakout deleted - I assume you don't know ASN.1 by heart and
copied it from the source).

> You follow this by the 20 digest bytes, then pad it with block type
> 1 from PKCS-1 section 8.1.  We could take out the comments and it would
> be pretty concise:
> 
> 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 43, 14, 3, 2, 26, 0x05, 0x00, 0x04, 0x14
> 
> Similar structures could be provided for the other hashes.  This might
> be a better way to do it.

Or if you have SSLeay 0.9.X:

#include <stdio.h>
#include <asn1.h>
#include <objects.h>

int main(int argc, char *argv[])
{
  unsigned char buf[4096], *bp;
  int i, j;
  ASN1_OCTET_STRING s;

  s.data = "0123456789ABCDEFGHIJ";  /* replace with actual hash */
  s.length = 20;

  bp = &buf[4];
  i2d_ASN1_OBJECT(OBJ_nid2obj(OBJ_sn2nid(   "SHA1"   )), &bp);
  ASN1_put_object(&bp, 0, 0, V_ASN1_NULL, V_ASN1_UNIVERSAL);
  j = bp - buf - 4;
  i2d_ASN1_OCTET_STRING(&s, &bp);
  i = bp - buf - 2;
  bp = &buf[2];
  ASN1_put_object(&bp, 1, j, V_ASN1_SEQUENCE, V_ASN1_UNIVERSAL);
  bp = buf;
  ASN1_put_object(&bp, 1, i, V_ASN1_SEQUENCE, V_ASN1_UNIVERSAL);
  i += 2;
  for (j = 0; j < i - 20; j++)
    if ((j & 7) == 7)
      fprintf(stderr, "0x%02x,\n", buf[j]);
    else
      fprintf(stderr, "0x%02x, ", buf[j]);
  fprintf(stderr, "\n");
#if 1
  fwrite(buf, 1, i, stdout);
#endif
  return 0;
}

But this code is as obscure as the description.

The fwrite to stdout allows piping to "asn1parse -inform DER"
Change the "SHA1" to MD5, RIPEMD160, or MD2 (no oid for HAVAL yet), and
change the s.length as needed.  Because the above code is far longer and
more complex than the tables, I didn't do the objects that way.

I have a fuller version that writes out the tail of hasher.c (maybe I
should do that as a .h file, but I only need run it once).

> > > > 12.7
> > But implementors might also want to import secret V3 keys, so will need
> > the general algorithm.  And I don't use any of the FR, FRE or other
> > registers described.  I simply copy the last 8 bytes (actually the cipher
> > block size, but all are 8 so far) of cyphertext into the IV and set the
> > IVcount to zero.
> 
> Yes, I wrote up that long description because I thought you were asking
> how it worked, and Jon put it in the spec as an explicit example of
> how the feedback works.  I think the description in the earlier part
> of the spec was OK but if we do want this kind of long description then
> perhaps we should also do one (or two for the two cases) for the secret
> key encryption as well.

Or at least put a note that it would not be a good idea to hardcode parts
of the method.  The example gives symmetric encryption header specific
stuff instead of being a general description.  Were I reading it I might
use fixed values.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Tue, 28 Apr 1998 18:51:51 +0200
From: Werner Koch <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Some suggestions
Mail-Followup-To: [email-masked], [email-masked]
Sender: [email-masked]

Bill Frantz <[email-masked]> writes:

> The version of ZIP in Java 1.1.3 has memory leaks and isn't thread safe.  I
> don't know about other implementations using zlib.

Is this zlib version 1.0.4, Jul 24th, 1996?
That one is thread safe - it was one of the goals:

  zlib 1.0.4 is a general purpose data compression library.  All the code
  is reentrant (thread safe).  The data format used by the zlib library
  is described by RFCs (Request for Comments) 1950 to 1952 in the files 

And _many_ tools link against this lib.

Werner

Date: Tue, 28 Apr 1998 09:21:39 -0800
To: Werner Koch <[email-masked]>, [email-masked]
From: Bill Frantz <[email-masked]>
Subject: Re: Some suggestions
Cc: [email-masked]
Sender: [email-masked]

At 4:57 AM -0800 4/28/98, Werner Koch wrote:
> 2) We need a new compression algorithm.
>    The ZIP algorithm with id 1 is not described in a RFC and
>    the support in zlib is not documented. I suggest a ZIP
>    algorithm with id 2 which complies to RFC1950.

The version of ZIP in Java 1.1.3 has memory leaks and isn't thread safe.  I
don't know about other implementations using zlib.

-------------------------------------------------------------------------
Bill Frantz       | If hate must be my prison  | Periwinkle -- Consulting
(408)356-8506     | lock, then love must be    | 16345 Englewood Ave.
[email-masked] | the key.     - Phil Ochs   | Los Gatos, CA 95032, USA

Date: Tue, 28 Apr 1998 16:27:10 +0200
From: Werner Koch <[email-masked]>
To: IETF OpenPGP <[email-masked]>
Subject: Re: Some suggestions
Mail-Followup-To: IETF OpenPGP <[email-masked]>
Sender: [email-masked]

Lindsay Mathieson <[email-masked]> writes:

> Why not just document the usage of zlib - A new compression algorithm would
> break existing implementations and compatibility is one of the objectives
> for the spec.

PGP used an early version of zlib which was limited to a 13 bit
compression window, the RFC documented zlib does not have this
limitation.  It's okay to support the old version, but why should
I not use a newer (and documented) one as an option?

Werner

Date: Tue, 28 Apr 1998 16:30:22 +0200
From: Werner Koch <[email-masked]>
To: IETF OpenPGP <[email-masked]>
Subject: Re: Some suggestions
Mail-Followup-To: IETF OpenPGP <[email-masked]>
Sender: [email-masked]

Lindsay Mathieson <[email-masked]> writes:

> break existing implementations and compatibility is one of the objectives
> for the spec.

and why do we have identifiers for ElGamal, HAVAL or ECC ?  This
would break existing implementations too.

Werner

Date: 28 Apr 1998 12:58:24 GMT
From: Lindsay Mathieson <[email-masked]>
Subject: Re: Some suggestions
To: Werner Koch <[email-masked]>, IETF OpenPGP <[email-masked]>
Sender: [email-masked]

> 2) We need a new compression algorithm.
>    The ZIP algorithm with id 1 is not described in a RFC and 
>    the support in zlib is not documented.

Why not just document the usage of zlib - A new compression algorithm would
break existing implementations and compatibility is one of the objectives
for the spec.

Cheers - Linz
--
Lindsay Mathieson
Black Paw Communications
	Using MailCat for Win32 Release Vs 2.7, on April 28, 1998, in Win95 4.0
	http://www.blackpaw.com/

Date: Tue, 28 Apr 1998 14:57:34 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Some suggestions
Mail-Followup-To: [email-masked], [email-masked]
Sender: [email-masked]

Hi,

After browsing through the latest draft I have some remarks:

 1) The comment packets are gone.
    Ooops.  How can write code when the specification is changed at 
    will.  I was lucky to find a solution for the moved comment packet
    number from 14 to 16 - and now there is no comment packet at all.
    So what shall I do?  Go back to RFC1991 or stay with comment packet
    of type 16?

    Comment packets are very useful:  I use them to store the factorization
    of the ElGamal prime (in case someone wants to check it), store
    a program version number to make debugging easier.  Another use is
    to transport additional informations to other programs in a pipeline.

    *Please put the comment packets back into OpenPGP*

 2) We need a new compression algorithm.
    The ZIP algorithm with id 1 is not described in a RFC and 
    the support in zlib is not documented. I suggest a ZIP 
    algorithm with id 2 which complies to RFC1950.

 3) 4 new signature classes 0x14 to 0x17
    which are like 0x10..0x13 but do a hash over all preceding
    user id packets.  This has the advantage of keeping a public
    key certificate small but a signator is still able to sign
    more than one user-id.

 4) A signature class which can used to sign the complete
    public key certificate would be very nice - or is there
    already one which can be used for this purpose?
 
All these enhancements may be OPTIONAL.

Werner

Date: Fri, 24 Apr 1998 18:35:20 -0400
From: [email-masked]
To: Jon Callas <[email-masked]>
cc: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-openpgp-formats-02.txt
Sender: [email-masked]

On Fri, 24 Apr 1998, Jon Callas wrote:

> Let's not worry about V2. The charter of the working group says, "limited
> backwards compatibility" and even RFC 1991 says that you should be
> compatible back one version.

Actually I have some code that handles 2.1 DEKs :).  And signatures ;).

> If you want, I can remove the reference to V2.

I have mixed feelings.  Some really old messages might use the RSAref V2
packets and then would not work, although they could.  But in general it
might be better to err on the other side (if they have such a message they
should have a 2.X version of PGP around that can read it).

But to avoid confusion, removing any reference to V2 is best (and let
implementors who might want it read the old docs and figure out how to add
this - the spec says nothing else about V2 compatibility).

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Fri, 24 Apr 1998 13:53:20 -0700
To: [email-masked], Jon Callas <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-openpgp-formats-02.txt
Cc: [email-masked]
Sender: [email-masked]

At 03:39 PM 4/23/98 -0400, [email-masked] wrote:

   The internal format of what is RSAen/decrypted changed from 2.2 to 2.3,
   but not the version number.  I don't know what the RFC says.
   
   So I can get a version with 2 and the old (pre RSAREF) format DEK.

Let's not worry about V2. The charter of the working group says, "limited
backwards compatibility" and even RFC 1991 says that you should be
compatible back one version.

If you want, I can remove the reference to V2.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 4200 Bohannon Drive
Network Associates, Inc.                    Menlo Park, CA 94025
(650) 473-2860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Fri, 24 Apr 1998 12:42:11 -0700
From: Hal Finney <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-openpgp-formats-02.txt
Cc: [email-masked]
Sender: [email-masked]

> > V3 keys can switch to using the new iterated/salted passphrase hashing,
> > which is a major security improvement.
>
> The spec says V4 uses the new, V3 uses the old.  Note that there are only
> two differences between V3 and V4 secret key packets, and the other is the
> version number at the head of the packet.  It would be easy to modify
> things to use V4 S2K protection on V3 keys, but the spec should say this
> is permitted on a V3 key.

Does the spec say that V3 keys cannot use string-to-key specifiers,
and/or that it must use only the Simple S2K?  I don't see that, but maybe
I am not looking in the right place.  Neither 3.6.X nor 5.5.3 say that.
5.5.3 describes the difference in terms of what is encrypted, but doesn't
prevent you from using the new S2K packets.  Is there someplace else
where it is mentioned?

> > We are relying on PKCS-1 to explain how the byte stream is set up.
> > PKCS-1 does not specify the OIDs for the algorithms we are using, so we
> > provide those here.
>
> Get a copy of the PKCS-1 spec and try writing something from it.  Without
> looking at the preformatted number I challenge you to determine the other
> bytes in the packet.  Even given SSLeay's ASN1 support it takes about 10
> lines (optimizing more than is proper).  Unless I haven't seen a good
> version of the spec (is there one beyond that on RSA.com?).

It is true that you have to be able to read ASN.1 to understand this part
of PKCS-1.  The actual code requirements are very simple, and perhaps we
should put them into the spec as you suggest.  Our SHA-1 prefix looks like:

0x30, /* Universal, Constructed, Sequence */
    0x21, /* Length 33 (bytes following) */
        0x30, /* Universal, Constructed, Sequence */
        0x09, /* Length 9 */
            0x06, /* Universal, Primitive, object-identifier */
            0x05, /* Length 8 */
                43, /* 43 = ISO(1)*40 + 3 */
                14,
                3,
                2,
                26,
            0x05, /* Universal, Primitive, NULL */
            0x00, /* Length 0 */
        0x04, /* Universal, Primitive, Octet string */
        0x14 /* Length 20 */
            /* 20 SHA.1 digest bytes go here */

You follow this by the 20 digest bytes, then pad it with block type
1 from PKCS-1 section 8.1.  We could take out the comments and it would
be pretty concise:

0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 43, 14, 3, 2, 26, 0x05, 0x00, 0x04, 0x14

Similar structures could be provided for the other hashes.  This might
be a better way to do it.

> MD2 was just added and is 128 bits if I remember right.  I didn't ask why,
> but maybe it would be appropriate.

MD2 is used in some existing X.509/SSL signatures.  Although it is only
128 bits there are no partial attacks against it as with MD4 and MD5.

> > > 12.7
> But implementors might also want to import secret V3 keys, so will need
> the general algorithm.  And I don't use any of the FR, FRE or other
> registers described.  I simply copy the last 8 bytes (actually the cipher
> block size, but all are 8 so far) of cyphertext into the IV and set the
> IVcount to zero.

Yes, I wrote up that long description because I thought you were asking
how it worked, and Jon put it in the spec as an explicit example of
how the feedback works.  I think the description in the earlier part
of the spec was OK but if we do want this kind of long description then
perhaps we should also do one (or two for the two cases) for the secret
key encryption as well.

Hal

Date: Fri, 24 Apr 1998 00:23:09 -0400
From: [email-masked]
To: Hal Finney <[email-masked]>
cc: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-openpgp-formats-02.txt
Sender: [email-masked]

On Thu, 23 Apr 1998, Hal Finney wrote:

> > 3.6.2.1, Cipher alg: use Simple S2K
> >
> > ... SHOULD NOT be generated.  The only value for Cipher Alg should be 1 to
> > (IDEA) to maintain compatability, so why not just say 1 instead of saying
> > that you can theoretically use 3DES or CAST to do something you shouldn't
> > be doing?
> 
> A bit farther down, it says "it should be understood, but not generated."
> Perhaps it needs some capital letters?

SHOULD not as opposed to MUST not?  Capitalizing a Should does not make it
a Must, and the only way to generate a cipher alg other than IDEA is with
a new implemetation.  Why say Cipher alg instead of IDEA when you mean
IDEA (to be backward compatible), unless you are trying to say if you want
to be slightly noncompliant it is fine to be noncompliant using 3DES
(which is unpatented and thus would make some sense). 

By saying "Cipher Algorithm" instead of "IDEA" you imply that there is a
reason other than backward version interoperability to use this mode.

> V3 keys can switch to using the new iterated/salted passphrase hashing,
> which is a major security improvement.

The spec says V4 uses the new, V3 uses the old.  Note that there are only
two differences between V3 and V4 secret key packets, and the other is the
version number at the head of the packet.  It would be easy to modify
things to use V4 S2K protection on V3 keys, but the spec should say this
is permitted on a V3 key.

> > 5.2.2
> >
> > The full prefix isn't given, just the OID in ASN1 form.  The fuller
> > version is sequence(sequence(object,null),octet-stream).
> 
> We are relying on PKCS-1 to explain how the byte stream is set up.
> PKCS-1 does not specify the OIDs for the algorithms we are using, so we
> provide those here.

Get a copy of the PKCS-1 spec and try writing something from it.  Without
looking at the preformatted number I challenge you to determine the other
bytes in the packet.  Even given SSLeay's ASN1 support it takes about 10
lines (optimizing more than is proper).  Unless I haven't seen a good
version of the spec (is there one beyond that on RSA.com?).

> > If DSA is used (I know it SHOULD NOT) with a hash with less than 160 bits,
...
> We really don't want to encourage any more use of MD5.

MD2 was just added and is 128 bits if I remember right.  I didn't ask why,
but maybe it would be appropriate.

> My preferred approach is simply to disallow non-SHA hashes with DSA.
> That's what DSS says, after all.

Sounds like there is a missing SHOULD NOT
 
> > 7. Cleartest signature framework
> >
> > "The ASCII armored signature(s)" - for multiple signatures, is each
> > signature individually armored, or are the signature packets concatenated
> > and the whole armored?
> 
> Despite allowing multiple Hash headers at the top of a clearsigned
> message, there is no support at present for multiple signatures in
> clearsigned text in our PGP code.

But assuming I want to implement it, how should I do so?  Or equally
reasonable would be to simply allow one signature per clearsigning.

> > "If there are no such [Hash:] headers, SHA-1 is used.  So V3 Clearsigned
> > messages won't interoperate with V4 implementations?  Or should the
> > default be MD5? 
> 
> What PGP does is if there are no hash headers it saves up the message
> and then when it reads the signature at the bottom it goes back and
> hashes it.  However for backwards compatibility perhaps assuming MD5
> would make sense for OpenPGP.

PGP 2.6.2 probably won't like it, but instead of choking early on the
Hash, I am not sure what it would do beyond saying "invalid" signature.

Worse, and OpenPGP implementation reading a 2.6.2 message would
automatically do a useless SHA1 hash, then have to rewind and do MD5, as
would the existing implementations.

Also the whole point of having headers is to avoiding the rewind
operation.  I could initiate both MD5 and SHA1 hashes on the clearsigned
text (so only RIPEMD160, HAVAL, and MD2 would need to be explicitly
specified).

> > 12.7
> >
> > This describes ONLY the cfb reset for the symmetrical packet.  V3 RSA
> > secret keys also need the cfb reset (between MPIs), and they aren't
> > usually on a 10 byte boundary.
> 
> Perhaps this should be identified as the CFB mode used in symmetrically
> encrypted data packets.

But implementors might also want to import secret V3 keys, so will need
the general algorithm.  And I don't use any of the FR, FRE or other
registers described.  I simply copy the last 8 bytes (actually the cipher
block size, but all are 8 so far) of cyphertext into the IV and set the
IVcount to zero.

> > 13
> >
> > How can a broken hash algorithm leak a DSA secret key? (I would like a
> > reference noting the above interoperability problems, or would this only
> > affect a signing service where I could provide known plaintext).
> 
> I don't know if this is possible.  However a weak hash could allow you
> to forge signatures, as described in Handbook of Applied Cryptography,
> section 11.66(iii).

Forging signatures by forging the hash value is obvious.  However imagine
something like a timestamping service which signs arbitrary text.  I could
send things with known hash values to be signed, like 0, 1, 2, 4, ... I
would have to go back to the mathematics, but that is the origin of the
threat because I might be able to derive the secret key.

But if you want only SHA1 for DSA, and someone breaks SHA1 (without DSA)
this could be interesting.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: 24 Apr 1998 22:54:44 GMT
From: Lindsay Mathieson <[email-masked]>
Subject: Re: PGP Reference Implementation
To: Marshall Clow <[email-masked]>, IETF OpenPGP <[email-masked]>
Sender: [email-masked]

>>The S/MIME had no encryption code it, just hooks for it, with
>instructions on >how to use Crypto++ to fill it in. > Can you give me a
>pointer to it? Thanks!

Sure

See <http://www.imc.org/imc-sfl/>. It is a freeware implementation of
S/MIME v3. Although in its early stages, it's reasonably complete.

--
Lindsay Mathieson
Black Paw Communications
	Using MailCat for Win32 Release Vs 2.7, on April 24, 1998, in Win95 4.0
	http://www.blackpaw.com/

Date: 24 Apr 1998 21:59:6 GMT
From: Lindsay Mathieson <[email-masked]>
Subject: PGP Reference Implementation
To: IETF OpenPGP <[email-masked]>
Sender: [email-masked]

The S/MIME people have put together a quite good reference S/MIME
implementation (though it has the usual irritating Visual C dependancies).
Is there a similar one for PGP, available internationally ?

The S/MIME had no encryption code it, just hooks for it, with instructions on
how to use Crypto++ to fill it in.
--
Lindsay Mathieson
Black Paw Communications
	Using MailCat for Win32 Release Vs 2.7, on April 24, 1998, in Win95 4.0
	http://www.blackpaw.com/

Date: Thu, 23 Apr 1998 15:27:57 -0700
From: Hal Finney <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-openpgp-formats-02.txt
Sender: [email-masked]

> 3.6.2.1, Cipher alg: use Simple S2K
>
> ... SHOULD NOT be generated.  The only value for Cipher Alg should be 1 to
> (IDEA) to maintain compatability, so why not just say 1 instead of saying
> that you can theoretically use 3DES or CAST to do something you shouldn't
> be doing?

A bit farther down, it says "it should be understood, but not generated."
Perhaps it needs some capital letters?

> (this also creates problems if you don't allow promoting V3 secret keys to
> V4 retaining the key id and other associations since you can't use the new
> secret key encryption algorithm). 

It is true that V3 keys have the secret key material encrypted slightly
differently, with the bit lengths in the clear.  However most of what
is exposed is known values anyway.  The size of n and e is known, the
sizes of p, q, u and d can be guessed to within a few bits.  So there is
not much harm in exposing them.  PRZ originally designed it like this to
have less known plaintext which would give a cryptanalyst a possible
opening.

V3 keys can switch to using the new iterated/salted passphrase hashing,
which is a major security improvement.

> 4.2.2.3 Five octet lengths
>
> Nowhere does it say this SHOULD NOT be used after partial body lengths. 
> So can it occur in place of the One or Two octet lengths?  If the idea was
> to mimmic the old style CTB, I would think not. 

4.2.2.4 describes the partial body length header, and says, "Another
length header (of one of the three types) follows that portion."
The "three types" should probably be enumerated as "one-octet, two-octet,
or partial", or else we should say "four types".  As TZ says, the former
seems preferable, with the five octet length used only at the start of
the packet.

> 5.2.2
>
> The full prefix isn't given, just the OID in ASN1 form.  The fuller
> version is sequence(sequence(object,null),octet-stream).

We are relying on PKCS-1 to explain how the byte stream is set up.
PKCS-1 does not specify the OIDs for the algorithms we are using, so we
provide those here.

> If DSA is used (I know it SHOULD NOT) with a hash with less than 160 bits,
> I would suggest the data be padded with zeros on the left, or repeat the
> hash result.  What about a hash with >160?  I would suggest the rightmost
> (least significant) 160 bits. 
>
> A reason to do this might be to use one hash algorithm for both V3 and V4
> signatures, which would mean MD5.

We really don't want to encourage any more use of MD5.

I also think we should stick to SHA-1 with DSA signatures.  If a different
hash is used, the client MUST expose the hash to the user so he can know
whether a strong one was used.  Otherwise, if one of our supported hashes
were eventually be broken, someone could forge a DSA signature using the
weak hash, and the user would think the signature is OK.

My preferred approach is simply to disallow non-SHA hashes with DSA.
That's what DSS says, after all.

> 7. Cleartest signature framework
>
> "The ASCII armored signature(s)" - for multiple signatures, is each
> signature individually armored, or are the signature packets concatenated
> and the whole armored?

Despite allowing multiple Hash headers at the top of a clearsigned
message, there is no support at present for multiple signatures in
clearsigned text in our PGP code.

> "If there are no such [Hash:] headers, SHA-1 is used.  So V3 Clearsigned
> messages won't interoperate with V4 implementations?  Or should the
> default be MD5? 

What PGP does is if there are no hash headers it saves up the message
and then when it reads the signature at the bottom it goes back and
hashes it.  However for backwards compatibility perhaps assuming MD5
would make sense for OpenPGP.

> 12.7
>
> This describes ONLY the cfb reset for the symmetrical packet.  V3 RSA
> secret keys also need the cfb reset (between MPIs), and they aren't
> usually on a 10 byte boundary.

Perhaps this should be identified as the CFB mode used in symmetrically
encrypted data packets.

> 13
>
> How can a broken hash algorithm leak a DSA secret key? (I would like a
> reference noting the above interoperability problems, or would this only
> affect a signing service where I could provide known plaintext).

I don't know if this is possible.  However a weak hash could allow you
to forge signatures, as described in Handbook of Applied Cryptography,
section 11.66(iii).

Hal

Date: Thu, 23 Apr 1998 14:07:39 -0700
From: Hal Finney <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-openpgp-formats-02.txt
Cc: [email-masked]
Sender: [email-masked]

> The internal format of what is RSAen/decrypted changed from 2.2 to 2.3,
> but not the version number.  I don't know what the RFC says.

I don't think we should try to support those old V2.2 messages in OpenPGP.
That code has been long, long superceded.  Anyone running PGP 2.2 should
upgrade to at least 2.6.2.

Hal

Date: Thu, 23 Apr 1998 15:39:19 -0400
From: [email-masked]
To: Jon Callas <[email-masked]>
cc: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-openpgp-formats-02.txt
Sender: [email-masked]

On Thu, 23 Apr 1998, Jon Callas wrote:

> At 02:16 PM 4/23/98 -0400, [email-masked] wrote:
>    5.1 PKESKPs
>    
>    "An implementation should accept, but not generate a version of 2, which
>    is equivalent to V3 in all other respects".
>    
>    Isn't V2 the old format using "1 [16 byte session key] [cksum]"  instead
>    of the PKCS-1 block type 02 for the ESK.  PGP 2.3?
>    
> As I understand it, the only difference between V2 and V3 was version
> number change; it was part of the shift to the RSAREF-based code, and the
> version number shift was to force an upgrade to the RSAREF version.
> 
> 	Jon

The internal format of what is RSAen/decrypted changed from 2.2 to 2.3,
but not the version number.  I don't know what the RFC says.

So I can get a version with 2 and the old (pre RSAREF) format DEK.

http://www.chem.swin.edu.au/~graeme/pgformat/pgformat_1.html

Note: packets that contain a version byte of 2 will contain a version
byte of 3 when using versions of PGP >= 2.6 after 9/1/94.

Page 7 has the version (==2) byte.

Page 10 describes the DEK...

The DEK has no CTB packet framing. The DEK is stored packetless and naked,
with padding, encrypted inside the MPI in the RSA public-key-encrypted
packet. 

[in the following it says "message digest", but means DEK]

PGP versions 2.3 and later use a new format for encoding the message
digest into the MPI in the signature packet. (This format is not presently
based on any RFCs due to the use of the IDEA encryption system.) This
format is accepted but not written by version 2.2. The older format used
by versions 2.2 and earlier is also accepted by versions up to 2.4, but
the RSAREF code in 2.5 is unable to cope with it.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Thu, 23 Apr 1998 15:19:17 -0400
From: [email-masked]
To: Jon Callas <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Before I forget - two more spec questions
Sender: [email-masked]

On Thu, 23 Apr 1998, Jon Callas wrote:

> At 12:32 AM 4/22/98 -0400, [email-masked] wrote:
>    1. I didn't read over the draft carefully and I don't have it in front of
>    me. Does it say that the new 5 octet 0xff packet-length MUST be the only
>    packet length (i.e. not at the end of partial-lengths)? 
> 
> No, it doesn't. 

Back to the code - I generally interpret this as an error, but it is easy
to fix (introducing another if-then-else case everyhwere).

> Incidentally, I was talking to PhilZ, who has expressed a desire to have
> partial lengths deprecated. 

Only deprecated for the cases I mentioned (and are fixed in the spec),
i.e. small blocks, headers, etc. or for everything?  They can be useful if
you wanted to use PGP in a stream to do something like SSL does.

They can also be deprecated for compression without much of a problem.

Maybe even Symmetrically encrypted packets (with a "look-for-eof" like
compression) since they end when they end.

Literals have problems since you have to find the signature(s) at the end.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Thu, 23 Apr 1998 11:30:31 -0700
To: [email-masked], [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-openpgp-formats-02.txt
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 02:16 PM 4/23/98 -0400, [email-masked] wrote:
   5.1 PKESKPs
   
   "An implementation should accept, but not generate a version of 2, which
   is equivalent to V3 in all other respects".
   
   Isn't V2 the old format using "1 [16 byte session key] [cksum]"  instead
   of the PKCS-1 block type 02 for the ESK.  PGP 2.3?
   
As I understand it, the only difference between V2 and V3 was version
number change; it was part of the shift to the RSAREF-based code, and the
version number shift was to force an upgrade to the RSAREF version.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 4200 Bohannon Drive
Network Associates, Inc.                    Menlo Park, CA 94025
(650) 473-2860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Thu, 23 Apr 1998 14:16:54 -0400
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]
cc: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-openpgp-formats-02.txt
Sender: [email-masked]

5.1 PKESKPs

"An implementation should accept, but not generate a version of 2, which
is equivalent to V3 in all other respects".

Isn't V2 the old format using "1 [16 byte session key] [cksum]"  instead
of the PKCS-1 block type 02 for the ESK.  PGP 2.3?

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Thu, 23 Apr 1998 11:06:57 -0700
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Before I forget - two more spec questions
Cc: [email-masked]
Sender: [email-masked]

At 12:32 AM 4/22/98 -0400, [email-masked] wrote:
   1. I didn't read over the draft carefully and I don't have it in front of
   me. Does it say that the new 5 octet 0xff packet-length MUST be the only
   packet length (i.e. not at the end of partial-lengths)? 

No, it doesn't. 

Incidentally, I was talking to PhilZ, who has expressed a desire to have
partial lengths deprecated. 
   
	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 4200 Bohannon Drive
Network Associates, Inc.                    Menlo Park, CA 94025
(650) 473-2860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Thu, 23 Apr 1998 13:59:10 -0400
From: [email-masked]
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-openpgp-formats-02.txt
Sender: [email-masked]

On Thu, 23 Apr 1998 [email-masked] wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the An Open Specification for Pretty Good Privacy 
> Working Group of the IETF.
> 
> 	Title		: OpenPGP Message Format
> 	Author(s)	: R. Thayer, J. Callas, L. Donnerhacke, H. Finney
> 	Filename	: draft-ietf-openpgp-formats-02.txt
> 	Pages		: 54
> 	Date		: 22-Apr-98

3.6.2.1, Cipher alg: use Simple S2K

... SHOULD NOT be generated.  The only value for Cipher Alg should be 1 to
(IDEA) to maintain compatability, so why not just say 1 instead of saying
that you can theoretically use 3DES or CAST to do something you shouldn't
be doing?

It says 'the cipher algorithm number with an implicit use of MD5 and IDEA'
but the cipher algorithm number only means IDEA if it has the value of 1,
so if there is a cipher algorithm number, then the cipher is *NOT*
implicit, but specified by the number.

(this also creates problems if you don't allow promoting V3 secret keys to
V4 retaining the key id and other associations since you can't use the new
secret key encryption algorithm). 

4.2.2.3 Five octet lengths

Nowhere does it say this SHOULD NOT be used after partial body lengths. 
So can it occur in place of the One or Two octet lengths?  If the idea was
to mimmic the old style CTB, I would think not. 

5.2.2

The full prefix isn't given, just the OID in ASN1 form.  The fuller
version is sequence(sequence(object,null),octet-stream).

If DSA is used (I know it SHOULD NOT) with a hash with less than 160 bits,
I would suggest the data be padded with zeros on the left, or repeat the
hash result.  What about a hash with >160?  I would suggest the rightmost
(least significant) 160 bits. 

A reason to do this might be to use one hash algorithm for both V3 and V4
signatures, which would mean MD5.

7. Cleartest signature framework

"The ASCII armored signature(s)" - for multiple signatures, is each
signature individually armored, or are the signature packets concatenated
and the whole armored?

"If there are no such [Hash:] headers, SHA-1 is used.  So V3 Clearsigned
messages won't interoperate with V4 implementations?  Or should the
default be MD5? 

12.7

This describes ONLY the cfb reset for the symmetrical packet.  V3 RSA
secret keys also need the cfb reset (between MPIs), and they aren't
usually on a 10 byte boundary.

13

How can a broken hash algorithm leak a DSA secret key? (I would like a
reference noting the above interoperability problems, or would this only
affect a signing service where I could provide known plaintext).

--- reply to tzeruch - at - ceddec - dot - com ---

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-openpgp-formats-02.txt
Date: Thu, 23 Apr 1998 09:54:40 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the An Open Specification for Pretty Good Privacy 
Working Group of the IETF.

	Title		: OpenPGP Message Format
	Author(s)	: R. Thayer, J. Callas, L. Donnerhacke, H. Finney
	Filename	: draft-ietf-openpgp-formats-02.txt
	Pages		: 54
	Date		: 22-Apr-98
	
   This document is maintained in order to publish all necessary
   information needed to develop interoperable applications based on
   the OpenPGP format. It is not a step-by-step cookbook for writing an
   application. It describes only the format and methods needed to
   read, check, generate and write conforming packets crossing any
   network. It does not deal with storage and implementation questions.
   It does, however, discuss implementation issues necessary to avoid
   security flaws.
 
   Open-PGP software uses a combination of strong public-key and
   symmetric cryptography to provide security services for electronic
   communications and data storage.  These services include
   confidentiality, key management, authentication and digital
   signatures. This document specifies the message formats used in
   OpenPGP.

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-openpgp-formats-02.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-openpgp-formats-02.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-openpgp-formats-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-openpgp-formats-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-openpgp-formats-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Wed, 22 Apr 1998 23:16:01 -0400
From: [email-masked]
To: [email-masked]
Subject: Announcing: opgp98.tgz
Sender: [email-masked]

The main change is that everything in the library is renamed with PGP_ as
a prefix to avoid namespace collisions.  More things work including upto
16 recipients and/or one passphrase for encryption.  The last 2.6.2 bug
has been squashed (passphrased secret keys that were not 8N bits long).
Some slight restructuring and cleanup.  Also now works with tempfiles as
well as pipes.

at www.cryptography.org, soon to be in new, and then libraries.

I left a sed script in the goodies directory if you have some of your own
test programs that need fixing.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Wed, 22 Apr 1998 00:32:23 -0400
From: [email-masked]
To: Jon Callas <[email-masked]>
cc: [email-masked]
Subject: Before I forget - two more spec questions
Sender: [email-masked]

1. I didn't read over the draft carefully and I don't have it in front of
me. Does it say that the new 5 octet 0xff packet-length MUST be the only
packet length (i.e. not at the end of partial-lengths)? 

2. You have multiple hashes for Clearsigned messages, but don't cover
the format of the signatures themselves.  Is it merely a bunch of
concatenated signature packets?  Or is there a -----BEGIN PGP SIG... for
each of them?  Can they be nested?  Does nesting involve dash escaping?

Since I don't have any example of a multiple signature clearsigned message
I don't quite understand how this is to work.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Sun, 19 Apr 1998 01:14:26 -0400
From: [email-masked]
To: [email-masked]
Subject: Re: 11.2 Dual KeyIDs for RSA keys?
Sender: [email-masked]

On Sat, 18 Apr 1998, Jim Gillogly wrote:

> tzeruch wrote:
> > Generally, I think it would make sense to promote RSA keys to V4 format
> > (and assuming a V4 keyserver), but be able to export them in V3 format
> > when necessary.  The keyserver could find the key given either the V3 or
> > V4 keyid.
> 
> Looking forward to a "semantics" document (if it comes to that) to
> supplement the formats document, I'm uncomfortable making an explicit
> linkage between the V3 and V4 format RSA keys unless we have a good
> model of what signatures mean in this case.  If a signer signs one or
> the other format, would you assume that signature has the same meaning
> for the other format?  Would you have the Web of trust form the union
> of signatures on the two styles of key?  I suppose it makes sense, but
> I'd want to think through the implications further.  Certainly it would
> be sufficient to have each of your signers sign both formats, but it
> seems overly tricky to have to check a signature by failing, then
> converting the key to the other format and trying again.
> 
> 	Jim Gillogly

The actual essence of the key is the modulus and exponent in the case of
an RSA key (actually the Modulus - exponents would be subkeys).  So a V3,
and a V4 RSA key should mean the same "persistent identity" wherever the
N/E pair appears.  Same things applies for the public key parameter of DSS
or DH keys.

There is even a metacert group apparently trying to standardize on
something that will encompass all usages so one set of key parameters will
work everywhere.

About a year ago I converted my PGP key to an X509 certificate request and
had Verisign sign it when they were doing free user IDs, and should be
able to take a Verisign X509 cert, pull the moduli, create a PGP public
key that can verify the signatures (possibly giving it a high trust
level).

Since my implementation is SSLeay based, I already have most of the X509
style cert handling already available.  Conversion is usually figuring out
how to map the parameters (I usually use a oneline as the userid, and the
NotAfter gives the expiration date, etc.), and calling my keyout5 routine
with the x509 public key data.  I can also take my PGP secret key and
convert it to an SSLeay private key file.

I haven't looked at S/MIME in any detail yet, but from what I have seen it
shouldn't be too difficult to cross the boundary.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Sat, 18 Apr 98 08:58:33 PDT
From: [email-masked] (Jim Gillogly)
To: [email-masked]
Subject: Re: 11.2 Dual KeyIDs for RSA keys?
Sender: [email-masked]

tzeruch wrote:
> Generally, I think it would make sense to promote RSA keys to V4 format
> (and assuming a V4 keyserver), but be able to export them in V3 format
> when necessary.  The keyserver could find the key given either the V3 or
> V4 keyid.

Looking forward to a "semantics" document (if it comes to that) to
supplement the formats document, I'm uncomfortable making an explicit
linkage between the V3 and V4 format RSA keys unless we have a good
model of what signatures mean in this case.  If a signer signs one or
the other format, would you assume that signature has the same meaning
for the other format?  Would you have the Web of trust form the union
of signatures on the two styles of key?  I suppose it makes sense, but
I'd want to think through the implications further.  Certainly it would
be sufficient to have each of your signers sign both formats, but it
seems overly tricky to have to check a signature by failing, then
converting the key to the other format and trying again.

	Jim Gillogly

Date: Sat, 18 Apr 1998 01:55:11 -0400
From: [email-masked]
To: Jim Gillogly <[email-masked]>
cc: [email-masked]
Subject: Re: 11.2 Dual KeyIDs for RSA keys?
Sender: [email-masked]

On Sat, 18 Apr 1998, Jim Gillogly wrote:

> > But then there is a problem.  If I already have a V3 RSA key, and want to
> > use the V4 features, I will have to convert the key.  Considering it as a
> > new key might work, but if I want to sign something to a V3 recipient, I
> > have to use the old ID along with the format (i.e. keyservers won't have
> > the key under the old ID).
> > 
> > Or are you saying I MUST not generate any V3 signatures with V4 RSA keys?
> 
> Could you achieve the desired effect by sending both the V3 and V4
> versions of your RSA key to the keyservers?

Yes and no.  The question is whether keyid 0x12345678 <me@here> is the
same identity as 0xdeadbeef <me@here>.  And then, what if you lookup
me@here and get both keys, how do I say the V4 version is the preferred
key when there is no real way to link them?  And if I revoke one, the
other is still good unless the keyserver links the keys.

Generally, I think it would make sense to promote RSA keys to V4 format
(and assuming a V4 keyserver), but be able to export them in V3 format
when necessary.  The keyserver could find the key given either the V3 or
V4 keyid.

> > Adding these MUST options is reasonable, but then they should be added to
> > the spec.  Letting implementations use RSA keys in both V3 and V4 contexts
> > on the fly is also reasonable.  But something should appear in the spec
> > saying what should be done - Do I check both possible keyids on a V4 RSA
> > signature or just the V4 type?  Am I allowed to export my V4 RSA key in V3
> > format?
> 
> I think this is an implementation and program behavior detail, and thus
> should not be in the formats document.  However, I approve of and applaud
> your approach of being willing to accept many different combinations and
> permutations of formats.

I did my code such that it tries the V4 ID first, and only if that does
not match, it then computes and tries to match on the V3 ID.  When signing
I use a specified keyid (but return the V3 ID by number for my testmode
where a keyid of zero means get the first key supporting the algorithm).

Even if the exact behavior isn't specified, this ambiguity should be noted
so that implementors can take it into account instead of blindly assuming
all RSA keys should use V3 keyids, and saying "Key not found" if I V4sign
a document with an RSA key and place the V4 keyid in the signature (and
looking it up on a keyserver returns the same key, but the ID is only
computed the old way, so it will always look up the key, return it as
correctly formatted, but never be able to find it). 

If an implementation imports a V4 RSA key without error, but doesn't
accept the V4 keyid to match it (for things like signatures), I consider
it a bug.  And only that.  Whether and how to promote/demote the keys can
be implementation dependent.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Fri, 17 Apr 98 21:25:41 PDT
From: [email-masked] (Jim Gillogly)
To: [email-masked]
Subject: Re: 11.2 Dual KeyIDs for RSA keys?
Sender: [email-masked]

> Jon Callas wrote:
> > Within the openPGP framework, a keyid is a 64 bit number, and you can use
> > them at will.

tzeruch wrote:
> Which is fine when there is a one-to-one mapping.  What I am pointing out
> is technically a keyid is either of two possible 64 bit numbers.
> 
> > It's a perfectly fine feature to have V3 => V4 migration, but I'd consider
> > the V4 key to be a completely separate key, and forget that it shares bits
> > with the V3 one.

I see nothing in the formats document that would contradict this.  I
also see nothing that would preclude the possibility of an
implementation keeping track of both the V3 and V4 Key ID and
fingerprints of the key and taking appropriate action if either of them
is seen.  I think it would be unlikely to achieve the desired effect
across the range of PGP-like programs if you were to do V3 sigs with
your V4 key or vice versa, but I feel it's not the place of the formats
document to preclude this usage.

> But then there is a problem.  If I already have a V3 RSA key, and want to
> use the V4 features, I will have to convert the key.  Considering it as a
> new key might work, but if I want to sign something to a V3 recipient, I
> have to use the old ID along with the format (i.e. keyservers won't have
> the key under the old ID).
> 
> Or are you saying I MUST not generate any V3 signatures with V4 RSA keys?

Could you achieve the desired effect by sending both the V3 and V4
versions of your RSA key to the keyservers?

> Adding these MUST options is reasonable, but then they should be added to
> the spec.  Letting implementations use RSA keys in both V3 and V4 contexts
> on the fly is also reasonable.  But something should appear in the spec
> saying what should be done - Do I check both possible keyids on a V4 RSA
> signature or just the V4 type?  Am I allowed to export my V4 RSA key in V3
> format?

I think this is an implementation and program behavior detail, and thus
should not be in the formats document.  However, I approve of and applaud
your approach of being willing to accept many different combinations and
permutations of formats.

	Jim Gillogly

Date: Sat, 18 Apr 1998 00:05:51 -0400
From: [email-masked]
Reply-To: [email-masked]
To: Jon Callas <[email-masked]>
cc: [email-masked]
Subject: Re: 11.2 Dual KeyIDs for RSA keys?
Sender: [email-masked]

On Fri, 17 Apr 1998, Jon Callas wrote:

> At 05:33 PM 4/17/98 -0400, [email-masked] wrote:
>    I brought this up before.  I can create a V4 fingerprint and keyid using
>    an RSA key, but it will be different than the V3 keyid.  I have some kluge
>    working so that PGP 2.6.X will work, but this isn't really addressed.
>    
>    If I use V4 stuff everywhere, shouldn't I use the V4 keyid?  Does any
>    version of PGP match on a V4 (SHA1-hash) RSA Keyid?  (I match on both -
>    the later versions of my code look for a matching V4 keyid and only if it
>    does NOT match will it compute the V3 keyid).
>    
> If you have the same key material that is used in a V3 key and a V4 key, it
> will have a different keyid and fingerprint. This is a feature, not a bug.
> One of the reasons for the new format is that keyids can be forged. 

I didn't say it was a bug.  But there is no mention in the section on
Keyids of the fact that an RSA key will have a different value under V3
v.s. V4.  And says nothing about which one to use in the KeyID fields in
the subpackets I generate.

> Within the openPGP framework, a keyid is a 64 bit number, and you can use
> them at will.

Which is fine when there is a one-to-one mapping.  What I am pointing out
is technically a keyid is either of two possible 64 bit numbers.

> It's a perfectly fine feature to have V3 => V4 migration, but I'd consider
> the V4 key to be a completely separate key, and forget that it shares bits
> with the V3 one.

But then there is a problem.  If I already have a V3 RSA key, and want to
use the V4 features, I will have to convert the key.  Considering it as a
new key might work, but if I want to sign something to a V3 recipient, I
have to use the old ID along with the format (i.e. keyservers won't have
the key under the old ID).

Or are you saying I MUST not generate any V3 signatures with V4 RSA keys?

i.e. that the migration creates an entirely new key (then why migrate?).

If I want to have V3 capabilities, MUST? I leave the key and corresponding
ID in a V3 format?  So a corolary would be "I MUST not generate V4
signatures with a V3 RSA key?

Adding these MUST options is reasonable, but then they should be added to
the spec.  Letting implementations use RSA keys in both V3 and V4 contexts
on the fly is also reasonable.  But something should appear in the spec
saying what should be done - Do I check both possible keyids on a V4 RSA
signature or just the V4 type?  Am I allowed to export my V4 RSA key in V3
format?

I am only pointing out that the current (preliminary) spec doesn't address
this anywhere that I have found, and something should be written in before
it is released.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Wed, 15 Apr 1998 10:05:34 -0700
To: Jon Callas <[email-masked]>, [email-masked]
From: Bill Stewart <[email-masked]>
Subject: Re: Elgamal signatures
Sender: [email-masked]

At 05:43 PM 4/14/98 -0700, Jon Callas wrote:
>Elgamal signatures are large [....] also slow [....]
...
>allow a key to be used for both encryption and signatures. 
....
>Elgmal keys that are used for signing have to have more constraints placed
>on them than encryption keys. The keys that PGP 5.x generates are not
>suitable for signatures. Some facets of this are a serious consideration;

I think tzeruch's position should dominate, that if you make
ElGamal signatures a MAY, then all his ElGamal support code is
"just authentication" and therefore exportable.
Accepting ElGamal signatures may be more important than
creating them, and implementations that create ElGamal keys
MUST (or maybe SHOULD) generate strong keys (or the documentation
should read something analagous to the link(2) manpage,
which says that linking directories can only be done
by root, who is presumed to know what he is doing. :-)

				Thanks! 
					Bill
Bill Stewart, [email-masked]
PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639

Date: Thu, 16 Apr 1998 10:11:57 +0800
From: griffin <[email-masked]>
Reply-To: [email-masked]
Organization: freebie
To: [email-masked]
CC: [email-masked]
Subject: Re: announce: opgp97.tgz - I've gone monolithic
Sender: [email-masked]

[email-masked] wrote:

> It should appear on www.cryptography.org by tomorrow in either the new or
> libraries directory.

I'm more interested in when it will appear in
the European sites ;)

Date: Wed, 15 Apr 1998 18:45:23 -0400
From: [email-masked]
To: [email-masked]
Subject: announce: opgp97.tgz - I've gone monolithic
Sender: [email-masked]

I now have replaced several things with a single pgp5 program.  Apologies
to PGP inc. since I couldn't think of something else to call it for this
release and it is still intended to be a demo of the underlying library. 
If you have fork and pipe, it works in one pass, e.g.

./pgp5 -i FILE -o FILE.pgp -l FILE -1 -t 0 -z -e kid -m MESSAGE

Signs, compresses, and encrypts to kid (keyid), and ascii armors.

./pgp5 -i FILE.pgp -o FILE.out

Will recover the file and indicate the results of the signature check.
This doesn't work everywhere (i.e. when the final step is not a literal or
a text file), but I have an Increment flag for those cases.

There are still some structures (e.g. multiple recipients) I don't do, and
it is one file at a time, but I have full control of all the algorithms
used internally and should be able to correctly generate or process
anything which is in the OpenPGP specification and exists in SSLeay 0.9.0
(plus SAFER/SK128 and HAVAL).  And the source is still under 3500 lines.

clear-signing and testing clearsigned messages are done in two other
auxillary programs.  There is a new-to-old CTB program for 2.6.2 support
and some keyring routines.

A few internal improvements have been made since 95b7 - ROTN is out,
armoring is many times faster.  Lots of things from earlier versions are
much improved.  If you haven't upgraded in a while, check this version
out.  It requires SSLeay 0.9.0.  Safer and Haval URLs are included and can
be compiled in by simply installing the .c and .h files.

Thanks to all who are bearing with me with a work in progress.

It should appear on www.cryptography.org by tomorrow in either the new or
libraries directory.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Tue, 14 Apr 1998 17:55:21 -0700
To: [email-masked], Jon Callas <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: Elgamal signatures
Cc: [email-masked]
Sender: [email-masked]

At 06:40 PM 4/14/98 -0400, [email-masked] wrote:

   I assume you are going to leave ROT-N and SAFER/SK128 in?  The former is
   specifically designed to be weak.
   
ROT-N is out, SAFER is in. 

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 4200 Bohannon Drive
Network Associates, Inc.                    Menlo Park, CA 94025
(650) 473-2860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Tue, 14 Apr 1998 17:43:56 -0700
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Elgamal signatures
Sender: [email-masked]

There are a number of issues around Elgmal signatures, as opposed to (say)
DSA signatures. These are the ones I can remember off the top of my head:

Al discrete-log signature systems have as part of their real strength the
size of the hash function as well as the size of the key. Because of
birthday attacks, the strength of the hash is half its length (a.k.a. the
square root of the maximum hash number) -- so a 160 bit hash has a strength
of 80 bits. This is alleged to be roughly the same strength as a 1024 bit
key. The downside of this is that there is no reason to make a key longer
than 1024 bits with no longer hashes, and in fact it is arguably a security
weakness. The counter-argument to this is that without the longer keys,
there's no reason to have longer hashes. (For the last couple of months,
I've been waiting for someone to suggest a longer hash, like say
Haval-5-256, or to even agree with my hints that such a thing would be a
good idea.)

Elgamal signatures are large when compared to DSA sigs -- two full-key
MPIs, as opposed to two 160-bit MPIs. The counter-argument is, "so what?"
They're also slow -- they require three exponentiations, as opposed to only
one for DSA.

Elgamal signatures allow a key to be used for both encryption and
signatures. The counter argument is that many protocol designers think this
is a Bad Thing, that keys should be single-purpose. The counter-counter
argument is, "you design your protocols, I'll design mine." In other words,
if there is *some* protocol that has a good use for a sual-use key, then
the meta-protocol shouldn't forbid it.

Elgmal keys that are used for signing have to have more constraints placed
on them than encryption keys. The keys that PGP 5.x generates are not
suitable for signatures. Some facets of this are a serious consideration;
unlike some signature flaws that cause bad signatures, these cause loss of
your key. There's a good discussion of these security considerations in
Menezes, van Oorschot, and Vanstone, pp454-456. You can also find an
interesting paper on mere forgeries at
<ftp://ftp.inf.ethz.ch/pub/publications/papers/ti/isc/ElGamal.ps>

There are also some other fussy things you can do to forge signatures, like
make r and s roughly twice the size of the prime p. It all just means you
have to be extra careful with Elgamal sigs.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 4200 Bohannon Drive
Network Associates, Inc.                    Menlo Park, CA 94025
(650) 473-2860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Tue, 14 Apr 1998 23:42:44 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: Elgamal signatures
Sender: [email-masked]

Jon Callas <[email-masked]> writes:
> I've been writing up a section on the care needed to select Elgamal keys so
> that the resulting signatures are strong. In going through all of this, I
> can't help but wonder if it's worth it.
> 
> Should we forego Elgamal signatures in the spec and make Elgamal only an
> encryption algorithm?

One advantage of Elgamal signatures is that they are defined for hash
algorithms producing more than 160 bits of output.

So this might be nice for RIPE-MD with larger output to provide a more
secure option than 160 bits.  When you take into account birthday
attacks, at 80 bits DSA doesn't look that strong, if we are talking
about building in future proofing.

For this reason I'd like to see Elgamal sigantures remain as a MAY.

(And I'd also like by implication to see a larger output hash function
in).

Adam

Date: Tue, 14 Apr 1998 18:40:56 -0400
From: [email-masked]
To: Jon Callas <[email-masked]>
cc: [email-masked]
Subject: Re: Elgamal signatures
Sender: [email-masked]

On Tue, 14 Apr 1998, Jon Callas wrote:

> I've been writing up a section on the care needed to select Elgamal keys so
> that the resulting signatures are strong. In going through all of this, I
> can't help but wonder if it's worth it.

You could also simply point to the external info, or just add info on how
to detect weak signatures.

> Should we forego Elgamal signatures in the spec and make Elgamal only an
> encryption algorithm?

I would rather leave a reserved number, etc. for it.  DSA limits the
signature size to 160 bits, so even if I create a 4096 bit p, it isn't any
more secure than a 2048 bit p.

Also, since one of the problem is the generators, if anyone wants to add
ElGamal signatures later, it would help if people started using a
generator other than 2 when creating the parameters even if they don't
support ElGamal in the current version.

There is one further complication.  Right now I would leave them in as a
MAY so that all my ring handling code is required for *authentication* and
therefore *possibly* exportable (I actually have a slim version of my
library without any encryption, but it still does clearsigning and
verification using the 3 signature algorithms v.s. the 5 hashes). 

I assume you are going to leave ROT-N and SAFER/SK128 in?  The former is
specifically designed to be weak.

--- reply to tzeruch - at - ceddec - dot - com ---

From: "William H. Geiger III" <[email-masked]>
Date: Tue, 14 Apr 98 17:19:12 -0500
To: Jon Callas <[email-masked]>
Cc: [email-masked]
Subject: Re: Elgamal signatures
Sender: [email-masked]

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

In <[email-masked]>, on 04/14/98 
   at 04:22 PM, Jon Callas <[email-masked]> said:

>I've been writing up a section on the care needed to select Elgamal keys
>so that the resulting signatures are strong. In going through all of
>this, I can't help but wonder if it's worth it.

>Should we forego Elgamal signatures in the spec and make Elgamal only an
>encryption algorithm?

No,

I think that there is substantial interest in Elgamal signatures to
include it in the spec.

I admit I have not given Elgamal a through study but I am currious as to
how an Elgamal key would be secure for encryption and yet not be so for a
signature?

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://users.invweb.net/~whgiii
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 2.6.3a at: http://users.invweb.net/~whgiii/esecure.html                        
- ---------------------------------------------------------------
 
Tag-O-Matic: PATH=C:\DOS;C:\DOS\RUN;C:\WIN\CRASH\DOS;C:\ME\DEL\WIN

Date: Tue, 14 Apr 98 14:45:23 PDT
From: [email-masked] (Jim Gillogly)
To: [email-masked]
Subject: Re: Elgamal signatures
Sender: [email-masked]

Jon sez:
> I've been writing up a section on the care needed to select Elgamal keys so
> that the resulting signatures are strong. In going through all of this, I
> can't help but wonder if it's worth it.
> 
> Should we forego Elgamal signatures in the spec and make Elgamal only an
> encryption algorithm?

Given the potential pitfalls and the fact that the first version
of openpgp-formats is more a description of interoperability with
existing versions (plus a little) than severe groundbreaking, I'm
inclined to agree with this sentiment.

Since there'll be a follow-on document at some distant point in the
future, that'll even give time for more attacks to mature on various
systems... i.e. we may be smarter in a year or two.

It's a good idea to have dissimilar options for each variable, and
we seem to have that already.  The hashing department is the only
one where the main algorithms we're using have very similar structures.

	Jim Gillogly

Date: Tue, 14 Apr 1998 14:22:15 -0700
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Elgamal signatures
Sender: [email-masked]

I've been writing up a section on the care needed to select Elgamal keys so
that the resulting signatures are strong. In going through all of this, I
can't help but wonder if it's worth it.

Should we forego Elgamal signatures in the spec and make Elgamal only an
encryption algorithm?

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 4200 Bohannon Drive
Network Associates, Inc.                    Menlo Park, CA 94025
(650) 473-2860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Tue, 14 Apr 1998 11:08:37 -0400
From: [email-masked]
To: [email-masked]
Subject: update - how to get my latest code
Sender: [email-masked]

My versions have been coming rapidly, so occasionally it took time to
appear in the libraries directory.  There is a new system that will let my
code reappear by the next day at:

http://cryptography.org/cgi-bin/crypto.cgi/new/

(But also remember to look in the libraries directory).

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Mon, 13 Apr 1998 21:49:33 -0400
From: [email-masked]
To: [email-masked]
Subject: Armor CRC clarification
Sender: [email-masked]

Nowhere does it say that CRC applies to each part of an armored message
instead of a cumulative or other system.

Also, I don't know if it belongs in the spec, but is the implementation
supposed to sort the messages in the stream?  I can do cat msg.a* | ./pgpv
as long as they are already in sequence (as of 95b9).

Date: Mon, 13 Apr 1998 17:48:04 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: SecureConnect 1 announcement
Sender: [email-masked]

IMC's popular series of interoperability events for developers continues
with SecureConnect 1 for S/MIME v2, S/MIME v3, PGP/MIME, and OpenPGP.
SecureConnect 1 will be held July 23 and 24, and will cover end-to-end mail
security, specifically using S/MIME v2, S/MIME v3, PGP/MIME, and OpenPGP.
The market for mail clients using these technologies continues to grow, and
the S/MIME v3 and OpenPGP specs are nearing completion. Now is the time for
the industry to make sure that shipping and soon-to-be-shipping products
interoperate. Signed messages require the presence of certificates, and
SecureConnect 1 will also be a place for certificate Authority (CA) vendors
to test the interoperability of the certificates generated by their
products. Further, user agent vendors at SecureConnect 1 will be able to
make sure that their products can create and verify messages that come with
certificates from participating CAs.

More information about SecureConnect 1 can be found at
<http://www.imc.org/imc-secureconnect/>.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Mon, 13 Apr 1998 19:24:53 -0400
From: [email-masked]
To: [email-masked]
Subject: opgp95 beta 7
Sender: [email-masked]

New - I actually documented the calls, though I need to flesh out the
descriptions and insure that the very latest changed didn't damage
anything.

Updated to use SSLeay 0.9.0 (which has builtin CAST and RIPEMD).

The only 2.6.2 routine left is keyout2 which does only V3 rsa keys.

A new ringscan program has been added.

I now use malloc for buffers, hash context, and do symmetrical encryption
using a malloced context, and reorganized many other things.

And it is even a little smaller (2257 lib, 3210 total source lines :).

Date: Sun, 12 Apr 1998 03:23:42 -0400
From: [email-masked]
To: [email-masked]
Subject: Why no one-pass symmetric test packet?
Sender: [email-masked]

I mentioned this earlier in a different context.

One problem is that each public key and passphrase key prepended to the
symmetrically encrypted packet will need to create a context if I want to
do things in one pass.  What would be better is a one-pass-symencrypt
header similar to the one pass sigs which would have the algorithm and the
first 10 bytes so that you could pretest the passphrase keys as they
occured (and the speculative public keys).

Note this also creates a problem if there is ever a cipher with a block
length greater than 8.  Without the 10 byte header there would be no easy
way to determine if a passphrase key actually worked.  And I worry about
the probability of the byte pair matching but with the wrong key.

It would still help to have a checksum on the SKESK, and that too could be
detected (by the key length determined by the algorithm leaving two
bytes).  Or a CRC since random bytes would tend to average to the same
mean value.  Or even an XOR of every byte pair or something.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Sat, 11 Apr 1998 18:00:29 -0400
From: [email-masked]
To: [email-masked]
Subject: Well, I did a pgpv command...
Sender: [email-masked]

Since I added an autodetect to minipgp, it wasn't much of a leap to add a
pipe/fork mechanism.  It accepts armored, encrypted, compressed or
literaled input and goes all the way to plaintext.  Using SSLeay 0.9.0,
the simple benchmarks indicates it is 50% to 100% faster than PGP 5.0 for
linux.  Interestingly enough, dearmoring proved to be a major bottleneck.
The rest (about 80%) of the speed difference was not due to anything I
did, but to Eric Young and Tim Hudson's work in speeding up SSLeay.

This is in the archive opgp95b3.tgz, just uploaded to
www.cryptography.org, or email me with the appropriate legalese about not
exporting it if you want it sooner.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Fri, 10 Apr 1998 11:26:03 -0700
From: [email-masked] (Jim Gillogly)
To: [email-masked], [email-masked]
Subject: Re: RSA Key spec question
Sender: [email-masked]

> At 10:33 AM 4/3/98 -0500, tzeruch - at - ceddec - dot - com wrote:
> >E is 17 in pgp, but often 3 or 65567 elsewhere.  I know why 2**N+1, but is
> >there anything that should be said about this in the spec?
> >
> >(Testing 2.6.2 v.s. SSLeay from long ago proved that any value of E worked
> >in either; But only some could be generated, or would be by default).

Bill Stewart writes:
> The spec says that PKCS1 padding is required for the encrypted
> session key packet, but it doesn't explicitly say that
> in a message with multiple recipients, EVERY encrypted session
> key packet needs to use a different random padding, as opposed to 
> making one copy of m and encrypting it separately with each key.
> This needs to be fixed.
> 
> The issue is preventing the low-exponent attack on RSA,
> which is a particular risk for e=3, but occasionally messages
> will have more than e=17 RSA-using recipients.

Indeed.  My PGP keyring may be odd, but I have several PGP keys
that have exponents other than e=17:  Richard Outerbridge's,
Arnold Reinhold's, David Stoler's, and the IETF Registrar's all
use 65537, and Christopher Drake (0xC0DED00D) has a 69-bit
exponent.  I'm guessing that's not an accidental number. :)

	Jim Gillogly

Date: Thu, 09 Apr 1998 09:24:38 -0700
To: [email-masked]
From: Bill Stewart <[email-masked]>
Subject: Re: RSA Key spec question
Sender: [email-masked]

At 10:33 AM 4/3/98 -0500, tzeruch - at - ceddec - dot - com wrote:
>E is 17 in pgp, but often 3 or 65567 elsewhere.  I know why 2**N+1, but is
>there anything that should be said about this in the spec?
>
>(Testing 2.6.2 v.s. SSLeay from long ago proved that any value of E worked
>in either; But only some could be generated, or would be by default).

The spec says that PKCS1 padding is required for the encrypted
session key packet, but it doesn't explicitly say that
in a message with multiple recipients, EVERY encrypted session
key packet needs to use a different random padding, as opposed to 
making one copy of m and encrypting it separately with each key.
This needs to be fixed.

The issue is preventing the low-exponent attack on RSA,
which is a particular risk for e=3, but occasionally messages
will have more than e=17 RSA-using recipients.

Mentioning that 17, 3, and 65537 are popular values of e
seems worthwhile; it's probably not important to say that
implementations MUST or SHOULD support encrypting with other
values of e, since there's no realy reason to assume they wouldn't.
A more interestng problem is whether implementations SHOULD or MAY
refuse to encrypt to RSA keys with e=1, at least for multiple-
recipient messages.  Are there other categories of keys
that are easily detected as weak, e.g. composites, or 
do you really need to know p and q to detect weak keys?
Are there similar problems for ElGamal / Diffie Hellman?

Section 5.1 of the spec currently says:
> The encrypted value "m" in the above formulas is derived from the
> session key as follows.  First the session key is prepended with a
> one-octet algorithm identifier that specifies the conventional
> encryption algorithm used to encrypt the following Symmetrically
> Encrypted Data Packet.  Then a two-octet checksum is appended which is
> equal to the sum of the preceding octets, including the algorithm
> identifier and session key, modulo 65536.  This value is then padded as
> described in PKCS-1 block type 02 [PKCS1] to form the "m" value used in
> the formulas above.

				Thanks! 
					Bill
Bill Stewart, [email-masked]
PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639

Date: Thu, 9 Apr 1998 22:36:22 -0400
From: [email-masked]
To: [email-masked]
Subject: Update: V4 RSA keys work, if they aren't protected
Sender: [email-masked]

I found a problem with my V4 RSA key export routine.  Now if I don't
passphrase them, PGP 5.0 seems to be able to understand them.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Thu, 9 Apr 1998 18:10:22 -0400
From: [email-masked]
To: [email-masked]
Subject: preannounce: opgp95
Sender: [email-masked]

Lots of fixes, enhancements, etc. to meet the spec as I currently
understand it.  I don't do multiple [P|S]KESKs, multiple 1 pass
signatures, and keymanagement, and I do support ElGamal signatures, so I
am not in 100% compliance.  But it works and can interoperate with other
programs insofar as they meet the spec.

The big news is that everything is now done by one program, i.e. 

cat cryptfile | minipgp5 | minipgp5 | minipgp5 | minipgp5 >plainfile

................dearmor.....decrypt...decompress..deliteral

When not piping, or with onepass sigs, the deliteral will also check the
signature.  And these work with either the old or new CTB format (as long
as the new format isn't fragmented, but I have a preprocessor for that).

And the reverse steps would be

cat plainfile | minipgp5 -l plainfile | \
	minipgp5 -z | minipgp5 -k <uid> >cryptfile.

(signatures are generated detached with or without onepass headers
and assembled using cat).

The minipgp5 program is mostly glue to invoke the proper library routine
and is designed more to allow testing of the library or provide samples of
how to preparse and invoke the functions.  It is not a designed to be a
practical or usable implementation. 

The only difficulty is that with a swiss-army-knife approach, I now have
about 20 options that can be specified, and some must be precise to cause
the right thing to happen (and my checking isn't good, if you ask for both
armoring and compression only one will happen).  In the other direction,
the autodetect is fairly good.

I have updated my awk scripts so they now work with minipgp5 to generate
or check clearsigned messages on OpenPGP messages.

Another big note is that with a ctb conversion program it is now fully
backward compatible - minipgp5 only generates new CTBs, but the tooldctb
program will fix that.  I also removed the SKESK for the case where
everything is 2.x default (and assume 2.x defaults if I see the CTB for a
symmetrical data packet before an ESK).

The old minipgp directory is going away (but all the functions are moving
into the newpgp directory which will likely be renamed).

SSLeay 0.9 is due out in a few days, so I am going to be adapting the
program to use that so you may want to wait.

www.cryptography.org has been backlogged, so if you want an alpha version,
email me with the appropriate "I can legally send to you and you know
about exporting and should not" information.

I also managed to cut the codesize (all .c and .h files are under 3500
lines, not counting safer, haval, and ripemd).

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Tue, 07 Apr 1998 18:42:51 -0700
To: [email-masked] (Ulf =?iso-8859-1?Q?M=F6ller?= ), [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: character set
Sender: [email-masked]

At 01:48 AM 4/8/98 DST, Ulf M=F6ller wrote:
   The draft says that user IDs are encoded in UTF-8. Do the current
   versions of PGP actually do that? My user ID, which I generated with
   PGP 5.0 for Windows, is plain Latin-1.
  =20
Nope, they don't. That means they aren't OpenPGP compliant, and will have
to change that.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 4200 Bohannon Drive
Network Associates, Inc.                    Menlo Park, CA 94025
(650) 473-2860                             =20
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Wed, 8 Apr 98 01:48 CET DST
From: [email-masked] (Ulf =?iso-8859-1?Q?M=F6ller?=)
To: [email-masked]
Subject: character set
Organization: HR13
Sender: [email-masked]

The draft says that user IDs are encoded in UTF-8. Do the current
versions of PGP actually do that? My user ID, which I generated with
PGP 5.0 for Windows, is plain Latin-1.

Date: Tue, 7 Apr 1998 17:27:21 -0400
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]
Subject: Updates - opgp93 soon.
Sender: [email-masked]

I now have more test cases, but the tgz is 4+Mb.  This includes all extra
stuff like blowfish, safer, and haval, and even ROT-N and plaintext.

I recreated a pgpz/pgpunz which can take literal packets directly to/from
pgp5 compressed packets.  These may disappear from the release.   I also
have CTB to rawstream and rawstream to CTB code (which collects tiny
fragments into large ones so they can be used with the rest of my
routines).

(note that the version of pgp 5.0 I use can't accept a raw compressed
packet in either form - but if I encrypt it everything works)

www.cryptography.org has been unattended, so if someone is desparate (and
a US citizen in the US, etc), I can email them.

SSLeay has an impending release which should include CAST and RIPEMD160,
and I am working toward that.  My #define setup now assumes the newer
version as the default (as I understand it will be, since the code isn't
released yet and I don't have it) and has everything turned on that comes
with SSLeay. 

Other changes include V4 RSA keys, fixes to conventional encryption and a
fix that prevented my awk clearsign signature checker from working in
minipgp.  The readme files have been tweaked, and code reorganized.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Mon, 06 Apr 1998 16:43:38 -0300
To: Jon Callas <[email-masked]>
From: [email-masked] (Paulo Barreto)
Subject: Re: On my HAVAL implementation
Cc: [email-masked]
Sender: [email-masked]

At 05:58 PM 98/04/03 -0800, Jon Callas <[email-masked]> wrote:

>At 03:41 PM 3/30/98 -0300, Paulo Barreto wrote:
>
>   1. Though my implementation is indeed public domain, the very algorithm is
>   *not*, as Dr. Yuliang Zheng clearly states in his HAVAL page.  However,
>   he's very liberal in conceding "licenses" (in fact, absolutely no fee is
>   due; Dr. Zheng only wants to keep track of where HAVAL is being used).
>   
>I'm a little concerned about this. It is my understanding of copyright law
>that one can copyright an *implementation* but not an algorithm. I wrote
>Dr. Zheng, and he gave me permission to put it in OpenPGP. However, I am
>still concerned about putting in an algorithm that someone claims
>"copyright" on. Furthermore, we need an OID for it.

I agree with you, but I'm not a lawyer, so I'm not sure about what can be
copyrighted and what can't; this could even be country-dependent.  But
since Dr. Zheng gave permission to use HAVAL in OpenPGP, I don't think this
is a problem anymore.

>Does anyone have an opinion? Should I strike HAVAL? Should I leave it there
>even if it's just a placeholder for later? It's certainly nice to have
>extra hash algorithms, but it is by no means something we should delay
>over. It can always go in 1.1.

Remember that there aren't that many 256-bit fast hashing functions around
(Tiger is only 192-bit, and the only other such a function I know of is J.
Daemen's StepRightUp, which is not widely known), so dropping HAVAL would
be a great loss.

Paulo Barreto.

Date: Mon, 6 Apr 1998 13:18:13 -0400
From: [email-masked]
To: [email-masked]
Subject: Re: Preliminary V4 RSA key support added.  But I can't test...
Sender: [email-masked]

Part of PGP 5.0 wants the format to be MPI-checksum-MPI-checksum... and
another part MPI-MPI-...-checksum, so I can't use pgpv to decrypt using
V4 RSA keys.

I did some major rework to my keypacket input and output routines, but
www.cryptography.org is backlogged.  If anyone need this quickly, please
email me (with a note about your export status).

Also, a new rev of SSLeay should be out in a week or so with CAST and
RIPEMD160 included.

--- reply to tzeruch - at - ceddec - dot - com ---

From: Uri Blumenthal <[email-masked]>
Subject: Re: On my HAVAL implementation
To: [email-masked] (Jon Callas)
Date: Sun, 5 Apr 1998 22:30:57 -0400 (EDT)
Cc: [email-masked], [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

Jon Callas says:
>    1. Though my implementation is indeed public domain, the very algorithm is
>    *not*, as Dr. Yuliang Zheng clearly states in his HAVAL page.  However,
>    he's very liberal in conceding "licenses" (in fact, absolutely no fee is
>    due; Dr. Zheng only wants to keep track of where HAVAL is being used).
>    
> I'm a little concerned about this. It is my understanding of copyright law
> that one can copyright an *implementation* but not an algorithm. I wrote
> Dr. Zheng, and he gave me permission to put it in OpenPGP. However, I am
> still concerned about putting in an algorithm that someone claims
> "copyright" on. Furthermore, we need an OID for it.

I would not be concerned of mere "copyrights" - for example, I say that
DES/SK is "copyrighted" by me and Steve Bellovin. So what? As long as
that ownership is acknowledged and the authors are held harmless,
anybody can do whatever they wish with the algorithm: implement
it, sell the implementation, give the implementation away, etc.

> Does anyone have an opinion? Should I strike HAVAL? Should I leave it there
> even if it's just a placeholder for later? It's certainly nice to have
> extra hash algorithms, but it is by no means something we should delay
> over. It can always go in 1.1.

I think this is a no-brainer. If Dr. Zheng only wants his "ownership"
to be acknowledged (like - "this is HAVAL function invented by Dr. 
Zheng") there is no problem. If however he demands something more
than a mere recognition - you may consider striking the algorithm
out.

The simplest solution is to check with Dr. Zheng and ask what his
requirements are and what his copyright says.
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

Date: Sun, 5 Apr 1998 11:14:44 -0400
From: [email-masked]
To: [email-masked]
cc: Jon Callas <[email-masked]>
Subject: More spec cleanup/suggestions
Sender: [email-masked]

Move section 11 (Ehnanced Key Formats) to 5.5.4 or something else near the
rest of the descriptions.

5.11 "Trust Packet" either needs to describe the existing format or it
should be listed as purely implementation dependant.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Sat, 4 Apr 1998 17:23:13 -0500
From: [email-masked]
To: Jon Callas <[email-masked]>
cc: [email-masked]
Subject: Re: Preliminary V4 RSA key support added.  But I can't test...
Sender: [email-masked]

On Fri, 3 Apr 1998, Jon Callas wrote:

>    I was wrong, it is a V4 packet.  But it uses V3 including keyids for
>    everything else, so I can't find the key on the keyring.
>    
>    I needed to compensate for the checksums unique to RSA secret MPIs.
>    
> Nonetheless, this sounds like a bug in 5.0.

Bug or feature?  It appears that a V4 RSA secret material is handled
identically to V3 secret material.  It appears that the version byte is
ignored unless it is not 3 or 4.

I can make my code do the right thing (for OpenPGP).  As soon as what the
right thing requires is defined.  But it would break 5.0.

Anyone working on an implementation for the Palm Pilot Pro?

--- reply to tzeruch - at - ceddec - dot - com ---

To: [email-masked]
Date: Fri, 3 Apr 1998 14:38:32 -0500
From: [email-masked]
To: [email-masked]
Subject: Preliminary V4 RSA key support added.  But I can't test...
Sender: [email-masked]

On Fri, 3 Apr 1998 [email-masked] wrote:

> Why not, for V4 keys, treat RSA MPIs just like DSA or DH MPIs?

That is, encrypt the MPI whole and not do any resets.  In this case
encrypt all 4 MPIs in a stream starting with the first bitcount octet.

And while I am here, you are storing U (which is iqmp in SSLeay) as part
of the RSA secret key.  Might I suggest (given the rest of the
incompatibilites already there) that we also include dmp1 and dmq1?  And
place those just above U?  I calculate them, but I could calculate U.
(see my getkey2.c and rsa.h from SSLeay, and the SSLeay docs about what
these are used for - it works with just N,E, and D, but is much faster
with the rest of these params).

> I also have a problem with Key v.s. Subkey packets.  I use DH keys for El
> Gamal signing.  Do they belong in a key or subkey packet?  What about an
> RSA key used for both?

I generated a V4 RSA key as a primary key and PGP 5.0 promptly converted
it to a V3 packet, V3 Keyid, V3 Fingerprint, etc.  Since I can't export
a V4 RSA key at the moment, I don't know if I would be able to read it.

I am going to have to rework my interface, currently I have it if the DSA
and DH pointers are identical, then it points to a RSA structure.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Sat, 4 Apr 1998 03:09:03 -0500
From: [email-masked]
To: Jon Callas <[email-masked]>
cc: [email-masked]
Subject: V4 RSA key update.
Sender: [email-masked]

I have working? V4 rsa keys.

1. When encrypting to RSA keys, PGP 5.0 always uses the old packet format.
adding this allowed me to decrypt a pgpe encrypted message.  I am
generating the new format.

2. I haven't tried passphrase protected V4 RSA keys, since that is being
added.  I may dupe PGP 5.0 behavior.

3. PGP 5.0 only uses the old style RSA key ids.

4. pgpv still won't recognize a pgpe produced RSA message., nor one I
create, so I suspect it has something to do with the V4 key.

A new opgp should happen sometime this weekend.  I also reorganized some
more things.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Fri, 3 Apr 1998 23:35:33 -0500
From: [email-masked]
To: Jon Callas <[email-masked]>
cc: [email-masked]
Subject: Re: Preliminary V4 RSA key support added.  But I can't test...
Sender: [email-masked]

On Fri, 3 Apr 1998, Jon Callas wrote:

> Nonetheless, this sounds like a bug in 5.0.
> 
> 	Jon

One note is that SSLeay and OpenPGP label the P and Q RSA constants the
reverse of each other.  Normally it doesn't matter, but if you use the
extension with D mod Q-1 and D mod P-1 for the SSLeay structure you need
to get these right. 

Also I see it says in the spec,

P < Q

Which may explain why it is reversed.

But it still doesn't interoperate with PGP 5.0.  I may still have a
problem with my secring format (but the pubring V4 format seems to work
fine).

Worse, pgpe also encrypts using one of my keys (pgpk says it is fine too),
but I can't decrypt it - pgpv acts the same.

pgpk:

Type Bits KeyID    Created    Expires    Algorithm       Use
sec   512 331A8FBD 1998-04-04 ---------- RSA             Sign and Encrypt
f16    Fingerprint16 = AF F7 A7 54 6F EB 62 C1  72 86 90 BA 18 0E D6 64
uid  RSAKey

(it can say sec+ if I set it to axiomatic, but it still does the same
thing).

pgpv:

Message is encrypted.
Cannot decrypt message.  It can only be decrypted by:
   512 bits, Key ID 331A8FBD, Created 1998-04-04
   "RSAKey"

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Fri, 3 Apr 1998 21:50:42 -0500
From: [email-masked]
To: Jon Callas <[email-masked]>
cc: [email-masked]
Subject: Re: On my HAVAL implementation
Sender: [email-masked]

On Fri, 3 Apr 1998, Jon Callas wrote:

> At 03:41 PM 3/30/98 -0300, Paulo Barreto wrote:
>    
> I'm a little concerned about this. It is my understanding of copyright law
> that one can copyright an *implementation* but not an algorithm. I wrote
> Dr. Zheng, and he gave me permission to put it in OpenPGP. However, I am
> still concerned about putting in an algorithm that someone claims
> "copyright" on. Furthermore, we need an OID for it.

1. I would get a clarification that it would be something like GPL, i.e.
no restriction on incorporation or distribution if we put it in, or
something like "No restrictions on use in OpenPGP implementations".

2. You don't need an OID to use it with DSS, only RSA and El Gamal, and
currently I say the OID is length zero, but have some appropriate
constants which will never get in.

3. Even if you leave in a placeholder, at least it would help to define
the rounds and length of the hash.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Fri, 3 Apr 98 18:36:06 PST
From: [email-masked] (Jim Gillogly)
To: [email-masked]
Subject: Re: On my HAVAL implementation
Sender: [email-masked]

Jon says:
> At 03:41 PM 3/30/98 -0300, Paulo Barreto wrote:
> 
>    1. Though my implementation is indeed public domain, the very algorithm is
>    *not*, as Dr. Yuliang Zheng clearly states in his HAVAL page.  However,
>    he's very liberal in conceding "licenses" (in fact, absolutely no fee is
>    due; Dr. Zheng only wants to keep track of where HAVAL is being used).
>    
> I'm a little concerned about this. It is my understanding of copyright law
> that one can copyright an *implementation* but not an algorithm. I wrote

Yes, that's my understanding as well.  People have been getting away
with patenting algorithms and other mathematics (pretending they're
process patents and using appropriately convoluted language in the
patent to further that fiction), but copyright covers only the
expression and not the factual content.

> Does anyone have an opinion? Should I strike HAVAL? Should I leave it there
> even if it's just a placeholder for later? It's certainly nice to have
> extra hash algorithms, but it is by no means something we should delay
> over. It can always go in 1.1.

I'd like to keep it, but not at the cost of substantial delays.  Perhaps
another iteration or two, having somebody assign an OID while discussing
it with Prof. Zheng, would be enough to resolve it.  And if it isn't
resolved by Last Call, it's OAPL.

Another possibility is Tiger (Anderson & Biham,
http://www.cs.technion.ac.il/~biham).  I don't see an OID for it either,
though, nor do I see anything about IPR for it.  Its design is different
from MD5 and SHA-1 (which are in the same general family), which is a plus.

Perhaps it's premature to include either HAVAL or Tiger in the spec, though,
since neither has gotten a fraction of the attention of MD5 and SHA-1.

	Jim Gillogly

Date: Fri, 3 Apr 1998 21:26:38 -0500
From: [email-masked]
To: Jon Callas <[email-masked]>
cc: [email-masked]
Subject: Re: V4 RSA keys??? Incongruities
Sender: [email-masked]

On Fri, 3 Apr 1998, Jon Callas wrote:

> At 10:07 AM 4/3/98 -0500, [email-masked] wrote:

> We should. All public keys should be handled the same in V4 formats. I've
> changed that. Thanks for pointing it out. There are a number of places
> where the original text uses "RSA" to mean "V3." It is my intent for
> OpenPGP to extend V4 to all key types, even the ones that Team PGP never
> implemented (such as V4 RSA keys, Elgamal signing keys, etc). I've changed
> the text in that paragraph and the one after to reflect this.

And nuke the checksum on unencrypted keys (i.e. make the routines
identical).

>    I also have a problem with Key v.s. Subkey packets.  I use DH keys for El
>    Gamal signing.  Do they belong in a key or subkey packet?  What about an
>    RSA key used for both?
> 
> When Viacrypt wanted to make sign-only and encrypt-only keys, they added
> the new PKC types for those uses. There are a (small) number of those keys
> still hanging around. Personally, I think Lutz's new subpacket for marking
> key usage is a better solution for the long term, and I wouldn't mind
> deprecating the RSA usage types (comments?). I didn't even know they
> existed until some code I had written (based upon RFC1991 and other
> documents) blew up.

It would be much cleaner to have type == 1 instead of type == 1 || type ==
2 all over the place.

The only counter I would have is DH keys with generators of 2 which aren't
appropriate for El Gamal signatures.  I generate DH keys not subceptible
to the known attacks against El Gamal signatures (assuming I understood
the paper right - and I think a few people are reviewing what I did to see
if it is sufficient).  If you have an old DH key, it can simply not be
used if the signature would be weak (I do this too).

> I believe that the "extended key structure" consists of a top-level key
> which MUST be able to sign, but MAY also be able to encrypt, and a
> collection of subkeys which may be of any type. The top leve key is the key
> that certifications (a.k.a. key signatures) are made over, and the
> top-level key also makes its own certifications which state its ownership
> of the subkeys.

Agreed.  It helps to have one central key per identity.

> Now then, it is my considered opinion that it is a bad idea to use a
> top-level key for encryption. My ideal world would also have the top-level
> key only used for certifying other keys, and you'd have subkeys for
> document signing. But that's my opinion. I don't think it's erroneous for
> an implementation to let you do that, but if I were writing an
> implementation, that's what I'd implement. This is why I like Lutz's key
> use subpacket. It is, though, an subject on which gentlebeings may
> disagree, so I don't want to mandate things in the spec. 

This is good.  I might want to use the top key for internal personal
encryption, e.g. local files or something.  I would leave the model to by
default be PS(SE...,SS...) especially so that the PS would be used so that
the keyservers could easily manage things. (prior Acronyms expand to
Primary/Secondary Sign/Encrypt).  You could override things for special
usages.

>    Another note: A Subkey MAY??? MAY_NOT??? appear under more than one Key.
>    
> I think that it is a Bad Idea to use a subkey in more than one extended
> key. But I can think of situations where you'd want to migrate a subkey
> from one extended key to another. For example, I get a new job, so I torch
> all my signing keys (top-level included), and make a new extended key,
> copying over all the old encryption keys. Want me to say things like this
> in the security considerations section?

Yes, red lights should flash if you find the same subkey under two
non-revoked primary keys (and then should consult a keyserver).   I would
say SHOULD NOT with the note that the implementation should complain, but
might want to complete the operation, since I might get your new keys
before I can confirm your old primary key is invalid

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Fri, 03 Apr 1998 17:58:56 -0800
To: [email-masked] (Paulo Barreto), [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: On my HAVAL implementation
Sender: [email-masked]

At 03:41 PM 3/30/98 -0300, Paulo Barreto wrote:

   1. Though my implementation is indeed public domain, the very algorithm is
   *not*, as Dr. Yuliang Zheng clearly states in his HAVAL page.  However,
   he's very liberal in conceding "licenses" (in fact, absolutely no fee is
   due; Dr. Zheng only wants to keep track of where HAVAL is being used).
   
I'm a little concerned about this. It is my understanding of copyright law
that one can copyright an *implementation* but not an algorithm. I wrote
Dr. Zheng, and he gave me permission to put it in OpenPGP. However, I am
still concerned about putting in an algorithm that someone claims
"copyright" on. Furthermore, we need an OID for it.

Does anyone have an opinion? Should I strike HAVAL? Should I leave it there
even if it's just a placeholder for later? It's certainly nice to have
extra hash algorithms, but it is by no means something we should delay
over. It can always go in 1.1.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 4200 Bohannon Drive
Network Associates, Inc.                    Menlo Park, CA 94025
(650) 473-2860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Fri, 03 Apr 1998 15:29:58 -0800
To: [email-masked], [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Preliminary V4 RSA key support added.  But I can't test...
Sender: [email-masked]

At 05:23 PM 4/3/98 -0500, [email-masked] wrote:
   On Fri, 3 Apr 1998 [email-masked] wrote:
   
   > I generated a V4 RSA key as a primary key and PGP 5.0 promptly converted
   > it to a V3 packet, V3 Keyid, V3 Fingerprint, etc.  Since I can't export
   > a V4 RSA key at the moment, I don't know if I would be able to read it.
   
   I was wrong, it is a V4 packet.  But it uses V3 including keyids for
   everything else, so I can't find the key on the keyring.
   
   I needed to compensate for the checksums unique to RSA secret MPIs.
   
Nonetheless, this sounds like a bug in 5.0.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 4200 Bohannon Drive
Network Associates, Inc.                    Menlo Park, CA 94025
(650) 473-2860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Fri, 03 Apr 1998 15:11:03 -0800
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: V4 RSA keys??? Incongruities
Sender: [email-masked]

At 10:07 AM 4/3/98 -0500, [email-masked] wrote:

   In the V4 section it says "With RSA keys, the MPI bit count prefix... is
   not encrypted...".  So you are using old V3 style encryption.  But you
   will probably be using 3DES to encrypt the secret key itself, so it would
   be incompatible.
   
   Why not, for V4 keys, treat RSA MPIs just like DSA or DH MPIs?

We should. All public keys should be handled the same in V4 formats. I've
changed that. Thanks for pointing it out. There are a number of places
where the original text uses "RSA" to mean "V3." It is my intent for
OpenPGP to extend V4 to all key types, even the ones that Team PGP never
implemented (such as V4 RSA keys, Elgamal signing keys, etc). I've changed
the text in that paragraph and the one after to reflect this.

An historical note about this is that in the early days of PGP, they were
very concerned about known plaintext. Consequently, a number of attempts
were made to hide the structure of PGP data and encrypted data. That is the
reason for the "hand-huffman-coding" and other facets like not encrypting
the bit count (because that was known). By the time the V4 structures were
made, there was less fear of known plaintext. 
   
   I also have a problem with Key v.s. Subkey packets.  I use DH keys for El
   Gamal signing.  Do they belong in a key or subkey packet?  What about an
   RSA key used for both?

When Viacrypt wanted to make sign-only and encrypt-only keys, they added
the new PKC types for those uses. There are a (small) number of those keys
still hanging around. Personally, I think Lutz's new subpacket for marking
key usage is a better solution for the long term, and I wouldn't mind
deprecating the RSA usage types (comments?). I didn't even know they
existed until some code I had written (based upon RFC1991 and other
documents) blew up.

I believe that the "extended key structure" consists of a top-level key
which MUST be able to sign, but MAY also be able to encrypt, and a
collection of subkeys which may be of any type. The top leve key is the key
that certifications (a.k.a. key signatures) are made over, and the
top-level key also makes its own certifications which state its ownership
of the subkeys. 

Now then, it is my considered opinion that it is a bad idea to use a
top-level key for encryption. My ideal world would also have the top-level
key only used for certifying other keys, and you'd have subkeys for
document signing. But that's my opinion. I don't think it's erroneous for
an implementation to let you do that, but if I were writing an
implementation, that's what I'd implement. This is why I like Lutz's key
use subpacket. It is, though, an subject on which gentlebeings may
disagree, so I don't want to mandate things in the spec. 

   How about something like:
   
   A Key packet MUST be able to be used for signing and MUST be used to sign 
   all subkey information.
   
   A Subkey packet MAY be used for siging.
   
   Either MAY be used for encryption if an algorithm is defined for the type.
   
   In effect, a two level hierarchy.  I can use a very secure signing key for
   the Key Packet, but use a faster, shorter, (disposable?) signing subkey.
   The high security key would be used for all the UserID stuff, etc. and
   define the particular online persona, with the subkeys being used as
   desired.
   
   I don't know if this was the full intent, but if it is not signing v.s.
   encryption (so an RSA key would have to appear as both) this is the most
   obvious next choice - primary and secondary.
   
It sounds like we're pretty much in agreement.

   Another note: A Subkey MAY??? MAY_NOT??? appear under more than one Key.
   
I think that it is a Bad Idea to use a subkey in more than one extended
key. But I can think of situations where you'd want to migrate a subkey
from one extended key to another. For example, I get a new job, so I torch
all my signing keys (top-level included), and make a new extended key,
copying over all the old encryption keys. Want me to say things like this
in the security considerations section?

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 4200 Bohannon Drive
Network Associates, Inc.                    Menlo Park, CA 94025
(650) 473-2860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Fri, 3 Apr 1998 17:23:21 -0500
From: [email-masked]
To: [email-masked]
Subject: Re: Preliminary V4 RSA key support added.  But I can't test...
Sender: [email-masked]

On Fri, 3 Apr 1998 [email-masked] wrote:

> I generated a V4 RSA key as a primary key and PGP 5.0 promptly converted
> it to a V3 packet, V3 Keyid, V3 Fingerprint, etc.  Since I can't export
> a V4 RSA key at the moment, I don't know if I would be able to read it.

I was wrong, it is a V4 packet.  But it uses V3 including keyids for
everything else, so I can't find the key on the keyring.

I needed to compensate for the checksums unique to RSA secret MPIs.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Fri, 3 Apr 1998 14:38:32 -0500
From: [email-masked]
To: [email-masked]
Subject: Preliminary V4 RSA key support added.  But I can't test...
Sender: [email-masked]

On Fri, 3 Apr 1998 [email-masked] wrote:

> Why not, for V4 keys, treat RSA MPIs just like DSA or DH MPIs?

That is, encrypt the MPI whole and not do any resets.  In this case
encrypt all 4 MPIs in a stream starting with the first bitcount octet.

And while I am here, you are storing U (which is iqmp in SSLeay) as part
of the RSA secret key.  Might I suggest (given the rest of the
incompatibilites already there) that we also include dmp1 and dmq1?  And
place those just above U?  I calculate them, but I could calculate U.
(see my getkey2.c and rsa.h from SSLeay, and the SSLeay docs about what
these are used for - it works with just N,E, and D, but is much faster
with the rest of these params).

> I also have a problem with Key v.s. Subkey packets.  I use DH keys for El
> Gamal signing.  Do they belong in a key or subkey packet?  What about an
> RSA key used for both?

I generated a V4 RSA key as a primary key and PGP 5.0 promptly converted
it to a V3 packet, V3 Keyid, V3 Fingerprint, etc.  Since I can't export
a V4 RSA key at the moment, I don't know if I would be able to read it.

I am going to have to rework my interface, currently I have it if the DSA
and DH pointers are identical, then it points to a RSA structure.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Fri, 3 Apr 1998 10:33:38 -0500
From: [email-masked]
To: [email-masked]
Subject: RSA Key spec question
Sender: [email-masked]

E is 17 in pgp, but often 3 or 65567 elsewhere.  I know why 2**N+1, but is
there anything that should be said about this in the spec?

(Testing 2.6.2 v.s. SSLeay from long ago proved that any value of E worked
in either; But only some could be generated, or would be by default).

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Fri, 3 Apr 1998 10:07:31 -0500
From: [email-masked]
To: [email-masked]
Subject: V4 RSA keys??? Incongruities
Sender: [email-masked]

On Wed, 1 Apr 1998 [email-masked] wrote:

> Also some note that V4 RSA key ids are valid and different from V3.
> i.e. Same Key, different ID.
> 
> Right now, I have RSA as V3, and DH/DSS as V4.  It is one of the remaining
> things I should do is add RSA to V4 and relegate the V3 to my pgp 2.6.2
> subset.

Having started the implementation, there are a few problems.

In the V4 section it says "With RSA keys, the MPI bit count prefix... is
not encrypted...".  So you are using old V3 style encryption.  But you
will probably be using 3DES to encrypt the secret key itself, so it would
be incompatible.

Why not, for V4 keys, treat RSA MPIs just like DSA or DH MPIs?

I also have a problem with Key v.s. Subkey packets.  I use DH keys for El
Gamal signing.  Do they belong in a key or subkey packet?  What about an
RSA key used for both?

How about something like:

A Key packet MUST be able to be used for signing and MUST be used to sign 
all subkey information.

A Subkey packet MAY be used for siging.

Either MAY be used for encryption if an algorithm is defined for the type.

In effect, a two level hierarchy.  I can use a very secure signing key for
the Key Packet, but use a faster, shorter, (disposable?) signing subkey.
The high security key would be used for all the UserID stuff, etc. and
define the particular online persona, with the subkeys being used as
desired.

I don't know if this was the full intent, but if it is not signing v.s.
encryption (so an RSA key would have to appear as both) this is the most
obvious next choice - primary and secondary.

Another note: A Subkey MAY??? MAY_NOT??? appear under more than one Key.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Thu, 2 Apr 1998 16:02:36 -0500
From: [email-masked]
To: Jim Gillogly <[email-masked]>
cc: [email-masked]
Subject: Re: Wordsmithing in 3.6.3.3
Sender: [email-masked]

On Thu, 2 Apr 1998, Jim Gillogly wrote:

> I'm probably unusually thick, but I found the wording of 3.6.3.3
> difficult.  Despite words to the contrary, it took me a while to
> get away from the idea that it was being run through multiple
> hashes -- I've been looking at too many HMACs lately -- rather
> than simply being duplicate data sent into the same hash.  The
> current second paragraph is:
> -------------------------------------------------------------------
> Initially, one or more hash contexts are set up as with the other S2K
> algorithms, depending on how many octets of key data are needed.  Then
> the salt, followed by the passphrase data is repeatedly hashed until
> the number of octets specified by the octet count has been hashed.  The
> one exception is that if the octet count is less than the size of the
> salt plus passphrase, the full salt plus passphrase will be hashed even
> though that is greater than the octet count.  After the hashing is done
> the data is unloaded from the hash context(s) as with the other S2K
> algorithms.
> -------------------------------------------------------------------
> Would it be too redundant to add a little more to it, like this?
> -------------------------------------------------------------------
> Initially, one or more hash contexts are set up as with the other S2K
> algorithms, depending on how many octets of key data are needed.  Then
> the
> salt, followed by the passphrase data is repeatedly hashed until the
> number of octets specified by the octet count has been hashed.  That is,
> each hash context is fed the initial zero-valued octets (if any), the
> salt, the passphrase, the salt again, the passphrase again, and so on
> until the specified octet count has been hashed, not counting the
> initializing zero-valued octets.  The one exception is that if the octet
> count is less than the size of the salt plus passphrase, the full salt
> plus passphrase will be hashed even though that is greater than the
> octet
> count.
>  
> After the hashing is done the data is unloaded from the hash context(s)
> as with the other S2K algorithms.
> ----------------------------------------------------------------------

Or (since I do them serially),

The number of octets of key material is determined by the conventional
algorithm.  If the hash result is larger than the number needed, the first
octets are used.  If more octets are required, the hash is repeated but is
started by hashing zero octets, one for each extra pass, before hashing
the key material, i.e for hash pass N, N-1 zero octets are hashed first.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Thu, 02 Apr 1998 11:29:39 -0800
From: Jim Gillogly <[email-masked]>
Organization: Banzai Institute
To: [email-masked]
Subject: Wordsmithing in 3.6.3.3
Sender: [email-masked]

I'm probably unusually thick, but I found the wording of 3.6.3.3
difficult.  Despite words to the contrary, it took me a while to
get away from the idea that it was being run through multiple
hashes -- I've been looking at too many HMACs lately -- rather
than simply being duplicate data sent into the same hash.  The
current second paragraph is:
-------------------------------------------------------------------
Initially, one or more hash contexts are set up as with the other S2K
algorithms, depending on how many octets of key data are needed.  Then
the salt, followed by the passphrase data is repeatedly hashed until
the number of octets specified by the octet count has been hashed.  The
one exception is that if the octet count is less than the size of the
salt plus passphrase, the full salt plus passphrase will be hashed even
though that is greater than the octet count.  After the hashing is done
the data is unloaded from the hash context(s) as with the other S2K
algorithms.
-------------------------------------------------------------------
Would it be too redundant to add a little more to it, like this?
-------------------------------------------------------------------
Initially, one or more hash contexts are set up as with the other S2K
algorithms, depending on how many octets of key data are needed.  Then
the
salt, followed by the passphrase data is repeatedly hashed until the
number of octets specified by the octet count has been hashed.  That is,
each hash context is fed the initial zero-valued octets (if any), the
salt, the passphrase, the salt again, the passphrase again, and so on
until the specified octet count has been hashed, not counting the
initializing zero-valued octets.  The one exception is that if the octet
count is less than the size of the salt plus passphrase, the full salt
plus passphrase will be hashed even though that is greater than the
octet
count.
 
After the hashing is done the data is unloaded from the hash context(s)
as with the other S2K algorithms.
----------------------------------------------------------------------

-- 
	Jim Gillogly
	Trewesday, 11 Astron S.R. 1998, 19:21
	12.19.5.1.1, 7 Imix 19 Cumku, Third Lord of Night

Date: Wed, 1 Apr 1998 21:31:30 -0800
From: Hal Finney <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Key IDs
Sender: [email-masked]

Jim Gillogly, <[email-masked]>, writes:
> - 5.5.2 alludes to the 0xDEADBEEF problem with respect to v3 keys.
>   Geoff Keating posted a message Monday in
>   comp.security.pgp.tech entitled "Two different DSA keys with
>   identical key IDs", but I haven't been able to confirm them:
>   pgpk -a goes haring off to the Netherlands to try to install
>   them (I didn't realize PGP had a browser built in!).  Doing the
>   fingerprinting "by hand" results in different IDs than the ones
>   shown in his message -- at least for me.  If somebody else can
>   confirm his result, the v4 key explanation might need to include
>   a similar caveat.

I have confirmed that the two keys he showed do in fact generate matching
64-bit keyids.

The 64 bit keyid of a DSA key is simply the rightmost 64 bits of the
fingerprint, which is the SHA-1 hash of the key.  Generating two keys
with matching keyids is then a matter of finding a 64 bit hash collision.
This requires approximately 2^32 keys to be generated.

You can generate multiple DSA keys quickly if they all share the same
p, q and g values.  You pick a random x and calculate the public value
from y = g^x mod p.  Then you hash p, q, g and y to form the fingerprint.

Artificially generating two keys with matching keyids is therefore
relatively easy.  It is much more difficult to generate a key which
matches the keyid of a given key, which was the original so-called
"0xDEADBEEF attack" that Jim mentions, and which the spec alludes to
in section 5.5.2.  That would require generating approximately 2^64 keys,
which would be a huge effort.

Hal

Date: Wed, 1 Apr 1998 23:40:16 -0500
From: [email-masked]
To: [email-masked]
Subject: Re: Key IDs
Sender: [email-masked]

On Wed, 1 Apr 1998, Jim Gillogly wrote:

> Jon announced at IETF that he's about ready to go to a penultimate
> call on op-fmts.txt, so I'd better get a few suggestions into the
> hopper.
> 
> Here's a cluster of Key ID comments and questions.
> 
> - v3 Key ID and Fingerprint are handled in 5.5.2
>   v4 Key ID and Fingerprint are handled in 11.2
>   I suggest they ought to be discussed in the same place, or that
>   the v3 and v4 discussions be more parallel.  I understand that the
>   current structure is the result of handling it from a historical
>   or archaeological viewpoint, but I think a functional breakdown
>   makes more sense.

At least a pointer in 5.5.2 to 11.2.

Also some note that V4 RSA key ids are valid and different from V3.
i.e. Same Key, different ID.

Right now, I have RSA as V3, and DH/DSS as V4.  It is one of the remaining
things I should do is add RSA to V4 and relegate the V3 to my pgp 2.6.2
subset.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Wed, 01 Apr 1998 19:47:15 -0800
From: Jim Gillogly <[email-masked]>
Organization: Banzai Institute
To: [email-masked]
Subject: Key IDs
Sender: [email-masked]

Jon announced at IETF that he's about ready to go to a penultimate
call on op-fmts.txt, so I'd better get a few suggestions into the
hopper.

Here's a cluster of Key ID comments and questions.

- v3 Key ID and Fingerprint are handled in 5.5.2
  v4 Key ID and Fingerprint are handled in 11.2
  I suggest they ought to be discussed in the same place, or that
  the v3 and v4 discussions be more parallel.  I understand that the
  current structure is the result of handling it from a historical
  or archaeological viewpoint, but I think a functional breakdown
  makes more sense.

- 11.2 says a Key ID may be 32 or 64 bits, but doesn't say when
  each is meaningful.  From a formats point of view I think we
  always use 64 bits for the Key ID, and truncating it for display
  to 32 bits is a user interface issue, so we may as well say flat
  out that it's a 64 bit quantity.

- 5.5.2 alludes to the 0xDEADBEEF problem with respect to v3 keys.
  Geoff Keating posted a message Monday in
  comp.security.pgp.tech entitled "Two different DSA keys with
  identical key IDs", but I haven't been able to confirm them:
  pgpk -a goes haring off to the Netherlands to try to install
  them (I didn't realize PGP had a browser built in!).  Doing the
  fingerprinting "by hand" results in different IDs than the ones
  shown in his message -- at least for me.  If somebody else can
  confirm his result, the v4 key explanation might need to include
  a similar caveat.

  Also, this discussion seems awkward.  I suggest replacing

	Since the release of V3 keys, there have been a number of
	improvements desired in the key format.  For example, if
	the key ID is a function of the public modulus, it is easy
	for a person to create a key that has the same key ID as
	some existing key.  Similarly, MD5 is no longer the preferred
	hash algorithm, and not hashing the length of an MPI with its
	body increases the chances of a fingerprint collision.

  with something along the lines of

	V3 keys SHOULD be used only for backward compatibility because
        of three weaknesses.  First, they are subject to a Key ID
	spoofing attack: a key can easily be constructed with an ID
	matching the ID of any target key.  Second, the fingerprint of
	a key may often be made to match the fingerprint of a target
	key by taking advantage of the fact that MPI lengths are
	not included in the hash.  Finally, the MD5 algorithm used in
	V3 keys has begun to come under mild suspicion.

- Should we offer any more specific advice than in 3.3 about when
  an implementation SHOULD NOT assume the Key ID is unique?  Like
  "if the signature doesn't match, see if you have another such
  Key ID"?  Or is even the mention in 3.3 beyond the scope of a
  formats document?

--
	Jim Gillogly
	Trewesday, 11 Astron S.R. 1998, 01:25
	12.19.5.1.0, 6 Ahau 18 Cumku, Second Lord of Night

Date: Wed, 1 Apr 1998 20:55:39 -0500
From: [email-masked]
To: Jon Callas <[email-masked]>
cc: [email-masked]
Subject: Re: Status from the Working Group Meeting
Sender: [email-masked]

On Wed, 1 Apr 1998, Jon Callas wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHAme On You

Well, I just completed an SSL layer for Mozilla 5.0b1, so I should have
time to implement any of the things on your list.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Wed, 1 Apr 1998 16:37:14 -0800
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Status from the Working Group Meeting
Cc: Jon Callas <[email-masked]>
Sender: [email-masked]

Today at the OpenPGP meeting, I announced some new features for OpenPGP.
The attendees thought that I should send them to the list, stressing that
it was vital they get sent today, even before the minutes get posted to the
list.

The first new feature is a new type of signature, "Message Validity
Signatures." These new signatures are a mechanism that contains information
that allows a user to determine whether a message is true. This new
technology has a number of uses, particularly with electronic commerce and
digital contracts. They also employ an extension to the PGP Web of Trust
called the Web of Contempt.

The Web of Contempt is a cumulative system that uses aggregate information
from a family of users. It mirrors the Web of Trust and has in it
user-customizable settings for Partially Contemptible Keys, Completely
Contemptible Keys, and Axiomatically Contemptible Keys. The last ones are
the root keys from which the PGP contempt model extends contempt. This new
mechanism is especially useful for diplomacy and other systems that require
plausible deniability, withering remarks, faint praise, or backhand
compliments.

A new type of signature, the "Anti-Identity Signature" allows a user to
declare that they do not have a given identity. For example, a user can
declare that he or she is not Bill Clinton. It also allows a user to
declare that someone else does not have a certain identity, perhaps
attesting that someone else is not Bill Clinton. Lastly, when used in
combination with the Web of Contempt, a group of users can combine their
digital signatures to invalidate the identity of another certificate. This
is especially useful for fighting the widespread crime of identity theft,
by revoking the stolen identity. It also works in situations where you want
to keep a person around, but want someone else to fulfill that role. This
new signature type can also solve the Internet problem of email spam by
letting users revoke the identity of spammers.

Bit-Sorted Escrow is a technique that satisfies the concerns that law
enforcement agencies have about cryptography, while preserving the privacy
needed for electronic commerce. In Bit-Sorted Escrow, the user can reserve
40 (which do not have to be contiguous) bits of a key to remain secret, and
the other remaining bits are sorted (big-endian, zeroes to the MSB), and
then sent to the Bit-Sorted Escrow Server run by the United States
Department of Justice at <ldaps://bsescrow.doj.gov>. This has the advantage
of providing strong cryptography for honest users while giving the
government the access to message content that it deserves.

Many organizations need to test the implementations of their public key
infrastructure, especially when rapidly deploying new systems such as the
Web of Contempt to a large introduction. PGP 6.6.6 implements a new
solution to this problem, called the Beta-Introducer. A Beta-Introducer
allows an organization to test out their infrastructure, while not actually
granting undue trust or contempt to their members.

We are also going to start working on some new RFCs for two new servers and
some more infrastructure.

The first new server is the "Passphrase Recovery Server." The largest
obstacle to deploying strong crypto is that people keep forgetting their
passphrases. Even people at the IETF from time to time have to tell someone
not to use a key because they have lost their passphrase. A Passphrase
Recovery Server lets a user who has lost their passphrase get a new one.

The second sever is the "Key Generation Server." Many, many organizations
have people who are (as Mel Brooks put it) "the salt of the earth." These
people are incapable of generating their own keys, so they can get them
from the server.

Interestingly, the combination of these is quite powerful. People who lose
their passphrases some number of times can be given a new key from the key
generation server (or perhaps one that's specified in the RFC), and have
their settings appropriately modified in the Web of Contempt.

The last new RFC is for a generalized Emotion-Model System. Having already
two emotions, trust and contempt, we should define the general case. It can
work with a web of affection (useful for computer dating services), a web
of benevolence (for charitable organizations), or even a web of lust
(useful for the Executive Branch).

As time permits, we will do more work on these new systems. I'd like it if
this time next year, there were some drafts that could be sent to the
working group. If anyone wants to work on these drafts, let me know,
especially if they have any ideas for new things to suggest then.

	Jon

- -----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 4200 Bohannon Drive
Network Associates, Inc.                    Menlo Park, CA 94025
(650) 473-2860
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Wed, 1 Apr 1998 15:11:31 -0500
From: [email-masked]
To: [email-masked]
cc: Jon Callas <[email-masked]>
Subject: Re: Obvious (?) question about interoperability
Sender: [email-masked]

> > There has been a suggestion for a new-format length that would use the
> > length byte of 0xFF (which would ordinarily be a stream-chunk of 2GB) as a
> > marker for a four-octet length that follows. So you would see:
> > 
> > 	<CTB><0xFF><four-octet-length><packet-body>
> > 
> > as a packet form. That lets someone bring in the whole packet without the
> > streaming mechanism. People sounded supportive of that, and my slides for
> > tomorrow have that on there as a feature I want to have in the next draft.

The above is implicitly a terminal packet-length

...

> I want a rule that if the content of a packet is less than the maximum
> terminal packet size (8192+192? bytes), then it MUST NOT be split up.

With the new packet type above, you can also require that things like
keys, signatures, etc. be monolithic even if they are larger than the
largest terminal length packet.  They either use a terminal small packet
length or the 0xff-4-octet form. 

So I vote for the new packet length type *and* forcing certain packets to
be monolithic.

Otherwise someone will use incremental lengths for each unit within a
subpacket, e.g. for an MPI integer <0xE1> 0x00 0xA0 <0xE4>...<0xE2>...
which is what I really don't want to have to handle.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Wed, 1 Apr 1998 12:08:34 -0500
From: [email-masked]
To: Jon Callas <[email-masked]>
cc: [email-masked]
Subject: Re: Obvious (?) question about interoperability
Sender: [email-masked]

On Wed, 1 Apr 1998, Jon Callas wrote:

> At 6:11 PM -0800 3/31/98, [email-masked] wrote:
> 
>    Generally PGP 5.0 will interoperate, except any secret keyrings won't be
>    decryptable in OpenPGP (because of the loss of type 3 Iterated S2K being
>    replaced by type 4).  It will also cause problems for conventionally
>    encrypted packets.
> 
> We're going back to the type 3 iterated-salted s2ks. Simplicity is a
> virtue, but not when it makes things harder.

So I can rip out type 4 (which I haven't tested).  Good.  Easy != Simple

> The charter calls for "limited" backwards compatibility. I think for your
> purposes it depends on how much you want to do. Our predecessor, RFC 1991,
> recommended backwards compatibility to one previous version. That would
> mean you could ignore 2.6. That wouldn't particularly nice, though. There
> are a number of things you can do that are easy to make things work with
> 2.6.

Actually I have code to allow the 2.6 code to handle 2.1 (or whatever
the pre PKCS padding PGP2 was and it may still be in the minipgp README).

> I am planning on putting in the algorithm notes that a V3 key with a V3
> self signature MAY be considered to have an implicit preference for IDEA
> alone. This would mean that a considerate OpenPGP implementation can freely
> interoperate with 2.6, but a minimal one doesn't have to.
> 
> For you, do as much as you want above what is required. If you want your
> implementation to be widely used and interoperable with old versions, you
> can do a lot. Otherwise, you can leave the annoying stuff to someone else.

Actually I just updated my 2.6.2 libraries and am retaining them as
separate routines since they are fairly short.  It would make a
-V3-compatible flag much easier than trying to fiddle with each bit.

>    ------------------
> 
>    Another problem I have is with the new CTB, at least for intrinsically
>    short packets like keys, signatures, P/SKESK headers, etc.
>    If these are normalized (Monolithic if overall length is <4096 bytes), I
>    can use ordinary libc calls (fread, fwrite).  Otherwise I need a
>    normalization pass.  I think implementations SHOULD store anything except
>    compressed, literal, or conventionally encrypted packets in normalized
>    form.  Further, the conventionally encrypted packets should not divide the
>    first 10 bytes (actually 11) of the stream.
> 
> There has been a suggestion for a new-format length that would use the
> length byte of 0xFF (which would ordinarily be a stream-chunk of 2GB) as a
> marker for a four-octet length that follows. So you would see:
> 
> 	<CTB><0xFF><four-octet-length><packet-body>
> 
> as a packet form. That lets someone bring in the whole packet without the
> streaming mechanism. People sounded supportive of that, and my slides for
> tomorrow have that on there as a feature I want to have in the next draft.

NO! NO! NO! IT DOESN'T - I will still have to support the V3, the
degenerate packet length
<0xe0>f<0xe0>o<0xe0>r<0xe0>m<0xe0>a<0xe0>t<0x01>s, and this new one. 

I can't magically force all messages sent to me to use this new format.

Actually, I don't object to the new packet above, at least not until I
think about it.  Remember that ADDING anything for one implementation will
require all other implementations to support it or not be able to read it.

What I object to is what I did with the <0x07>formats string above.
Perfectly valid.  Pefectly horrid.

I want a rule that if the content of a packet is less than the maximum
terminal packet size (8192+192? bytes), then it MUST NOT be split up.

Barring that (for small memory or something), that the first
partial-packet-length must encompass any header information and at least
one byte of data (i.e. the 10 byte startup encryption packet, or the
entire literal header for literal packets). 

That way I can use fread instead of another layer to extract the data from
the packet-length bytes.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Wed, 1 Apr 1998 11:47:29 -0500
From: [email-masked]
To: Hal Finney <[email-masked]>
cc: [email-masked]
Subject: Re: Why one pass sigs?
Sender: [email-masked]

On Wed, 1 Apr 1998, Hal Finney wrote:

> The purpose of the 1-pass signature packets is not primarily to provide
> multiple signature capability.  The main purpose is to allow the signer
> to process the entire message in one pass.

The rest of the message is technical commentary, sort of Oh, yea - it
would have to be done this way.

The SIGNER needs the one pass format to do signatures in one pass.

> With old-style signatures, the signature has to go at the front of
> the message.  But the signer can't create the signature until he has
> processed the whole message.  So he then has to go back and stick the
> signature back at the front of the message, which requires some buffering
> and re-scanning of the data.

It requires two read passes.  The first doesn't write, but only formats
and hashes.  Then the sig would be written out.  Then a second read would
write out the real (e.g. literal encasulated) data.

But you are right, you could not handle a stream this way.  Unless you had
a filesystem that allowed for insertion at the head as well as the tail.

> With the 1-pass signature, the signer puts the 1-pass packet at the
> front to tell the verifier what hash to use, then comes the message,
> and then comes the signature.  This is a much more natural flow for all
> parties.

Except that the validity data comes later (which would be known), so you
do all the work and find the signature is expired or something else is
wrong.

You could also have split the signature packet, with everything up to the
2 hash verification bytes and the MPI integers appearing afterword.  This
would leave one format and thus one mode and parser.

> PGP 2.X creates many temp files to deal with the buffering needed by the
> signature structure, and the need to know all packet lengths in advance.
> The one-pass signature packets and partial packet length specifiers are
> designed to allow processing messages without any temporary files, which
> enhances security and performance.

Security, maybe.  If you implement a loop that can pass data between each
layer:
	in->dearmor->decrypt->decompress->deliteral->out
something like:
ret=fread(BUFSIZ); ret=dearmor_update(ret); ret=decrypt_update(ret) ...

with the potential for missing layers, etc.  This is not something that
would help performance (since you have to call the update lots of times
instead of one call to a sub with an internal loop).  You could use huge
buffers, and comression would still require realloc, but that is a memory
usage for CPU tradeoff.

If you use threads with pipes or other OS structures, then those become an
attack point as much as temp files.  Even if you use huge buffers, the OS
will probably respond by swapping out your passphrase, so you have a
virtual temp file.

For *verification*, you merely need to retain the original signature
packet until the end, so it is a few K. 

For pure signing, the file must already exist as plaintext to be read in
(so there is no added security in not reading it a second time, but there 
is added performance), and then the signature packet can be written out
(like a detached signature, and then optionally append the plaintext).

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Wed, 1 Apr 1998 10:55:58 -0500
From: [email-masked]
To: Hal Finney <[email-masked]>
cc: [email-masked]
Subject: Re: Obvious (?) question about interoperability
Sender: [email-masked]

On Wed, 1 Apr 1998, Hal Finney wrote:

> > can use ordinary libc calls (fread, fwrite).  Otherwise I need a
> > normalization pass.  I think implementations SHOULD store anything except
> > compressed, literal, or conventionally encrypted packets in normalized
> > form.  Further, the conventionally encrypted packets should not divide the
> > first 10 bytes (actually 11) of the stream.
> 
> By "normalization" do you mean the problem of assembling packets which use
> partial-length fields?  If so, it was for this reason that I recommended
> adopting a four-byte length field option.  I understand this will be
> discussed at the OpenPGP meeting tomorrow.

Exactly, but it doesn't matter the length field.  As long as you can have
a valid message of <0xe0>t<0xe0>h<0xe0>i<0x01>s form, evil things happen
to the code.

It is easy to detect, since if the first partial length field is for <4096
I can call a normalizer which would collapse the above to <0x04>this.

> > I would make all of these MUSTs, but embedded applications may have
> > reasons not to, and I can normalize the stream myself.
> 
> What exactly would you make MUSTs?  Do you mean you would disallow the
> partial-length packets?

Disallow the partial length packets EXCEPT in literal, compressed, and
symmetrically encrypted packets (though if any of the other could exceed
the 8192+192 byte limit I would allow this; I could contrive an exaple but
I don't know if one would exist in the real world since such things might
break other static limits - huge MPIs, excessive hashed subpackets, etc.).

Do not allow the partial length packet to subdivide a literal header or
the first 11 bytes of an encrypted packet (I would say 10 bytes, but this
way I can be sure of one byte to decipher which makes the decryption loop
much nicer, and the partial length would be 16 if it met this).

> > Since I introduced the term normalized, I should define it -
> >
> > packet :- oldCTB-len, datachunk... | newCTB len-stream
> >
> > len-stream :- nontermlen, datachunk, len-stream | termlen, datachunk
> >
> > The len-stream is normal if it does not contain any nontermlen entries
> > indicating the following datachunk is less than 4096 bytes.
> 
> I don't understand the significance of this definition.  What is it about
> normal vs non-normal streams which requires them to be treated differently?
> I could see a distinction between packets which have the length at the
> beginning vs packets whose length is not known until you have read the
> whole thing.  But I don't understand why the issue is whether the
> partial length packets are less than 4096 bytes.

For things like [PS]KESKs, signature packets, key material, they are
normally all under 4096 bytes.  They SHOULD all be under the 8192+ size of
the largest terminal packet length.  This allows express handling:

Normal stream:

get packet length of L
/* you can allocate an L byte buffer */
fread(buf,1,L,fp);
/* process buf */

Unnormal stream:

/* make buf *big*, or do a lot of reallocs */
bufp = buf;
get length packet L
while( partial )
	fread(bufp,1,L,fp);
	bufp += L;
	get length packet L
fread(bufp,1,L,fp);
/* process buf */

Or:

Len = pgpfread(buf,1,BUFMAX,fp); /* containing the above */

My 5.X implementation handles things by reading the whole thing in (if
there is a sane upper limit on the size), and then processing by moving a
buffer pointer. 

If you do a series of pgpfread(..) for every subpacket or atomic data
type, it changes things (and I think this is how PGP5.0 does it), But one
problem with this is that you need state information as to how much data
is left before the next expected packet-length, i.e.

Sub: I want 10 bytes
pgpfread: I have 5 bytes buffered, send them, read next packet length, oh,
it is 0xef, malloc 2147483648 bytes :), read them, return 5 more,
remembering that we have 2147483643 left.

Or:
pgpfread: 0xef, read BUFMAX (4096) bytes, and note there are 2**31-4096
bytes left until the next ctb, send the 5 and note there are 4091 bytes
left in the buffer.  pgpfread now has lots of states and if tests to
determine how to respond.  This is ugly.  Really ugly.

I need to do this anyway for indeterminate length types (SymEncPkt,
Compressed, Literal), but having to handle it withing subfields within the
header is painful.  But I can then inline the state info with the
read-decrypt (see my implementation).

--- reply to tzeruch - at - ceddec - dot - com ---