Subject: Re: Agree with PRZs MDC suggestion

From: [email-masked]
Date: Tue, 18 May 1999 19:24:13 -0700

NAI has decided not to include Twofish in the next release so that we
can try to come to agreement on an MDC packet and use that.

Here is a concrete proposal which represents what we have been discussing
most recently.

I think the only thing I have changed is that I am using version 1.
It's going to be wasteful of version numbers if we keep having to leapfrog
them.  If we made this one 5, then the next time we make a change to
a packet we have to use 6, etc.  It will be more economical to start
new packets at v1 and increment them as we make new versions of them.
I know this practice was not always followed in the past but it will be
better for the future.

As I described earlier, I propose not to have any mechanism for turning
the MDC on and off, or for selecting a hash algorithm, because these would
leave openings for an attacker to possibly modify this selector.  He might
be able to turn off the MDC, which would completely defeat the purpose.

Another attack I have considered is that the attacker could strip off
the MDC packet (by removing the last 22 bytes of ciphertext) and change
the packet tag to an old-style symmetrically encrypted data packet.
However because we are handling the CFB SYNC differently it will produce
completely garbled data, which I view as an acceptable failure mode.
What do you think?

Hal

=====

5.X. Symmetrically Encrypted Integrity Protected Data Packet (Tag 15)

   The Symmetrically Encrypted Integrity Protected Data packet contains
   data encrypted with a symmetric-key algorithm and protected against
   modification by the SHA-1 hash algorithm. When it has been decrypted,
   it will typically contain other packets (often literal data packets
   or compressed data packets).  The last such decrypted packet must be
   a Modification Detection Code packet.

   The body of this packet consists of:

     - A one-octet version number.  The only currently defined value is 1.

     - Encrypted data, the output of the selected symmetric-key cipher
       operating in Cipher Feedback mode with shift amount equal to the
       block size of the cipher (CFB-n where n is the block size).

   The symmetric cipher used MUST be specified in a Public-Key or
   Symmetric-Key Encrypted Session Key packet that precedes the
   Symmetrically Encrypted Data Packet.  In either case, the cipher
   algorithm octet is prefixed to the session key before it is
   encrypted.

   The data is encrypted in CFB mode, with a CFB shift size equal to
   the cipher's block size.  The Initial Vector (IV) is specified as
   all zeros.  Instead of using an IV, OpenPGP prefixes an octet string
   to the data before it is encrypted.  The length of the octet string
   equals the block size of the cipher in octets, plus two.  The first
   octets in the group, of length equal to the block size of the cipher,
   are random; the last two octets are each copies of their 2nd preceding
   octet.  For example, with a cipher whose block size is 128 bits or 16
   octets, the prefix data will contain 16 random octets, then two more
   octets, which are copies of the 15th and 16th octets, respectivelly.
   Unlike the Symmetrically Encrypted Data Packet, no special CFB
   resynchronization is done after encrypting this prefix data.

   The repetition of 16 bits in the random data prefixed to the message
   allows the receiver to immediately check whether the session key
   is incorrect.

   The plaintext of the data to be encrypted is passed through the SHA-1
   hash function, and the result of the hash is appended to the plaintext
   in a Modification Detection Code packet.  Specifically, the input to
   the hash function does not include the prefix data described above;
   it includes all of the plaintext, and then also includes two octets
   of values 0xD0, 0x14.  These represent the encoding of a Modification
   Detection Code packet tag and length field of 20 octets.

   The resulting hash value is stored in a Modification Detection Code
   packet which MUST use the two octet encoding just given to represent
   its tag and length field.  The body of the MDC packet is the 20 octet
   output of the SHA-1 hash.

   The Modification Detection Code packet is appended to the plaintext and
   encrypted along with the plaintext using the same CFB context.

   During decryption, the plaintext data should be hashed with SHA-1,
   not including the prefix data but including the packet tag and length
   field of the Modification Detection Code packet.  The body of the
   MDC packet, upon decryption, should be compared with the result of
   the SHA-1 hash.  Any difference in hash values is an indication that
   the message has been modified and SHOULD be reported to the user.
   Likewise, the absence of an MDC packet, or an MDC packet in any
   position other than the end of the plaintext, also represent message
   modifications and SHOULD also be reported.

   Note: future designs of new versions of this packet should consider
   rollback attacks since it will be possible for an attacker to change
   the version back to 1.

5.Y Modification Detection Code Packet (Tag 16)

   The Modification Detection Code packet contains a SHA-1 hash of
   plaintext data which is used to detect message modification.  It is
   only used in the context of a Symmetrically Encrypted Integrity
   Protected Data packet.  The Modification Detection Code packet MUST
   be the last packet in the plaintext data which is encrypted in the
   Symmetrically Encrypted Integrity Protected Data packet, and MUST
   appear in no other place.

   A Modification Detection Code packet MUST have a length of 20 octets.

   The body of this packet consists of:

     - A 20-octet SHA-1 hash of the preceding plaintext data of the
       Symmetrically Encrypted Integrity Protected Data packet, not
       including prefix data but including the tag and length byte of
       the Modification Detection Code packet.

   Note that the Modification Detection Code packet MUST always use a
   new-format encoding of the packet tag, and a one-octet encoding of
   the packet length.  (These requirements are already imposed by the
   rules for tag and length encoding.)

---

From: Werner Koch <[email-masked]>
Date: Wed, 19 May 1999 10:12:08 +0200

> I think the only thing I have changed is that I am using version 1.

Okay.

> be able to turn off the MDC, which would completely defeat the purpose.

Together with the version number I can live with this.

> completely garbled data, which I view as an acceptable failure mode.

I think this is reasonable.

>    algorithm octet is prefixed to the session key before it is

Don't know wthether I understand it:  Does it mean, that the first 8
bits of the session key are known?  So we actually have only 248 bit
Twofish?  Why not putting the algorithm octet just after the 2
checksum bytes in the prefix? 

>    resynchronization is done after encrypting this prefix data.

And we should cleanup the ambiguity about this in rfc2440.

>    of values 0xD0, 0x14.  These represent the encoding of a Modification

So you can use your old implemenation idea of a fixed block at the end
of the encrypted data.  That is okay.  

>    rollback attacks since it will be possible for an attacker to change

So we also solved this issue :-)

We should also mention that an implemenation SHOULD use this new
packet for ciphers others than 1,2,3,4,5 (which are the ones from the
current rfc).  And that it MAY use the new packet if the preferences
of a receiver's key indicate that an algorithm other than 1..5 can
be used (this is because we can assume, that the new packet type is 
supported by the implemenation used at the receivers side).

Another suggestion for the next version:
Extend the marker paket with a version number of the RFC: "PGP/1.1"
instead of a bare "PGP".  This may be useful in the future.

You did good work with this and I can agree with it.
What do the others think?

-- 
Werner Koch at guug.de           www.gnupg.org           keyid 621CC013

---

From: Marcel Waldvogel <[email-masked]>
Date: Wed, 19 May 1999 16:18:48 +0200 (CEST)

>5.X. Symmetrically Encrypted Integrity Protected Data Packet (Tag 15)
[...]
>   resynchronization is done after encrypting this prefix data.

Hal,

thanks for putting up this proposal. I think it provides a step into the
right direction.

Why don't we repeat the version number (and maybe even the packet tag)
after the two check bytes? Or would this give too much plaintext away?

Although I do understand your concerns against selecting an MDC or even
allowing to turn it off, I would like to see some selection mechanism
included, either for specialized devices or in case some problem shows up
with SHA-1 (e.g. political or cryptanalytical). Wouldn't tampering become
close to impossible if we included the algorithm byte both in the plain
header and repeated it after the CFB?

Even if the algorithm ID was included only in the plain section, the
receiving implementation could flag unknown or weak algorithms as "has
possibly been tampered with".

-Marcel

---

From: Werner Koch <[email-masked]>
Date: Wed, 19 May 1999 16:26:20 +0200

> after the two check bytes? Or would this give too much plaintext away?

I don't think so, there is already enough plaintext because the
structure of the packet heades is well known and this gives you 
already some plaintext.

> with SHA-1 (e.g. political or cryptanalytical). Wouldn't tampering become

political/patents maybe an argument.  Actually we don't need a
cryptograhic hash function here but only a good checksum - so SHA1
is good enough and it is the only hash algorithm which is required
anyway.

However, if it turns out that we have to change something, we have the
version number and can implement another scheme with another version
number which must then be made tamperproof, e.g. by putting a copy
into the encrypted data.

---

From: [email-masked]
Date: Wed, 19 May 1999 10:55:25 -0400

> be able to turn off the MDC, which would completely defeat the purpose.

We are in agreement that there should be no mechanism for turning the MDC
off.  Having a mechanism for selecting a hash algorithm is different, and
I don't see it as leaving the same openings.

You could put a simple checksum (like used for keys) so that the attacker
would have to change both the algorithm ID and checksum within the
encrypted stream.

Also you assume that you could somehow calculate an RMD160 (or other) hash
of modified encrypted data and reencrypt that.

And you could still simply strip off the last N bytes as you have things
now, which is another thing a prefix, the equivalent of "Hash:" helps.

>        the Modification Detection Code packet.

And when the NIST comes up with a wider hash for the DSA-plus (or whatever
it will then be called) you absolutely, positively never ever want to be
able to use it here?  (Or if OpenPGP comes up with a wider DSA, say SHA
followed by RMD160 over the same input we don't want to use that here
either?)

There were strong arguments for removing ElGamal signatures.  But they
turned on providing a mechanism for allowing a DSA like signature to use a
wider, i.e. better (PRZ can do a commercial for GM) hash algorithm, since
a 4096 bit DSA key doesn't add anything when you only have 160 bits of
hash to protect.  I am assuming that this might actually be resolved with
some mechanism for a 256 or 320 bit hash, maybe without the NISTs help, we
can use a modified DSA, and depricate and drop ElGamal signatures.  And if
that happens I would really want the option to use that wider hash here.

>    rules for tag and length encoding.)

My proposal (not in spec language):

The MDCP appears first PRECEEDING the encrypted plaintext and contains
only the version number and algorithm ID(s), and a checksum word.

Alternative 1: 1 MDC packet with version byte, number of hashes byte -
must be nonzero, N algorithm ID bytes.

Alternative 2: N MDC packets, one per algorithm used in reverse order
(therefore no #-of-hashes byte), and nested, i.e. an outer hash will be
made only over all the inner hash packets.  e.g. RMD+ ( SHA+ ( plaintext )
SHA= ) RMD =

Alternative 3: only 1 MDC allowed, with version, algid, and checksum.

Then any plaintext packets (should this be required to be 1?).

Then the real MDCP but is 20 (or whatever the hash length(s) is(are) )
bytes longer than the one at the top, and has a checksum which reflects
the full packet.

So would a header MDCP, and having both MDCPs checksummed be adequately
secure?  If the entirety was encrypted how would you attack it?  You would
have to change two algorithm ID bytes, come up with two correct checksums,
and a valid hash for the algorithm you are altering the hash algorithm to.

---

From: Werner Koch <[email-masked]>
Date: Wed, 19 May 1999 17:43:45 +0200

> able to use it here?  (Or if OpenPGP comes up with a wider DSA, say SHA

Not for the purpose of a MDC, even the 160 bit digest is overkill, but
we already have to use it elsewhere so it does make sense to use it.

> wider, i.e. better (PRZ can do a commercial for GM) hash algorithm, since

(What is GM?)

> can use a modified DSA, and depricate and drop ElGamal signatures.  And if

But a MDC is very different to a signature and there is no need for
wider hash.

> only the version number and algorithm ID(s), and a checksum word.

I think that is much to complicated and I can't see the benefit from
it.  Putting a checksum (or a copy of the algid and version number)
into the encrypted text  E(random_prefix,2_checkbytes,version_byte,
algorithm byte) is much easier and all waht we need.  We already
encode the cipher algorithm in the pk-encoded sessionkey - so why I 
see no argument why not putting additional input into the encrypted 
packet.

> bytes longer than the one at the top, and has a checksum which reflects

Why an extra checksum if we already have an MDC?

---

From: Jon Callas <[email-masked]>
Date: Thu, 20 May 1999 23:50:25 -0700

At 7:26 AM -0700 5/19/1999, Werner Koch said:

I believe that it's true that we don't need all the properties of a
cryptographic hash. The reason for picking SHA-1 is that an implementation
already has to have SHA-1, so it's a favor to anyone who wants to do a
minimal implementation.

I did a design for this late last year that had a hash selector. The
objection to a selector on the hash algorithm is simply that an attacker
could potentially modify the hash selector and cause mischief. I'm
skeptical as to what sort of mischief they could really cause, but I see
the point.

For this purpose, SHA-1 is good enough. Actually, for this purpose, MD4
(which is known to be broken as a signature hash) is good enough. Remember,
we have in this packet (presumably) unknown plaintext (if the attacker
knows the plaintext of the message, I think there are other problems)
sealed with a strong cipher. We don't need all the properties of a
cryptographic hash. I'm in favor of picking SHA-1, just because it's handy.

	Jon

---

From: Tom Zerucha <[email-masked]>
Date: Fri, 21 May 1999 22:45:23 -0400

> we already have to use it elsewhere so it does make sense to use it.

We also have a 24 bit CRC which must be implemented for the ASCII armor
and it is even faster.  If that is adequate (and faster), why not use it
instead of a cryptographic hash?

> > wider, i.e. better (PRZ can do a commercial for GM) hash algorithm, since

General Motors - they have an ad campaign for one of the cars of the theme
"Wider is Better".

> see no argument why not putting additional input into the encrypted 

Where exactly?  We have a packet header for the encrypted packet itself,
the key material from the PK or SK material packet, and potential
information in a packet at the head of the encrypted plaintext.

(see my next comment)

> Why an extra checksum if we already have an MDC?

Because someone was suggesting that if anyone ever changed the algorithm
ID byte they could turn off the MDC.  That could be prevented by a
checksum.  If it is not reasonable to have an attack of this form, then
there should be no problem having an algorithm ID byte.  But if it is
unencrypted, it can be changed.

And I might want to specify other algorithm IDs, e.g. the Palm Pilot has
MD5 (and DES) in the OS kernel, but not SHA1.  I would really prefer to
have my MDCs there as MD5, and use 3DES for a minimal Palm implementation.

In either case, the MDC proper should be encapsulated in a packet, and if
the algorithm can be specified as I want (maybe 0 could be the ASCII CRC)
the algorithm ID with version number should be in a packet and preceed the
encrypted data.

---

From: Werner Koch <[email-masked]>
Date: Sat, 22 May 1999 12:15:50 +0200

> instead of a cryptographic hash?

ASCII armor is SHOULD, SHA1 is MUST.  May people would not feel
comfortable with CRC and there is a chance of an attack on a CRC used
as a MDC.

> ID byte they could turn off the MDC.  That could be prevented by a

Ah well, I think it is easier to put a copy of the version byte and
the algorithm identifier into the encrypted text:

E(random_prefix[blocksize+2],version_byte,algo_byte,plaintext,mdc_packet)

> have my MDCs there as MD5, and use 3DES for a minimal Palm implementation.

Makes sense for me.  And I think it is better to use OpenPGP
dataformats than to use somethin else or invent another one.

Is it okay to have SHOULD use SHA1-MDC and SHOULD give a warning if
another MDC is used? 

  Werner

---

From: uri <[email-masked]>
Date: Sun, 23 May 1999 03:34:17 -0400 (EDT)

> E(random_prefix[blocksize+2],version_byte,algo_byte,plaintext,mdc_packet)

Yes. And we could require that MDC can *not* be turned off.
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

---

From: uri <[email-masked]>
Date: Sun, 23 May 1999 03:34:17 -0400 (EDT)

---

From: Tom Zerucha <[email-masked]>
Date: Tue, 25 May 1999 11:14:39 -0400

> E(random_prefix[blocksize+2],version_byte,algo_byte,plaintext,mdc_packet)

Blocksize+2?  Are we doing PGP-cfbs still?  Also, by mdc_packet, I take it
to mean you mean a real packet (i.e. there is a virtual EOF after the
plaintext)?

> Is it okay to have SHOULD use SHA1-MDC and SHOULD give a warning if

I think SHOULD use SHA1-MDC is best, but I am not sure about the warning
part.  I think it might be proper to give a warning on the creation (much
like giving a warning against using MAY or private algorithms other places
where most PGP implementations won't be able to handle it).

I forget if RMD160 or MD5 in the normal context are MAY or SHOULDs, but if
they are SHOULDs, I wouldn't want to give a warning.  Implementations
SHOULD be able to use any hash for MDC that they use for signatures.

---

From: Werner Koch <[email-masked]>
Date: Tue, 25 May 1999 17:22:58 +0200

> Blocksize+2?  Are we doing PGP-cfbs still?  Also, by mdc_packet, I take it

Sure ;-)  But without the extra sync step.

> to mean you mean a real packet (i.e. there is a virtual EOF after the

Yes.

> like giving a warning against using MAY or private algorithms other places

You are right.  It is not a security issue if one of the other hash
algorithms is used - but it may lead to a problem at the receivers
side to verify the MDC.

---

From: [email-masked] (Bodo Moeller)
Date: Fri, 28 May 99 00:23 +0200

> Yes. And we could require that MDC can *not* be turned off.

What does that mean for existing implementations?  Will they tolerate
the extra packets?

---

From: uri <[email-masked]>
Date: Fri, 28 May 1999 01:26:05 -0400 (EDT)

> What does that mean for existing implementations? Will they tolerate

Will they tolerate the extra encryption algorithms? The extra
signature methods? The extra...?

In short, let bygones be bygones.
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

---

From: [email-masked] (Bodo Moeller)
Date: Fri, 28 May 1999 21:22:02 +0200

On Fri, May 28, 1999 at 01:26:05AM -0400, uri wrote:

>>> [...] we could require that MDC can *not* be turned off.
>> What does that mean for existing implementations?
> [...] let bygones be bygones.

Then why not dump plain ElGamal encryption in favor of DHAES (see
http://www.cse.ucsd.edu/users/mihir/papers/pke.html), DHAES being used
on whole messages, not just session keys?  (DHAES is basically ElGamal
done right plus an MDC, and there are security proofs for it.)

Date: Fri, 28 May 1999 21:22:02 +0200
From: [email-masked] (Bodo Moeller)
To: uri <[email-masked]>
Cc: [email-masked]
Subject: Re: Agree with PRZs MDC suggestion
Sender: [email-masked]

On Fri, May 28, 1999 at 01:26:05AM -0400, uri wrote:

>>> [...] we could require that MDC can *not* be turned off.
>> What does that mean for existing implementations?
> [...] let bygones be bygones.

Then why not dump plain ElGamal encryption in favor of DHAES (see
http://www.cse.ucsd.edu/users/mihir/papers/pke.html), DHAES being used
on whole messages, not just session keys?  (DHAES is basically ElGamal
done right plus an MDC, and there are security proofs for it.)

Date: Fri, 28 May 1999 12:37:01 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: V5 signatures
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Werner Koch <[email-masked]> writes:

> However, the octet count for the [un]hashed subpackets is limited to
> 65535.

It just came to my mind, that large signature packets (currently they
have a limit of about 128k) do impose a problem:

It will then not be possible to keep the complete signature packet in
memory.  Signatures may be (theoretical) very large - up to 4 Gigs and
due to this they have to be handled like plaintext.

Doess it really make sense to build a protocol - based on OpenPGP - 
which puts all it's dat into a signature packet?  Such data should go
into a literal text packet or some new packet type.

Date: Fri, 28 May 1999 11:27:10 +0200
From: Thomas Roessler <[email-masked]>
To: [email-masked]
Subject: Re: V5 signatures
Sender: [email-masked]

On 1999-05-28 10:10:29 +0200, Werner Koch wrote:

> Because this is a conflict we really should address it with a new
> v5 signature paket.  Changes to an implementaion are minimal.  And
> while we are at it, we should consider to apply some rules to the
> name part of notation data - so that we can have unique names.
> Thomas Roessler already mentioned this and proposed a SSH like
> scheme for this.

I wouldn't confine this to V5 signatures. ;)

As for notation data naming, the suggestion is as follows.  It's
derived from what the secsh internet drafts do for "registering"
new algorithms.

------------------------------

Notation data naming

   OpenPGP "notation data" signature sub-packets traditionally consist
   of a name and a value, both of which are arbitrary, UTF-8 encoded
   strings.

   The OpenPGP standard does not define any registry for defined
   notation data names, nor does it describe safe extension mechanisms.

   The present document defines two name spaces for notation data names:
   The IETF name space and the user name space.

   Notation data names in the IETF name space consist of an arbitrary
   string of UTF-8 encoded characters, with the exception that the
   character "@" ("at") MUST NOT occur in such a name.

   XXX - describe IANA registration procedures.

   Notation data names in the user name space consist of a tag, followed
   by the "@" character, followed by a DNS domain name.  The tag may be
   an arbitrary string of UTF-8 encoded characters, with the exception
   that the character "@" MUST NOT occur in such a name.  The DNS domain
   name must be under the exclusive control of the person or entity
   which introduces the notation data name in question.

   For example, if The Example Corporation wishes to introduce sample
   notation data, the appropriate notation data name could be
   "[email-masked]".

------------------------------

Date: Fri, 28 May 1999 10:10:29 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: V5 signatures
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Jon Callas <[email-masked]> writes:

> No, it's there for things like PGP ticket. If someone is building a
> lightweight authorization scheme, it's conceivable that a signature would
> need to be bigger than 8383 bytes. V4 signatures don't allow that.

How did you calculate this?

5.2.3.1 says somewhere:

       if the 1st octet = 255, then
           lengthOfLength = 5
           subpacket length = [four-octet scalar starting at 2nd_octet]

However, the octet count for the [un]hashed subpackets is limited to
65535.

Because this is a conflict we really should address it with a new v5
signature paket.  Changes to an implementaion are minimal.  And while
we are at it, we should consider to apply some rules to the name part
of notation data - so that we can have unique names.  Thomas Roessler
already mentioned this and proposed a SSH like scheme for this.

From: uri <[email-masked]>
Subject: Re: Agree with PRZs MDC suggestion
To: [email-masked] (Bodo Moeller)
Date: Fri, 28 May 1999 01:26:05 -0400 (EDT)
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

Date: Thu, 27 May 1999 17:03:06 -0700
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: critical notation data sub-packets
Sender: [email-masked]

The purpose of the notation subpackets is to have a general-purpose
mechanism for implementors to put in their own extensions, so yes, people
should (in general) use those for any private or controversial additions to
signatures.

Sooner or later, we probably will need a registration system for them, or
some naming convention. Right now, there are a number of obvious things you
can do to restrict conficts, like prefixing your notation name with a
domain name (like foobar.com-private-value) and that will work.

This saves the subpacket versions for something we know we need -- for
example a subpacket that has an implemented features list (like MDC data
packets).

As for the critical bit, in my opinion, it is a way for the writer of a
signature to tell something to the reader. The reader, though, always has
the final say. A few examples:

A human-readable subpacket that's marked critical seems to be something
that the writer really wanted the reader to see. But the reader's software
may have an option to turn it off. I can see where someone might put
human-readable limits of liability or other such crud in there, and I don't
want to have legalese pop up in a window every time I use someone's key.
(But in such a case, I might solve it by deleting that signature,
personally.) So it's perfectly reasonable for an implementation to ignore a
critical human-readable notation. Similarly, a system that's running as a
robot is correct to ignore a critical human readable subpacket.

I think that it's merely impolite (as opposed to non-compliant) for an
implementation to ignore a critical bit. I'll spin another scenario.
Suppose XYZcorp makes an OpenPGP implementation, and they create some
feature that they want everyone else to support, so they mark it as
"critical" in all signatures they create. It's obnoxious, but it wouldn't
be the first time a vendor tried to bully features into a standard. If
another vendor ignored all critical bits on notations that started with
"xyzcorp.com" because of abuse of criticality, I wouldn't call them
non-compliant. If a different vendor was even more gonzo, again, it's up to
users to appeal to them to do the right thing (whatever than means). I
don't want to see it be a standards issue.

This is also the reason why we have a "receiver wins" policy in algorithms.
It is to forestall the case where someone tries to force their feature on
the world.

	Jon

Date: Thu, 27 May 1999 16:35:37 -0700
To: Anonymous <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: V5 signatures
Sender: [email-masked]

At 11:19 AM -0700 4/23/1999, Anonymous said:

Sorry for dropping this on the floor..

   > (4) A V5 signature packet that allows 4-byte lengths.

   Yet another signature packet version! Is this a scheme to increase
   S/MIME support?

No, it's there for things like PGP ticket. If someone is building a
lightweight authorization scheme, it's conceivable that a signature would
need to be bigger than 8383 bytes. V4 signatures don't allow that.

	Jon

Date: Fri, 28 May 99 00:23 +0200
From: [email-masked] (Bodo Moeller)
To: [email-masked]
Subject: Re: Agree with PRZs MDC suggestion
Organization: Hamburg University
Sender: [email-masked]

Date: Thu, 27 May 1999 12:36:15 -0700
To: Thomas Roessler <[email-masked]>
From: Jack Repenning <[email-masked]>
Subject: Re: critical notation data sub-packets
Cc: [email-masked]
Sender: [email-masked]

--=====================_100493171==_.ALT
Content-Type: text/plain; charset="us-ascii"

At 03:13 AM 5/26/99 , Thomas Roessler wrote:

>So, to the working group: Should standardized signature extensions
>go into sub-packets of their own, or should one start to standardize
>certain notation data names?

What about the rfc822 weasel:

     extension-field =
                   <Any field which is defined in a document
                    published as a formal extension to this
                    specification; none will have names beginning
                    with the string "X-">
 
     user-defined-field =
                   <Any field which has not been defined
                    in this specification or published as an
                    extension to this specification; names for
                    such fields must be unique and may be
                    pre-empted by published extensions>

I don't believe there's any clearing-house for user-defined-field names (is
there?). 

Informix Software, Inc.        Jack Repenning
Config/Release Mgmt            [email-masked]
4100 Bohannon Drive            M/S: 4100/2
Menlo Park, CA 94025           FAX: 650/926-6571
VOICE: 650/926-1044               PAGE: 800/781-6182
PGP/RSA: D24B E2C2 9AFB 7C24 : 7E59 7885 525D 644E
PGP/DSS: 955C 44AD 8FCE 77D4 9494 \
          : 4AB2 51F1 3EED 3B82 E870

--=====================_100493171==_.ALT
Content-Type: text/html; charset="us-ascii"

<html><div>At 03:13 AM 5/26/99 , Thomas Roessler wrote:</div>
<br>
<div>&gt;So, to the working group: Should standardized signature
extensions</div>
<div>&gt;go into sub-packets of their own, or should one start to
standardize</div>
<div>&gt;certain notation data names?</div>
<br>
<div>What about the rfc822 weasel:</div>
<br>
<div>&nbsp;&nbsp;&nbsp;&nbsp; extension-field =</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;Any field which is defined in a document</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
published as a formal extension to this</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
specification; none will have names beginning</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
with the string &quot;X-&quot;&gt;</div>
<div>&nbsp;</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp; user-defined-field =</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;Any field which has not been defined</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
in this specification or published as an</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
extension to this specification; names for</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
such fields must be unique and may be</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
pre-empted by published extensions&gt;</div>
<br>
I don't believe there's any clearing-house for user-defined-field names
(is there?).
<br>

<br>
<br>
<br>
<br>
<br>
<br>
<b>Inform<font face="Bookman Old Style, Bookman" size=4 color="#FF0000"><i>i</font></i><font face="Bookman Old Style, Bookman" size=4 color="#0000FF">x</font>
</b>Software, Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Jack Repenning<br>
Config/Release Mgmt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [email-masked]<br>
4100 Bohannon Drive&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; M/S: 4100/2<br>
Menlo Park, CA 94025&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; FAX: 650/926-6571<br>
VOICE: 650/926-1044<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&nbsp; PAGE: 800/781-6182<br>
PGP/RSA: D24B E2C2 9AFB 7C24 : 7E59 7885 525D 644E<br>
PGP/DSS: 955C 44AD 8FCE 77D4 9494 \<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 4AB2 51F1 3EED 3B82 E870<br>
</html>

--=====================_100493171==_.ALT--

From: "Emmanuel COLUSSI" <[email-masked]>
To: <[email-masked]>
Subject: LDAP Key Server
Date: Thu, 27 May 1999 11:01:32 +0200
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0072_01BEA830.47CB8790
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I use PGPfree6.0.2i.
I would create a LDAP Key Server.
What DN structure do you use ? for send key=20
and what is the bind login.

Thanks for your help

Emmanuel Colussi
Email : [email-masked]

------=_NextPart_000_0072_01BEA830.47CB8790
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2014.210" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>
<DIV><FONT size=3D2>I use PGPfree6.0.2i.</FONT></DIV>
<DIV><FONT size=3D2>I would create a LDAP Key Server.</FONT></DIV>
<DIV><FONT size=3D2>What DN structure do you use ? for send key =
</FONT></DIV>
<DIV><FONT size=3D2>and what is the bind login.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>Thanks for your help</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV></FONT><FONT size=3D2>Emmanuel Colussi<BR>Email : <A=20
href=3D"mailto:[email-masked]">[email-masked]</A></FONT=
></DIV></DIV></BODY></HTML>

------=_NextPart_000_0072_01BEA830.47CB8790--

Date: Wed, 26 May 1999 12:13:36 +0200
From: Thomas Roessler <[email-masked]>
To: [email-masked]
Subject: Re: critical notation data sub-packets
Sender: [email-masked]

On 1999-05-25 15:31:11 +0200, Werner Koch wrote:

> We should avoid to use private sub-packets when there is another
> way to do the task.

I'm not thinking about private ones. ;-)

The current spec says:

   This subpacket describes a "notation" on the signature that the
   issuer wishes to make. The notation has a name and a value, each
   of which are strings of octets. There may be more than one
   notation in a signature. Notations can be used for any extension
   the issuer of the signature cares to make.

While this is really fine for private extensions, I see a problem
with using notation data to put information into a sigature
sub-packet in a standardized way.  Essentially, we are lacking a
registry (or a conflict-free naming scheme) for notation data names.

So, to the working group: Should standardized signature extensions
go into sub-packets of their own, or should one start to standardize
certain notation data names?

From: [email-masked]
Date: Tue, 25 May 1999 08:51:01 -0700
To: [email-masked], [email-masked]
Subject: Re: critical notation data sub-packets
Sender: [email-masked]

Thomas Roessler, <[email-masked]>, writes:
> How do the current implementations handle this situation (most
> notably the NAI ones)?  Should the specification be changed?  Should
> extensions to RFC 2440 which have to put critical information into
> signatures define sub-packets of their own, or should they use
> notation data to avoid name-space cluttering?

The NAI software ignores notation packets.  If they are marked critical,
it treats the signature as invalid for trust calculation purposes.

Notation data is meant as an extension mechanism which is more text
oriented rather than using new binary signature packets.

I would suggest that if the human-readable bit is set, the only
obligation on the part of the application is to display it to the user.
If it does so, then it can consider the notation "handled" and it can
validate the signature even if the critical bit is set.  (Probably it
would be a good idea to note to the user that the critical bit was set,
when the notation was displayed.)

If the human-readable bit is not set, then the application should see
if the name field in the notation is one that it recognizes the meaning
of.  If not, and the critical bit is set, it should not validate the
signature, because it doesn't know what this critical packet is trying
to say.

Hal Finney
Network Associates, Inc.

Date: Tue, 25 May 1999 17:22:58 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: Agree with PRZs MDC suggestion
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Yes.

Date: Tue, 25 May 1999 11:14:39 -0400
From: Tom Zerucha <[email-masked]>
To: Werner Koch <[email-masked]>
cc: [email-masked]
Subject: Re: Agree with PRZs MDC suggestion
Sender: [email-masked]

Date: Tue, 25 May 1999 15:31:11 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: critical notation data sub-packets
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Thomas Roessler <[email-masked]> writes:

> The specification is a bit ambiguous about "notation data" signature
> subpackets marked as "critical".

I don't think so:  If an implementation encounters notation data with
critical bit set and it completely understands the semantics of this
notation data, it can verify the signature.  

To understand this notation data the implementaion might also want to
consult the policy URL to distinguish between different semantics.

The critical bit does not say anthing about how to handle this
subpacket; the implemenation is only required to understand that this
is critical and there is no required action defined for any
subpackets.  I don't think this is within the scope of OpenPGP. 
Definitions of the trust modell and the classes of signatures are 
are on purpose very loose.

> extensions to RFC 2440 which have to put critical information into
> signatures define sub-packets of their own, or should they use

We should avoid to use private sub-packets when there is another way 
to do the task. 

Date: Tue, 25 May 1999 13:55:19 +0200
From: Thomas Roessler <[email-masked]>
To: [email-masked]
Subject: critical notation data sub-packets
Sender: [email-masked]

The specification is a bit ambiguous about "notation data" signature
subpackets marked as "critical".

Implementors may assume that their implementations can safely ignore
such subpackets since they do "understand" "notation data".  This
may lead to problems with human-readable notation data whose display
to the user may be critical for whatever reason (including legal
ones, think liability limitations), and it may lead to even worse
problems with notation data which is not human-readable.

How do the current implementations handle this situation (most
notably the NAI ones)?  Should the specification be changed?  Should
extensions to RFC 2440 which have to put critical information into
signatures define sub-packets of their own, or should they use
notation data to avoid name-space cluttering?

From: uri <[email-masked]>
Subject: Re: Agree with PRZs MDC suggestion
To: [email-masked] (Werner Koch)
Date: Sun, 23 May 1999 03:34:17 -0400 (EDT)
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

Date: Mon, 24 May 1999 19:27:13 -0400 (EDT)
From: "David M. Balenson" <[email-masked]>
To: [email-masked]
Subject: REMINDER: CFP: ISOC Year 2000 Netw. & Distr. Sys. Security Symp. (NDSS 2000)
Sender: [email-masked]

            C  A  L  L       F  O  R       P  A  P  E  R  S

                          The Internet Society
           Year 2000 Network and Distributed System Security 
                         Symposium (NDSS 2000)

             Catamaran Resort Hotel, San Diego, California
                           February 2-4, 2000

IMPORTANT DATES:

  Paper and panel submissions due: June 16, 1999
  Author notification: August 17, 1999
  Final versions of papers and panels due: October 15, 1999

GOAL: 

  This symposium aims to foster information exchange among researchers
  and practitioners of network and distributed system security
  services.  The intended audience includes those who are interested
  in practical aspects of network and distributed system security,
  with the focus on actual system design and implementation, rather
  than theory. A major goal of the symposium is to encourage and
  enable the Internet community to apply, deploy, and advance the
  state of available security technology.  The proceedings of the
  symposium will be published by the Internet Society.

  Submissions are solicited for, but are not limited to, the
  following topics:

  * Secure Electronic Commerce, e.g., payment, barter, EDI,
    notarization/timestamping, endorsement and licensing.
  * Intellectual Property Protection: protocols, schemas,
    implementations, metering, watermarking, other forms of rights
    management.
  * Implementation, deployment and management of network security
    policies.
  * Integrating Security in Internet protocols: routing, naming,
    TCP/IP, multicast, network management, and, of course, the Web.
  * Attack-resistant protocols and services.
  * Special problems and case studies: e.g. interplay and tradeoffs
    between security and efficiency, usability, reliability and cost.
  * Security for collaborative applications and services: tele- and
    video-conferencing, groupwork, etc.
  * Fundamental services: authentication, data integrity,
    confidentiality, authorization, non-repudiation, and availability.
  * Supporting mechanisms and APIs: key management and certification,
    revocation, audit trails and accountability.
  * Integrating security services with system and application security
    facilities and protocols, e.g., message handling, file
    transport/access, directories, time synchronization, data base
    management, boot services, mobile computing.
  * Security for emerging technologies -- sensor networks, specialized
    testbeds, wireless/mobile (and ad hoc) networks, personal
    communication systems, and large heterogeneous distributed systems.
  * Intrusion Avoidance, Detection, and Response: systems, experiences
    and architectures
  * Network Perimeter Controls: firewalls, packet filters, application
    gateways.

BEST PAPER AWARD:

  A best paper award will be introduced at NDSS 2000. This award will
  be presented at the symposium to the authors of the best paper to
  be selected by the program committee.

GENERAL CHAIR:
  Stephen Welke, Trusted Computer Solutions

PROGRAM CO-CHAIRS:
  Gene Tsudik, USC / Information Sciences Institute
  Avi Rubin, AT&T Labs - Research

TUTORIAL CHAIR:
  Doug Maughan, NSA / DARPA

PROGRAM COMMITTEE:
  Bill Cheswick, Lucent Bell Labs  
  Marc Dacier, IBM Research Zurich 
  Jim Ellis, CMU / CERT
  Carl Ellison, Intel   
  Ed Felten, Princeton  
  Virgil Gligor, UMD College Park 
  Thomas Hardjono, Bay Networks/Nortel
  Cynthia Irvine, Naval Postgraduate School
  Charlie Kaufman,  Iris Associates
  Dave Kormann, AT&T Labs - Research 
  Hugo Krawczyk, Technion and IBM
  Carl Landwehr, Naval Research Lab
  Doug Maughan, NSA / DARPA   
  Gary McGraw, Reliable Software Technologies  
  Sandra Murphy, TIS Labs at Network Associates   
  Clifford Neuman, USC / Information Sciences Institute
  Paul Van Oorschot, Entrust
  Sami Saydjari, DARPA ISO 
  David Wagner, UC Berkeley   
  Bennet Yee, UC San Diego

LOCAL ARRANGEMENTS CHAIR:
  Thomas Hutton, San Diego Supercomputer Center

PUBLICATIONS CHAIR:
  John Kochmar, SEI

PUBLICITY CHAIR:
  David Balenson, TIS Labs at Network Associates   

LOGISTICS CHAIR:
  Carla Rosenfeld, Internet Society

REGISTRATIONS CHAIR
  Beth Strait, Internet Society

SUBMISSIONS: 

  The committee invites both technical papers and panel proposals.
  Technical papers should be at most 20 pages long. Panel proposals
  should be at most two pages and should describe the topic, identify
  the panel chair, explain the format of the panel, and list three
  to four potential panelists.  Technical papers will appear in
  the proceedings. A description of each panel will appear in the
  proceedings, and may -- at the discretion of the panel chair --
  include written position statements from the panelists.

  Each submission must contain a separate title page with the type
  of submission (paper or panel), the title or topic, the names of
  the author(s), organizational affiliation(s), telephone and FAX
  numbers, postal addresses, e-mail addresses, and must specify
  the contact author in case of multi-author submissions. The names
  of authors, affiliations, and other identifying information should
  appear only on the separate title page.

  Submissions must be received by June 16, 1999, and must be made
  via electronic mail in either PostScript or ASCII format.  If
  the committee is unable to print a PostScript submission, a
  hardcopy will be requested. Therefore, PostScript submissions
  must arrive well before the deadline.

  All submissions and program related correspondence (only) should
  be directed to the program chair:

        Gene Tsudik     
        USC Information Sciences Institute      
        4676 Admiralty Way      
        Marina Del Rey, CA 90292        
        Email: [email-masked]
        TEL: +1 (310) 822-1511 ext 329
        FAX: +1 (310) 823-6714 

  Dates, final call for papers, advance program, and registration
  information will be available soon at the URL: httl//www.isoc.org/ndss2000.

  Each submission will be acknowledged by e-mail.  If acknowledgment
  is not received within seven days, please contact the program
  chair as indicated above.  Authors and panelists will be notified
  of acceptance by August 17, 1999.  Instructions for preparing
  camera-ready copy for the proceedings will be sent at that time.
  The camera-ready copy must be received by October 15, 1999.

From: uri <[email-masked]>
Subject: Re: Agree with PRZs MDC suggestion
To: [email-masked] (Werner Koch)
Date: Sun, 23 May 1999 03:34:17 -0400 (EDT)
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

Date: Sat, 22 May 1999 12:15:50 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: Agree with PRZs MDC suggestion
Mail-Followup-To: [email-masked]
Sender: [email-masked]

  Werner

Date: Fri, 21 May 1999 22:45:23 -0400
From: Tom Zerucha <[email-masked]>
To: Werner Koch <[email-masked]>
cc: [email-masked]
Subject: Re: Agree with PRZs MDC suggestion
Sender: [email-masked]

(see my next comment)

Date: Thu, 20 May 1999 23:50:25 -0700
To: Werner Koch <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Agree with PRZs MDC suggestion
Sender: [email-masked]

	Jon

Date: Wed, 19 May 1999 17:43:45 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: Agree with PRZs MDC suggestion
Mail-Followup-To: [email-masked]
Sender: [email-masked]

(What is GM?)

Date: Wed, 19 May 1999 10:55:25 -0400
From: [email-masked]
To: [email-masked]
cc: [email-masked], [email-masked]
Subject: Re: Agree with PRZs MDC suggestion
Sender: [email-masked]

Date: Wed, 19 May 1999 16:26:20 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: Agree with PRZs MDC suggestion
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Date: Wed, 19 May 1999 16:18:48 +0200 (CEST)
From: Marcel Waldvogel <[email-masked]>
To: [email-masked]
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Agree with PRZs MDC suggestion
Sender: [email-masked]

[...]

Hal,

-Marcel

Date: Wed, 19 May 1999 10:12:08 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: Agree with PRZs MDC suggestion
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Okay.

Date: Wed, 19 May 1999 09:40:22 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: Then it is not a signature...
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Tom Zerucha <[email-masked]> writes:

> Anything without a PGP digital signature belongs in a literal packet, or
> perhapse elsewhere.  Hashed but unsigned anything is still being discussed
> - i.e. what form the MDC stuff will take.

I proposed this only to help Hal getting PGP OpenPGP conform.  And
with this change your MDC signatures would benefit too.  But okay,
if nobody likes this - forget about it.

Date: Tue, 18 May 1999 19:24:13 -0700
From: [email-masked]
To: [email-masked], [email-masked]
Subject: Re: Agree with PRZs MDC suggestion
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Hal

=====

Date: Tue, 18 May 1999 13:36:51 -0400
From: Tom Zerucha <[email-masked]>
To: Werner Koch <[email-masked]>
cc: [email-masked]
Subject: Then it is not a signature...
Sender: [email-masked]

On Tue, 18 May 1999, Werner Koch wrote:

> [email-masked] writes:
> 
> > unused public key algorithm, so that no implementations will attempt
> > to verify the signature.  I used zero, but we could use 100 if that
> 
> So what about this small change:
> 
> 
> 5.2.3. Version 4 Signature Packet Format
> 
>    The body of a version 4 Signature Packet contains:
> 
>      - One-octet version number (4).
> 
>      - One-octet signature type.

Would this even apply?

> |    - One-octet public key algorithm or a value of zero to indicate
> |      that no multi-precision integers follow.

The PGP signature consists of the MPIs, therefore if there are no MPIs,
there is no signature...

>      - One-octet hash algorithm.

Why is anything hashed if the result (except for 2 bytes) has no where to
go?  So should this even be here?

>      - Two-octet scalar octet count for following hashed subpacket
>        data. Note that this is the length in octets of all of the hashed
>        subpackets; a pointer incremented by this number will skip over
>        the hashed subpackets.
> 
>      - Hashed subpacket data. (zero or more subpackets)

If we can't do anything with the result, why have anything here?  (Also is
it really zero since I think there are some MUST subpackets).  Shouldn't
all this be in the unhashed area if it isn't being hashed, much less
signed?

>      - Two-octet scalar octet count for following unhashed subpacket
>        data. Note that this is the length in octets of all of the
>        unhashed subpackets; a pointer incremented by this number will
>        skip over the unhashed subpackets.
> 
>      - Unhashed subpacket data. (zero or more subpackets)
> 
>      - Two-octet field holding left 16 bits of signed hash value.
> 
> |    - Zero or more multi-precision integers comprising the signature.
> |      This portion is algorithm specific, as described above.

Then this is not a signature, so why put it in the signature packet?

Anything without a PGP digital signature belongs in a literal packet, or
perhapse elsewhere.  Hashed but unsigned anything is still being discussed
- i.e. what form the MDC stuff will take.

From: "William H. Geiger III" <[email-masked]>
Date: Tue, 18 May 1999 11:21:52 -0400
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: PGP 6.5
Sender: [email-masked]

In <[email-masked]>, on 05/14/99 
   at 10:03 AM, Hironobu Suzuki <[email-masked]> said:

>> If you send me a copy of the key I can analyze it for you.

>Thanks. I'll send you it.

Hi,

I have done a partial analysis of the key. It should be noted that this is
not a key generated by PGP 6.5.x but it has been processed by it. The key
in question was generated & signed 1996-08-01, and it is a RSA public key.
The error is in the self signature which has a signature algorithm of '00'
which is an undefined and illegal value for a public key algorithm. Some
of the other signature items look questionable. I am not sure why a bad
signature would cause the servers to crash, it should not (I am not even
sure why a signature would affect the server at all).

I did a search on the Public Key Servers and could not find this key
(keyID 0x12D6870D) on any of them (or for that matter any PGP key for
<[email-masked]>). I did find a copy of this key on the NAI's
LDAP server. 

As a side note:

There seems to be a problem with the LDAP search engine. A search of the
server by userID parameter of: [email-masked] does not find the
above key. A search by exact keyID does find the key.

A second side note:

I have my doubts about Thawte. I could not find their PGP key anywhere on
their site. In addition to this their SSL cert for their webpages expired
in '96 !!! This does not lend confidence to a CA, IMNSHO.

-- 

Analysis of the key follows:

 Public Key Block:
 =================

 99          -- 1 0 0110 01 : Old format, Public Key, Next 2 octets Length
 00 8F       -- Length 143 octets
 03          -- Version 3
 31 FF F3 80 -- Creation Date: 1 Aug 1996
 00 00       -- Expiration Date: Never
 01          -- Public Key Algorithm: RSA
 04 -> 0D    -- MPI #1 Public Modulus n
 04 00       -- MPI #1 Length 130 octets (128 + 2 length octets)
 00 -> 01    -- MPI #2 Exponent e 
 00 11       -- MPI #2 Length 5 octets (3 + 2 length octets)

 64 Bit KeyID:  C2 B5 66 22 12 D6 87 0D
 32 Bit KeyID:  12 D6 87 0D

 Raw Data Block:

 99 00 8F 03 31 FF F3 80 00 00 01 04 00 D3 A4 50
 6E C8 FF 56 6B E6 CF 5D B6 EA 0C 68 75 47 A2 AA
 C2 DA 84 25 FC A8 F4 47 51 DA 85 B5 20 74 94 86
 1E 0F 75 C9 E9 08 61 F5 06 6D 30 6E 15 19 02 E9
 52 C0 62 DB 4D 99 9E E2 6A 0C 44 38 CD FE BE E3
 64 09 70 C5 FE B1 6B 29 B6 2F 49 C8 3B D4 27 04
 25 10 97 2F E7 90 6D C0 28 42 99 D7 4C 43 DE C3
 F5 21 6D 54 9F 5D C3 58 E1 C0 E4 D9 5B B0 B8 DC
 B4 7B DF 36 3A C2 B5 66 22 12 D6 87 0D 00 11 01
 00 01 

 UserID Block:
 =============

 B4       -- 1 0 1101 00 : Old format, UserID Key, Next octet length
 2A       -- Length 42 octets
 54 -> 3E -- UserID
 
 UserID: Thawte Server CA <[email-masked]> 

 Raw Data:

 B4 2A 54 68 61-77 74 65-20 53 65 72 76 65
 72 20 43 41 20 3C 73 65-72 76 65 72 2D 63 65 72
 74 73 40 74 68 61 77 74-65 2E 63 6F 6D 3E 

 Signature Block:
 ================

 89        -- 1 0 0010 01 : Old format, Signature, Next 2 octets length
 03 3A     -- Length 826 octets
 04        -- Version 4 signature
 10        -- Signature on PubKey & UserID
 00        -- Public Key Algorithm 0 <=== ERROR!!!
 01        -- MD5 Hash
 03 2D     -- Hashed SubPacket Length 813 octets
 05 -> 47  -- Hashed SubPacket Data
 00 00     -- Unhashed SubPacket Length 0 octets
 00 00     -- Left 16 bits signed hash value
 00 01     -- MPI #1 length 3 octets (1 + 2 length octets)
 01        -- MPI #1 RSA signature value m**d

 Hashed SubPacket Data:

 05           -- Length 5 octets
 02           -- Type: Creation Date
 31 FF F3 80  -- 1 Aug 1996
 
 05           -- Length 5 octets
 03           -- Type: Expiration Date
 2D EE 72 7F  --

 03           -- Length 3
 05           -- Type: Trust Signature
 FF 78        -- Trust Level 255, Trust Amount 120 (complete)

 C2 5B        -- Length 795
 64           -- Type: Unknown [100] Internal Use

 Raw Data:

 89 03
 3A 04 10 00 01 03 2D 05-02 31 FF F3 80 05 03 2D
 EE 72 7F 03 05 FF 78 C2-5B 64 01 01 03 30 82 03
 13 30 82 02 7C A0 03 02-01 02 02 01 01 30 0D 06
 09 2A 86 48 86 F7 0D 01-01 04 05 00 30 81 C4 31
 0B 30 09 06 03 55 04 06-13 02 5A 41 31 15 30 13
 06 03 55 04 08 13 0C 57-65 73 74 65 72 6E 20 43
 61 70 65 31 12 30 10 06-03 55 04 07 13 09 43 61
 70 65 20 54 6F 77 6E 31-1D 30 1B 06 03 55 04 0A
 13 14 54 68 61 77 74 65-20 43 6F 6E 73 75 6C 74
 69 6E 67 20 63 63 31 28-30 26 06 03 55 04 0B 13
 1F 43 65 72 74 69 66 69-63 61 74 69 6F 6E 20 53
 65 72 76 69 63 65 73 20-44 69 76 69 73 69 6F 6E
 31 19 30 17 06 03 55 04-03 13 10 54 68 61 77 74
 65 20 53 65 72 76 65 72-20 43 41 31 26 30 24 06
 09 2A 86 48 86 F7 0D 01-09 01 16 17 73 65 72 76
 65 72 2D 63 65 72 74 73-40 74 68 61 77 74 65 2E
 63 6F 6D 30 1E 17 0D 39-36 30 38 30 31 30 30 30
 30 30 30 5A 17 0D 32 30-31 32 33 31 32 33 35 39
 35 39 5A 30 81 C4 31 0B-30 09 06 03 55 04 06 13
 02 5A 41 31 15 30 13 06-03 55 04 08 13 0C 57 65
 73 74 65 72 6E 20 43 61-70 65 31 12 30 10 06 03
 55 04 07 13 09 43 61 70-65 20 54 6F 77 6E 31 1D
 30 1B 06 03 55 04 0A 13-14 54 68 61 77 74 65 20
 43 6F 6E 73 75 6C 74 69-6E 67 20 63 63 31 28 30
 26 06 03 55 04 0B 13 1F-43 65 72 74 69 66 69 63
 61 74 69 6F 6E 20 53 65-72 76 69 63 65 73 20 44
 69 76 69 73 69 6F 6E 31-19 30 17 06 03 55 04 03
 13 10 54 68 61 77 74 65-20 53 65 72 76 65 72 20
 43 41 31 26 30 24 06 09-2A 86 48 86 F7 0D 01 09
 01 16 17 73 65 72 76 65-72 2D 63 65 72 74 73 40
 74 68 61 77 74 65 2E 63-6F 6D 30 81 9F 30 0D 06
 09 2A 86 48 86 F7 0D 01-01 01 05 00 03 81 8D 00
 30 81 89 02 81 81 00 D3-A4 50 6E C8 FF 56 6B E6
 CF 5D B6 EA 0C 68 75 47-A2 AA C2 DA 84 25 FC A8
 F4 47 51 DA 85 B5 20 74-94 86 1E 0F 75 C9 E9 08
 61 F5 06 6D 30 6E 15 19-02 E9 52 C0 62 DB 4D 99
 9E E2 6A 0C 44 38 CD FE-BE E3 64 09 70 C5 FE B1
 6B 29 B6 2F 49 C8 3B D4-27 04 25 10 97 2F E7 90
 6D C0 28 42 99 D7 4C 43-DE C3 F5 21 6D 54 9F 5D
 C3 58 E1 C0 E4 D9 5B B0-B8 DC B4 7B DF 36 3A C2
 B5 66 22 12 D6 87 0D 02-03 01 00 01 A3 13 30 11
 30 0F 06 03 55 1D 13 01-01 FF 04 05 30 03 01 01
 FF 30 0D 06 09 2A 86 48-86 F7 0D 01 01 04 05 00
 03 81 81 00 07 FA 4C 69-5C FB 95 CC 46 EE 85 83
 4D 21 30 8E CA D9 A8 6F-49 1A E6 DA 51 E3 60 70
 6C 84 61 11 A1 1A C8 48-3E 59 43 7D 4F 95 3D A1
 8B B7 0B 62 98 7A 75 8A-DD 88 4E 4E 9E 40 DB A8
 CC 32 74 B9 6F 0D C6 E3-B3 44 0B D9 8A 6F 9A 29
 9B 99 18 28 3B D1 E3 40-28 9A 5A 3C D5 B5 E7 20
 1B 8B CA A4 AB 8D E9 51-D9 E2 4C 2C 59 A9 DA B9
 B2 75 1B F6 42 F2 EF C7-F2 18 F9 89 BC A3 FF 8A
 23 2E 70 47 00 00 00 00-00 01 01

-- 
---------------------------------------------------------------
William H. Geiger III  http://www.openpgp.net
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 5.0 at: http://www.openpgp.net/pgp.html
Talk About PGP on IRC EFNet Channel: #pgp Nick: whgiii

Hi Jeff!! :)
---------------------------------------------------------------

From: "William H. Geiger III" <[email-masked]>
Date: Tue, 18 May 1999 08:39:23 -0400
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: MDCs and PGP 6.5.1b15
Sender: [email-masked]

In <[email-masked]>, on 05/17/99 
   at 11:29 PM, [email-masked] said:

>> IMHO the signature looks
>> foobared and violates several aspects of RFC 2440. I don't mind creating a
>> method to convert X.509 stuff to OpenPGP, I don't even mind the X.509
>> certs being encapsulated in a hashed subpacket. But if we are going to do
>> all this the end result should be a valid OpenPGP Key that contains the
>> following 3 elements:
>>
>> Valid OpenPGP Public Key Packet
>> Valid OpenPGP UserID Packet
>> Valid OpenPGP SelfSignature
>>
>> I don't think that the X.509 packet alone should qualify as a valid
>> SelfSignature but instead during the conversion process a OpenPGP
>> SelfSignature should be generated. Of course this would require that a
>> corresponding OpenPGP secret key be generated during the conversion
>> process. Otherwise I really don't see the point of going through the
>> conversion process at all.

>Most of the time there is no secret key available because the signature
>is made by someone other than the person importing the key.  That is the
>typical case for an X.509 certificate.  In that case there is no
>possibility of creating an equivalent PGP secret key because the secret
>key material is not available.

Ok, I see your point here. If the secret key material is not available
during import then I think we should flag the entire key with a new public
key type. My reason for doing this is so standard OpenPGP implementations
know not to use the key as they are unable to verify that it is valid or
not. By adding a new key type it will allow for faster processing as
implementations can make a decision what to do with the key at the
begining of processing rather than waiting until they are done processing
the signature block.

>I don't see the X.509 support in PGP 6.5 as something which will be part
>of the OpenPGP standard.  X.509 is a complex data format and most PGP
>implementations should not have to carry the burden of adding a full
>X.509 library just to support OpenPGP.  The intention is that X.509
>certificates will get turned into signature packets which other
>implementations can ignore without difficulty.

No problem with that. Actually I like it. I do wonder how much of an
advantage it is to import a X.509 public key into OpenPGP format unless
the corresponding secret key can also be converted. It may be simpler in
such cases to leave them in X.509 format and for PGP to have a separate
database to store the keys. If you think about it, no OpenPGP
implementation is going to be able to make use of these keys unless they
have X.509 support built in:

-- Can't use the key to verify signatures as only X.509 certs are going to
be generated from this key pair.

-- Can't use the key for encryption (or at least they should not) as there
is no way to verify or authenticate the key without X.509 capabilities.

In cases where you have a valid OpenPGP key with a mix of X.509 & OpenPGP
signatures on it (I imagine that this is your eventual goal here) I think
that processing would go a lot smother if we had a new signature type for
these converted X.509 sigs. OpenPGP implementations without X.509 support
could then just skip over these sigs during their processing of the key.

>This is done most
>directly by giving it an unused public key algorithm, so that no
>implementations will attempt to verify the signature.  I used zero, but
>we could use 100 if that would help.  Implementations need to be able to
>handle unrecognized public key algorithms, even those which are not
>defined in the current OpenPGP standard.

According to the RFC a 0 algorithm is an invalid number. IMHO 100 would be
better as it lets the processor know that he is dealing with a
private/experimental packet rather than thinking that the signature had
somehow been damaged (my first impression looking at the key this
weekend). You are correct though, no code should core dump because of the
key in question (IMHO core dumps because of input data is poor design). 

>I can make changes for version 6.5.1 which will come out in a few weeks
>(bug fix version) to address problems which are tripping up current
>implementations.

Do you know exactly what is triggering the problem? I sent my analysis to
the keyserver list but I haven't heard anything back yet. Other than
changing the algorithm to 100 and my recommendations for a new public key
& sig types I didn't see anything that is a major problem in the format
(my code didn't have any problems with it). IMHO the keyserver folks need
to do some cleanup of their code. :)

-- 
---------------------------------------------------------------
William H. Geiger III  http://www.openpgp.net
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 5.0 at: http://www.openpgp.net/pgp.html
Talk About PGP on IRC EFNet Channel: #pgp Nick: whgiii

Hi Jeff!! :)
---------------------------------------------------------------

Date: Tue, 18 May 1999 09:30:57 -0400
From: Tom Zerucha <[email-masked]>
To: [email-masked]
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: MDCs and PGP 6.5.1b15
Sender: [email-masked]

On Tue, 18 May 1999 [email-masked] wrote:

> Most of the time there is no secret key available because the signature
> is made by someone other than the person importing the key.  That is
> the typical case for an X.509 certificate.  In that case there is no
> possibility of creating an equivalent PGP secret key because the secret
> key material is not available.

I am missing something here.  You would need the PUBLIC key to validate
the signature.  These are available within the X509 certificate, so you
could use them to come up with a valid PGP signature over the PGP
signature packet (if you own the X509 cert - if you don't you can't vouch
for the validity or would use a PGP key to sign it).

> I don't see the X.509 support in PGP 6.5 as something which will be part
> of the OpenPGP standard.  X.509 is a complex data format and most PGP
> implementations should not have to carry the burden of adding a full X.509
> library just to support OpenPGP.  The intention is that X.509 certificates
> will get turned into signature packets which other implementations can
> ignore without difficulty.  This is done most directly by giving it an
> unused public key algorithm, so that no implementations will attempt
> to verify the signature.  I used zero, but we could use 100 if that
> would help.  Implementations need to be able to handle unrecognized
> public key algorithms, even those which are not defined in the current
> OpenPGP standard.

Unused or "private".  And it doesn't make sense to treat an X.509 RSA key
as not-an-RSA-key, and the same with DSA.  If you are going to use X.509
keys you can pull them into the PGP infrastructure.  And if you have any
secure web browser, you have an X.509 implementation.

It would be better to call this a version 5 signature packet.

And the issue of X.509 being a MAY / SHOULD is different from how it
should be implemented if it exists.  If OpenPGP MAY support X.509, the
details should be discussed here.

> I can make changes for version 6.5.1 which will come out in a few weeks
> (bug fix version) to address problems which are tripping up current
> implementations.

So my implementation (which has an X.509 implmentation in the same library
as the rest of the crypto) should easily work with what you are doing?

Date: Tue, 18 May 1999 09:25:32 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: MDCs and PGP 6.5.1b15
Mail-Followup-To: [email-masked]
Sender: [email-masked]

[email-masked] writes:

> unused public key algorithm, so that no implementations will attempt
> to verify the signature.  I used zero, but we could use 100 if that

So what about this small change:

5.2.3. Version 4 Signature Packet Format

   The body of a version 4 Signature Packet contains:

     - One-octet version number (4).

     - One-octet signature type.

|    - One-octet public key algorithm or a value of zero to indicate
|      that no multi-precision integers follow.

     - One-octet hash algorithm.

     - Two-octet scalar octet count for following hashed subpacket
       data. Note that this is the length in octets of all of the hashed
       subpackets; a pointer incremented by this number will skip over
       the hashed subpackets.

     - Hashed subpacket data. (zero or more subpackets)

     - Two-octet scalar octet count for following unhashed subpacket
       data. Note that this is the length in octets of all of the
       unhashed subpackets; a pointer incremented by this number will
       skip over the unhashed subpackets.

     - Unhashed subpacket data. (zero or more subpackets)

     - Two-octet field holding left 16 bits of signed hash value.

|    - Zero or more multi-precision integers comprising the signature.
|      This portion is algorithm specific, as described above.

Date: Tue, 18 May 1999 09:12:40 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: MDCs and PGP 6.5.1b15
Mail-Followup-To: [email-masked]
Sender: [email-masked]

"William H. Geiger III" <[email-masked]> writes:

> I don't think that the X.509 packet alone should qualify as a valid
> SelfSignature but instead during the conversion process a OpenPGP

We should not discuss the contents of private packets here.  I mailed
this only as an explanation why we mighgt have those problems with the
signature packets.  And becuase the public key algo 0 violates the
RFC, we should only dicusss, whether it might make sense to allow such 
an extension.  

Date: Mon, 17 May 1999 21:29:58 -0700
From: [email-masked]
To: [email-masked], [email-masked]
Subject: Re: MDCs and PGP 6.5.1b15
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

William H. Geiger III, <[email-masked]>, writes:
> I had done a detailed analysis of this key for the PGP-Keyserver Operators
> group this weekend (I can post here if desired).

Yes, that would be useful to see.

> IMHO the signature looks
> foobared and violates several aspects of RFC 2440. I don't mind creating a
> method to convert X.509 stuff to OpenPGP, I don't even mind the X.509
> certs being encapsulated in a hashed subpacket. But if we are going to do
> all this the end result should be a valid OpenPGP Key that contains the
> following 3 elements:
>
> Valid OpenPGP Public Key Packet
> Valid OpenPGP UserID Packet
> Valid OpenPGP SelfSignature
>
> I don't think that the X.509 packet alone should qualify as a valid
> SelfSignature but instead during the conversion process a OpenPGP
> SelfSignature should be generated. Of course this would require that a
> corresponding OpenPGP secret key be generated during the conversion
> process. Otherwise I really don't see the point of going through the
> conversion process at all.

Most of the time there is no secret key available because the signature
is made by someone other than the person importing the key.  That is
the typical case for an X.509 certificate.  In that case there is no
possibility of creating an equivalent PGP secret key because the secret
key material is not available.

I don't see the X.509 support in PGP 6.5 as something which will be part
of the OpenPGP standard.  X.509 is a complex data format and most PGP
implementations should not have to carry the burden of adding a full X.509
library just to support OpenPGP.  The intention is that X.509 certificates
will get turned into signature packets which other implementations can
ignore without difficulty.  This is done most directly by giving it an
unused public key algorithm, so that no implementations will attempt
to verify the signature.  I used zero, but we could use 100 if that
would help.  Implementations need to be able to handle unrecognized
public key algorithms, even those which are not defined in the current
OpenPGP standard.

I can make changes for version 6.5.1 which will come out in a few weeks
(bug fix version) to address problems which are tripping up current
implementations.

Hal Finney
Network Associates, Inc.

From: "William H. Geiger III" <[email-masked]>
Date: Mon, 17 May 1999 22:35:22 -0400
To: Tom Zerucha <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: MDCs and PGP 6.5.1b15
Sender: [email-masked]

In <[email-masked]>, on 05/17/99 
   at 07:19 PM, Tom Zerucha <[email-masked]> said:

>I don't know about this particular signature packet or extension, but I
>would hope you aren't violating any part of the existing spec with this
>addition.

I had done a detailed analysis of this key for the PGP-Keyserver Operators
group this weekend (I can post here if desired). IMHO the signature looks
foobared and violates several aspects of RFC 2440. I don't mind creating a
method to convert X.509 stuff to OpenPGP, I don't even mind the X.509
certs being encapsulated in a hashed subpacket. But if we are going to do
all this the end result should be a valid OpenPGP Key that contains the
following 3 elements:

Valid OpenPGP Public Key Packet
Valid OpenPGP UserID Packet
Valid OpenPGP SelfSignature

I don't think that the X.509 packet alone should qualify as a valid
SelfSignature but instead during the conversion process a OpenPGP
SelfSignature should be generated. Of course this would require that a
corresponding OpenPGP secret key be generated during the conversion
process. Otherwise I really don't see the point of going through the
conversion process at all.

-- 
---------------------------------------------------------------
William H. Geiger III  http://www.openpgp.net
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 5.0 at: http://www.openpgp.net/pgp.html
Talk About PGP on IRC EFNet Channel: #pgp Nick: whgiii

Hi Jeff!! :)
---------------------------------------------------------------

Date: Mon, 17 May 1999 20:19:03 -0400
From: Tom Zerucha <[email-masked]>
To: [email-masked]
cc: [email-masked], [email-masked]
Subject: Re: MDCs and PGP 6.5.1b15
Sender: [email-masked]

On Mon, 17 May 1999 [email-masked] wrote:

> MDCs are a different cryptographic entity and they should go into
> different packets.

As an aside, the first does not imply the second.  The spec does not state
that packets map to cryptographic entities (though it ends up this way for
the most part).  And I think the 1-pass signature prefix packet uses a
different packet type number although it is functionally part of the
trailing signature.

Then again, the new encryption scheme is the same type of cryptographic
entity so then should use the same packet as the existing encryption.

> MDCs only work in the context of an encryption envelope and so they
> should be associated with an encryption context.

True, but the question is where or how the association happens.  Do we put
a post-it on the document or on the inside of the envelope, or use glue
or write directly on the document.

> I will post information shortly with the formats of this PRIVATE signature
> subpacket, which does hold an X.509 certificate.  The picture above is
> inaccurate in one respect; it does not have a keyid of 0, rather there
> is no keyid subpacket.  X.509 certs use a different method to link
> issuing keys to signatures, and a keyid cannot meaningfully be used in
> this context.

A PGP key ID is derivable from an X.509 cert.  If you use openssl to fill
a key structure with the appropriate information and pass that to one of
my routines it will derive the corresponding ID as if the X.509 key
material was a PGP key. (goodies/x509topk.c)

> > If this has really been created by PGP, why didn't tell NAI us about
> > it?  
> 
> It uses a private subpacket.  That's what the private subpacket is for,
> so that vendors can extend the standard for their own uses.

Does it violate other rules about the signature packet?  The spec does not
allow for a signature without one (RSA) or two (DSA or even ElGamal) MPI
integers (unless you are using a private, experimental PK algorithm), plus
you need the all the hash stuff in their places.

Stuff all the private packets you want there, but the rest of the rules
about what MUST be there and the valid ID numbers still apply (0 is not
valid for a private, experimental PK algorithm).

I don't know about this particular signature packet or extension, but I
would hope you aren't violating any part of the existing spec with this
addition.

Date: Mon, 17 May 1999 19:41:53 -0400
From: Tom Zerucha <[email-masked]>
To: Werner Koch <[email-masked]>
cc: [email-masked]
Subject: Re: MDCs and PGP 6.5.1b15
Sender: [email-masked]

On Mon, 17 May 1999, Werner Koch wrote:

[key stuff deleted]

It may be a rogue version - and although I never sent any such keys to any
PGP server, I did experiment with using the X509 output capabilities of
openssl (so you could use a PGP key in an X509 routine, and vice versa).

> Tom, what about changing your MDC to use a unhashed subpacket for the
> MDC instead of an MPI?  I think this will be a much nicer solution and
> I wonder why we didn't came up with this earlier.

That would also work - I would have to put in the logic earlier, but then
the signature test logic wouldn't have the zero algorithm there.

We just need an unhashed packet ID

Date: Mon, 17 May 1999 09:36:24 -0700
From: [email-masked]
To: [email-masked], [email-masked]
Subject: Re: MDCs and PGP 6.5.1b15
Sender: [email-masked]

> I think I found a reason why NAI argues against MDCs in signature
> packets.

No, that has nothing to do with why we feel that MDCs should be
associated with encryption packets.  MDCs are not signatures and are not
syntactically replaceable with signatures.  They do not have the same
semantics as signatures and should not be put into signature packets.
Digital signatures are a well defined cryptographic concept and we have a
packet for that purpose.  MDCs are a different cryptographic entity and
they should go into different packets.  MDCs only work in the context
of an encryption envelope and so they should be associated with an
encryption context.

> There is a key which caused some key servers to crash and
> it seems that this one has been created by a new PGP version.  The
> key looks like this:
>
> :public key packet:
>         version 3, algo 1, created 838857600, expires 0
>         pkey[0]: [1024 bits]
>         pkey[1]: [17 bits]
> :user id packet: "Thawte Server CA <[email-masked]>"
> :signature packet: algo 0, keyid 0000000000000000
>         version 4, created 0, md5len 0, sigclass 10
>         digest algo 1, begin of digest 00 00
>         hashed subpkt 2 len 5 (sig created 1996-08-01)
>         hashed subpkt 3 len 5 (sig expires after 24y158d23h59m)
>         hashed subpkt 5 len 3 (trust signature)
>         hashed subpkt 100 len 795 (?)
>         unknown algorithm 0

I will post information shortly with the formats of this PRIVATE signature
subpacket, which does hold an X.509 certificate.  The picture above is
inaccurate in one respect; it does not have a keyid of 0, rather there
is no keyid subpacket.  X.509 certs use a different method to link
issuing keys to signatures, and a keyid cannot meaningfully be used in
this context.

> So we have all the stuff Tom proposed for MDCs in signature packets:
> keyid of zero and a public key algorithm identifier of zero.  The
> private subpacket with id 100 maybe a X509 certificate - I have not
> analyzed it.

It differs from Tom's proposal in several ways, not least because the
signature class of 0x10 indicates that it is a key certificate signature
and not a message signature as the MDC would presumably be.  We use a
PK alg of zero because the certificate validation has to be done using
special X.509 rules.

> If this has really been created by PGP, why didn't tell NAI us about
> it?  

It uses a private subpacket.  That's what the private subpacket is for,
so that vendors can extend the standard for their own uses.

> Tom, what about changing your MDC to use a unhashed subpacket for the
> MDC instead of an MPI?  I think this will be a much nicer solution and
> I wonder why we didn't came up with this earlier.

This would not address the other problems with using a signature packet
for this purpose.

Hal Finney
Network Associates, Inc.

Date: Mon, 17 May 1999 15:12:16 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: MDCs and PGP 6.5.1b15
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Hi,

I think I found a reason why NAI argues against MDCs in signature
packets.  There is a key which caused some key servers to crash and
it seems that this one has been created by a new PGP version.  The
key looks like this:

:public key packet:
        version 3, algo 1, created 838857600, expires 0
        pkey[0]: [1024 bits]
        pkey[1]: [17 bits]
:user id packet: "Thawte Server CA <[email-masked]>"
:signature packet: algo 0, keyid 0000000000000000
        version 4, created 0, md5len 0, sigclass 10
        digest algo 1, begin of digest 00 00
        hashed subpkt 2 len 5 (sig created 1996-08-01)
        hashed subpkt 3 len 5 (sig expires after 24y158d23h59m)
        hashed subpkt 5 len 3 (trust signature)
        hashed subpkt 100 len 795 (?)
        unknown algorithm 0
  
So we have all the stuff Tom proposed for MDCs in signature packets:
keyid of zero and a public key algorithm identifier of zero.  The
private subpacket with id 100 maybe a X509 certificate - I have not
analyzed it.

If this has really been created by PGP, why didn't tell NAI us about
it?  

Tom, what about changing your MDC to use a unhashed subpacket for the
MDC instead of an MPI?  I think this will be a much nicer solution and
I wonder why we didn't came up with this earlier.

Date: Mon, 17 May 1999 09:32:24 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: Agree with PRZs MDC suggestion
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Tom Zerucha <[email-masked]> writes:

> Does GPG have any plans on allowing MDCs with the other algorithms?  Other
> hash algorithms besides SHA1?

I'd like to allow RIPE-MD160 if somewone wants to do this.  There is
already the option to use DSA with RIPE.  And we have these
identifiers all over the place.

> But I don't have any objections to a new MDC-only packet, especially if it
> has a "MDC follows" prefix packet.

The one-pass signature packet can be used for this.

Date: Fri, 14 May 1999 10:05:30 -0400
From: Tom Zerucha <[email-masked]>
To: [email-masked]
cc: [email-masked], [email-masked]
Subject: Re: Agree with PRZs MDC suggestion
Sender: [email-masked]

yOn Thu, 13 May 1999 [email-masked] wrote:

> > > encryptwithmdc( <plaintext packet>, <mdc packet> )
> 
> (Note that what I showed here as "<plaintext packet>" could actually
> be multiple packets long.  It would be better described as an "<OpenPGP
> Message>" in the syntax of section 10.2 of RFC2440.)
> 
> If we did go with something like this, how would we handle the hashing
> of the packet headers on the mdc packet?  They should probably be hashed
> too, don't you think?
> 
> The simplest case from my point of view would be that we hash all the
> encrypted material except for the last 20 bytes (assuming we settle on
> a SHA-1 hash).

You probably would have the entire MDC packet in the buffer, so you could
use the prefix MDC as a sort of initial text to the hash function.

And also hash the beginning of the MDC value packet.  It would end up with
the final 20 bytes at the end, so it should work almost transparently.

One note, that it could mean hashing the packet content at this level
including the CTB bytes.  I would rather not hash the CTB, or hash a
"normalized" CTB sort of the way keys are prefixed with 99 hh ll for their
signature hash.

From: [email-masked]
Date: Thu, 13 May 1999 18:54:56 -0700
To: [email-masked], [email-masked]
Subject: Re: Agree with PRZs MDC suggestion
Cc: [email-masked], [email-masked]
Sender: [email-masked]

> > encryptwithmdc( <plaintext packet>, <mdc packet> )

(Note that what I showed here as "<plaintext packet>" could actually
be multiple packets long.  It would be better described as an "<OpenPGP
Message>" in the syntax of section 10.2 of RFC2440.)

If we did go with something like this, how would we handle the hashing
of the packet headers on the mdc packet?  They should probably be hashed
too, don't you think?

The simplest case from my point of view would be that we hash all the
encrypted material except for the last 20 bytes (assuming we settle on
a SHA-1 hash).

Hal

From: [email-masked]
Date: Thu, 13 May 1999 18:47:23 -0700
To: [email-masked], [email-masked]
Subject: Re: Versions and hashing
Sender: [email-masked]

Tom Zerucha, <[email-masked]>, writes:
> > >    1 byte version  (should be 1)
>
> Actually 5 would be more consistent.  Elsewhere 3 is used for PGP 2.6
> level packets, 4 for PGP 5-6.  Anything below 5 for this new packet would
> be an error.

Maybe, although with a new packet type it is questionable whether you
have to start that high.  It's not like there are any V1-V4 packets of
this type out there.  But for consistency maybe V5 is best.

> > >    1 byte MDC method (should be 2 to match SHA, or 0 to disable MDC)
> > 
> > This one worries me.  It allows an attacker to turn a 2 into a 0.  Also,
> > is there an implication that it can be something other than 2 or 0?  Like,
> > 1 means MD5?  If so, this again offers an attacker more opportunities to
> > mess with the receiver.  The attacker could change the hash algorithm to
> > something like 6.  Now the receiver doesn't know if this is a legitimate
> > message from a later version of PGP that supports hash algorithm 6, or
> > whether it is a messed up message by an attacker.  If we choose a fixed
> > hash algorithm this ambiguity cannot arise.
>
> The receiver would have to check the message on a later version of PGP.
> If 6 was a legitimage algorithm ID the hash would work.  The same problem
> arises if something shifts between any two valid IDs with the same length 
> hash, the second of which would might not be supported.

The point is that if no such new version of PGP is available, the
integrity protection is lost.  I think we can make a design where
integrity protection can't be stripped away.  Shouldn't we do so?

> One note is that if you use my idea of an MDC-ahead prefix packet, and
> MDC-result packet bracketing the plaintext, the MDC specification is
> encrypted too, making this attack difficult.

But still possible - you can make tweaks to encrypted data as I described
earlier.

> (CTB,len=2) 5 2; plaintext; (CTB, len=22) 5 2 <20 byte result>;
>
> Note that this would allow multiple MDCs with different algorithms
> (the hash would only be on the plaintext), so you could have
>
> [MDC: rmd160 follows][MDC: SHA1 follows][plaintext][MDC: SHA1 result][MDC:
> rmd result].
>
> Or these could be merged, (CTB len = 4) 5 2 3 0;/ (CTB len = 44) 5 2 <20
> byte sha1> 3 <20 byte rmd> 0; or something similar.

There is no point in having multiple MDC's with different algorithms.
There is not even any point in supporting more than one algorithm.
The attacker, when he makes his changes, either truncates the message
or can't help unpredictably corrupting a block of the message.  A simple
SHA hash will detect either of these changes with overwhelming security.

> While we are on the subject, last year at this time there was a suggestion
> to drop El Gamal. The objection was mainly that the only other two
> alternatives had other problems - RSA was patented, and DSA limited the
> hash length to 160 bits, so although you could do larger keys, they added
> no security since the hash was the weakest link.  ElGamal allowed for
> longer hashes and (if there were no flaws in the implementation) more
> functional bits in the public key.
>
> Various suggestions were made including a doublewide DSA or something
> similar including coming up with a hash system.
>
> Has anyone followed up on this?

We have spoken to NIST about this, and they say that they are acutely
aware of the need to standardize on a larger hash algorithm, and that
they are working very activelly on it.  However they have not given us
a fixed date for when they will have a result.

Hal Finney

Date: Thu, 13 May 1999 12:50:03 -0400
From: Tom Zerucha <[email-masked]>
To: [email-masked]
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Agree with PRZs MDC suggestion
Sender: [email-masked]

On Wed, 12 May 1999 [email-masked] wrote:

> > I am not arguing against an MDC packet, though I don't see as much problem
> > with the extra field bytes in the existing signature/validation packet.
> > They don't have to be in the existing signature packet (though I would
> > want things like version and algorithm bytes and length processing to make
> > them orthogonal with every other packet type).  I am arguing against a
> > required trailing naked MDC field unique to a new encryption packet.
> >
> > To clarify, it would be encrypt( literal(data), MDC ), MDC being the new
> > packet containing the hash of the literal.  And encrypt( "mdc follows",
> > literal(data), MDC) would be even better.
> 
> How about if the "encrypt" is a different packet number, something like
> "encryptwithmdc".  Then this would be:
> 
> encryptwithmdc( <plaintext packet>, <mdc packet> )

That too would work, but if you want to give (one or more) hash algorithm
IDs, or versions (we might want to change something with the MDC for 3.0),
that would have to go into the Ew/MDC header and be subject to the attack
you pointed out.  It can be an Ew/MDC function, but all MDC info will need
to go into the encrypted area.  (And if encrypted, you could have an MDC
header specifying "no algorithms" for those who want to use just the new 
algorithms but without MDC).

If these could be resolved, I would say the whole Ew/MDC stuff is a
SHOULD, but if so SHA1 is a MUST, rmd160 a SHOULD, none or others a MAY,
for the hash stuff.  I suspect TwoFish to be the MUST, the existing
SHOULD/MUST algorithms as SHOULDs here.

(assuming we aren't locked to SHA1 by having an MDC prefix packet in the
encrypted stream - note that if this header were checksummed you might not
need any other quick-check bytes).

> We would still need to decide whether to change to a more conventional
> IV handling, and if so how to handle check bytes.  I will tell you
> frankly that Phil likes the pseudo-IV; he invented it.  I have been
> the main one pushing for a more conventional handling of the IV,
> because I don't believe the pseudo IV offers any security advantage.
> It's unusual but has no security advantages.  This is generally not a
> good thing in cryptography.  So I'd like to make it more conventional.
> 
> Uri suggested that a conventional IV is less desirable from a security
> point of view, but I'd like to hear more about the reasons.
> 
> This is not the highest priority item for me so if everyone else likes
> the pseudo IV I can accept it.  But I would prefer to know a good reason
> for doing it that way.

I can go either way here.  I either pass the data directly to the
algorithm, or through my pseudoIV handler.  However I suspect it might be
nicer (especially if hardware implmentations of crypto become common) to
do things in the more conventional way.

> > Does GPG have any plans on allowing MDCs with the other algorithms?  Other
> > hash algorithms besides SHA1?
> 
> I would suggest that we should allow it with other algorithms in the spec.
> However initially implementations should accept it but not create it
> except for Twofish.
> 
> As for other hash algs, I have described how this could potentially open
> up a security hole (by letting an attacker tweak the hash-alg field).

Not if the field is encrypted.

Date: Wed, 12 May 1999 17:20:54 -0400
From: Tom Zerucha <[email-masked]>
To: [email-masked]
Subject: Versions and hashing
Sender: [email-masked]

On Tue, 11 May 1999 [email-masked] wrote:

> In my other message I pointed out the problem that an attacker could
> perturb some of these header values.  With that in mind let us look at
> these fields:
> 
> >    1 byte version  (should be 1)
> 
> This is probably a good idea.  If perturbed by an attacker to a later
> version, the software will refuse to process the packet.  We need

Actually 5 would be more consistent.  Elsewhere 3 is used for PGP 2.6
level packets, 4 for PGP 5-6.  Anything below 5 for this new packet would
be an error.

> >    1 byte MDC method (should be 2 to match SHA, or 0 to disable MDC)
> 
> This one worries me.  It allows an attacker to turn a 2 into a 0.  Also,
> is there an implication that it can be something other than 2 or 0?  Like,
> 1 means MD5?  If so, this again offers an attacker more opportunities to
> mess with the receiver.  The attacker could change the hash algorithm to
> something like 6.  Now the receiver doesn't know if this is a legitimate
> message from a later version of PGP that supports hash algorithm 6, or
> whether it is a messed up message by an attacker.  If we choose a fixed
> hash algorithm this ambiguity cannot arise.

The receiver would have to check the message on a later version of PGP.
If 6 was a legitimage algorithm ID the hash would work.  The same problem
arises if something shifts between any two valid IDs with the same length 
hash, the second of which would might not be supported.

One note is that if you use my idea of an MDC-ahead prefix packet, and
MDC-result packet bracketing the plaintext, the MDC specification is
encrypted too, making this attack difficult.

(CTB,len=2) 5 2; plaintext; (CTB, len=22) 5 2 <20 byte result>;

Note that this would allow multiple MDCs with different algorithms
(the hash would only be on the plaintext), so you could have

[MDC: rmd160 follows][MDC: SHA1 follows][plaintext][MDC: SHA1 result][MDC:
rmd result].

Or these could be merged, (CTB len = 4) 5 2 3 0;/ (CTB len = 44) 5 2 <20
byte sha1> 3 <20 byte rmd> 0; or something similar.

-----------------------

While we are on the subject, last year at this time there was a suggestion
to drop El Gamal. The objection was mainly that the only other two
alternatives had other problems - RSA was patented, and DSA limited the
hash length to 160 bits, so although you could do larger keys, they added
no security since the hash was the weakest link.  ElGamal allowed for
longer hashes and (if there were no flaws in the implementation) more
functional bits in the public key.

Various suggestions were made including a doublewide DSA or something
similar including coming up with a hash system.

Has anyone followed up on this?

Date: Wed, 12 May 1999 13:21:06 -0700
From: [email-masked]
To: [email-masked], [email-masked]
Subject: Re: Agree with PRZs MDC suggestion
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Tom Zerucha, <[email-masked]>, writes:
> And I am not saying it must be the signature packet or nothing.  My
> problem is with the 20 unencapsulated or unindicated hash bytes at the
> end.  Encapsulating them addresses all my major complaints.  But that
> would mean another new packet type or subtype.

OK, maybe we could do something along these lines.

> Is he also completely and irrevocably opposed to having the hash as
> anything except a naked 20 byte field at the end of the plaintext stream?

I recall that Phil and I did briefly discuss the idea of putting the
hash into a separate, following packet, and while he didn't like it as
much as integrating it, I don't think he objected to it.

> I am not arguing against an MDC packet, though I don't see as much problem
> with the extra field bytes in the existing signature/validation packet.
> They don't have to be in the existing signature packet (though I would
> want things like version and algorithm bytes and length processing to make
> them orthogonal with every other packet type).  I am arguing against a
> required trailing naked MDC field unique to a new encryption packet.
>
> To clarify, it would be encrypt( literal(data), MDC ), MDC being the new
> packet containing the hash of the literal.  And encrypt( "mdc follows",
> literal(data), MDC) would be even better.

How about if the "encrypt" is a different packet number, something like
"encryptwithmdc".  Then this would be:

encryptwithmdc( <plaintext packet>, <mdc packet> )

We would still need to decide whether to change to a more conventional
IV handling, and if so how to handle check bytes.  I will tell you
frankly that Phil likes the pseudo-IV; he invented it.  I have been
the main one pushing for a more conventional handling of the IV,
because I don't believe the pseudo IV offers any security advantage.
It's unusual but has no security advantages.  This is generally not a
good thing in cryptography.  So I'd like to make it more conventional.

Uri suggested that a conventional IV is less desirable from a security
point of view, but I'd like to hear more about the reasons.

This is not the highest priority item for me so if everyone else likes
the pseudo IV I can accept it.  But I would prefer to know a good reason
for doing it that way.

> What about Geiger's OS/2 (mainly) implementation?

I'm not familiar with this one.  Is there really such a thing?

> Does GPG have any plans on allowing MDCs with the other algorithms?  Other
> hash algorithms besides SHA1?

I would suggest that we should allow it with other algorithms in the spec.
However initially implementations should accept it but not create it
except for Twofish.

As for other hash algs, I have described how this could potentially open
up a security hole (by letting an attacker tweak the hash-alg field).
I believe we should stick with SHA-1.  There is actually no need for a
cryptographically collision-resistant hash here, and in practice probably
something like a CRC would work.  SHA-1 is overkill and even if it is
someday broken it will almost certainly still be more than adequate for
this purpose.

> To restate my position, the MDC should be encapsulated in some kind of
> packet consistent with the existing syntax and grammar.  My preference is
> for expanding the existing signature packet by adding a "zero" algorithm.
>
> But I don't have any objections to a new MDC-only packet, especially if it
> has a "MDC follows" prefix packet.
>
> All I don't want is an unencapsulated fixed number of bytes implicitly at
> the end of a packet.

I could go with this, along the lines Tom mentioned above, particularly
with the modification I suggested.  How does this sound to others?

Hal

Date: Wed, 12 May 1999 15:27:42 -0400
From: Tom Zerucha <[email-masked]>
To: [email-masked]
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Agree with PRZs MDC suggestion
Sender: [email-masked]

yOn Tue, 11 May 1999 [email-masked] wrote:

> These statements are only valid in the context of your implementation.
> I have implemented it in a different way which did not require adding any
> new layers.  I simply added calls to the hash function in the decryption
> module, as well as the 20 byte holdback buffer.  As it happened I
> already had a buffer in the decryption module so modifying it to hold
> back 20 bytes was easy.  There were then two extra functions added to
> the decryption module, one to finalize and retrieve the hash value,
> and one to retrieve the value from the holdback buffer (which holds the
> final 20 bytes at the end of processing).  These are then compared at
> the end of the packet.  It was not a difficult change.

I would still call this a layer, even if it is inline.

> Which is the most architecturally attractive way to do it?  Which method
> is the most logical and coherent?  Which method would you use if you
> were designing from scratch, rather than trying to shoehorn it into an
> existing implementation so as to change it as little as possible?

Architecture attractive means different things when adding on to a
building v.s. building a completely new building.

It is not more logical or coherent to not use an existing layer that
already does hashing and returns those hash bytes (with about a dozen
extra bytes hashed).

If you are asking which method should be used if redesigning EVERYTHING
from scratch, I would give a different answer, but then why bother calling
it or otherwise associating it with OpenPGP.  I could list about a half
dozen other things that should be done differently.  Will you be open to
those suggestions as long as the standard for OpenPGP 2.0 will be a clean
sheet of paper?

And I am not saying it must be the signature packet or nothing.  My
problem is with the 20 unencapsulated or unindicated hash bytes at the
end.  Encapsulating them addresses all my major complaints.  But that
would mean another new packet type or subtype.

> > Altering one byte to add a definition to the signature packet is less of
> > a hack than holding back 20 bytes.  Don't assume everyone is running on
> > big machines with an OS or API calls to handle this and CPU cycles to
> > spare.
> 
> Holding back 20 bytes does not take a big machine, or any OS or API calls.
> It is a simple circular buffer and about half a page of code.

Neither does it take much to reserve 20 bytes at the beginning.  I would
rather burden the single encryption operation than the many decryption
operations.  You then don't need any of this extra stuff in the decryption
layer to find the EOF.  And most things work better on block boundaries.

Nor does it take anything more to put a CTB terminal packet at both the
end of the encryption stream and do a 20 byte packet for the hash (oh,
maybe in YOUR implementation it would be hard).  And at least a byte for
the algorithm number even if it is fixed simply to be consistent.

> Let's not go down the path of putting bytes outside a packet.  That would
> violate all of our conventions.

An implicit convention that has been true UNTIL NOW is that no unknown
variable length data element is FOLLOWED by a fixed length data element,
perhaps except if you do a signed compression packet with an old style
CTB, but you do get the end-of-packet indication at the end of the
compression stream (i.e. the compressor does know where the compressed
data ends).

Another implicit convention is that everywhere things like algorithms are
used, there is no implicit value, but an identifier.  Maybe we only want
to use SHA1, but it would follow the tradition if the 20 bytes were
prefixed by a version number and the algorithm identifier.

Defining two new packet types, new encryption format and new MDC only
valid if it follows and is encrypted by the above isn't that much harder.

> > I have pointed out that we can do it without bloating the code.  But it
> > seems everyone wants to bloat it.  Assuming PRZ isn't doing another
> > "hit-and-run", what does HE think of the alternatives?
> 
> Phil is out of the country now, but I have spoken at great length to him
> about this over the past month.  I assure you that Phil is THE strongest
> supporter of integrating the MDC feature with a new encryption packet.
> I cannot over emphasize how strongly he opposes doing it as a hack of
> the signature packet.

I take it he is in a country without Email?  I don't care how
strongly one favors or opposes something if it is not on technical
grounds.  And he has been capable of speaking for himself in the past.

Is he also completely and irrevocably opposed to having the hash as
anything except a naked 20 byte field at the end of the plaintext stream?

> I showed earlier how inappropriate the signature packet is for this
> purpose.  I listed all the fields and showed how few of them made any
> sense in this context.  I can understand that this is the path of least
> resistance for kludging this feature into existing code, but we would
> prefer an approach which makes sense architecturally.  Signature packets
> are not appropriate for this purpose.

I will repeat that I am only calling it signature packet because that is
the title of the packet I want to use and would move to change it to
"validity packet" or "verification packet" in the spec.  Because it has
been given one specific name doesn't restrict it from both the function
and name being generalized.

Many of the fields make no sense in other contexts as well.  But having
implemented it this is what we have inside:
4 - the version (which is needed)
X - the signature type (not needed)
A - sig algorithm, 0 for MDCs
a - hash algorithm, SHA1 (needed unless we never want anything else)
four zero bytes (length of hashed and unhashed packets)

Also 0x04 0xff and 4 length bytes are hashed.  It is either redundant in
the signature packet or useful, and that would extend to here.

I haven't checked the packet types to see if there is any potentially
useful information that someone might want to add (e.g. a timestamp or
comment for a file that wouldn't be part of the image if it were something
like an executable).

Then there are the two redundant bytes for the hash that still provide a
quick check, which is less useful if you dont' have to do a signature
calculation.  And the hash value, but encoded in an MPI, so the MPI
length word would be redundant.

All this v.s. having a special case for the new encryption type that also
does the MDC - the special casing won't work or apply to existing
encryption algorithms, and the hashing that is already there won't apply
(or have to be done while generating a signature as well).

And, if you do create a signed message (where having a signature is
significant, for example a timestamp), why wouldn't the entire MDC
infrastructure be redundant? You are validating the decryption and then
revalidating it again when checking the signature.  Shouldn't it be turned
off to avoid having this function that doesn't make sense in this context?

What added integrity does the MDC give to a signed message (and since we
are talking about elimination redundancy and extra fields, I am assuming
the key is available, etc.)?  Why is the MDC not redundant since that is
the reason you are giving for not having it encapsulated in the existing
validation structure.  I think there are fewer total redundant bytes.

And I have asked about existing algorithms.  Whatever extra security an
MDC would provide for TwoFish should also apply to 3DES, IDEA, and CAST.
Is there a reason for NOT doing MDCs with the existing algorithms?  It
might be useful to have an implementation that implements only the MUST
algorithms except to have the extra MDC function (insert all the reasons
we need an MDC and not merely an "anybody" signature key here). How does
your method address this?

Even having an MDC "packet" (those horrid extra header bytes and the
restart of the CTB packet length engine) appended to the plaintext packet
instead of being part of it would allow for this.

I am not arguing against an MDC packet, though I don't see as much problem
with the extra field bytes in the existing signature/validation packet.
They don't have to be in the existing signature packet (though I would
want things like version and algorithm bytes and length processing to make
them orthogonal with every other packet type).  I am arguing against a
required trailing naked MDC field unique to a new encryption packet.

To clarify, it would be encrypt( literal(data), MDC ), MDC being the new
packet containing the hash of the literal.  And encrypt( "mdc follows",
literal(data), MDC) would be even better.

Note this would also have use as a simple checksum - only detecting if the
file was corrupted in transmission for simple non-crypto type validation.

> > Conversely, extending the existing structure is easy enough to warrant
> > being a SHOULD.
> 
> As far as I know, there are three implementations that are affected:
> your reference implementation, the Gnu Privacy Guard, and the commercial
> PGP from Network Associates.  If we can come to agreement then we can get
> these changes into all of these implementations, and make it a SHOULD as
> Werner suggested.

What about Geiger's OS/2 (mainly) implementation?

Does GPG have any plans on allowing MDCs with the other algorithms?  Other
hash algorithms besides SHA1?

To restate my position, the MDC should be encapsulated in some kind of
packet consistent with the existing syntax and grammar.  My preference is
for expanding the existing signature packet by adding a "zero" algorithm.

But I don't have any objections to a new MDC-only packet, especially if it
has a "MDC follows" prefix packet.

All I don't want is an unencapsulated fixed number of bytes implicitly at
the end of a packet.

From: uri <[email-masked]>
Subject: Re: Agree with PRZs MDC suggestion
To: [email-masked]
Date: Wed, 12 May 1999 07:23:19 -0400 (EDT)
Cc: [email-masked], [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

[email-masked] says:
> >    1 byte MDC method (should be 2 to match SHA, or 0 to disable MDC)
> 
> This one worries me.  It allows an attacker to turn a 2 into a 0. 

I would not have "disable MDC" at all.

> Also,
> is there an implication that it can be something other than 2 or 0?

Absolutely - like 3 for HAVAL, 5 for <whatever>...

> If so, this again offers an attacker more opportunities to
> mess with the receiver.  The attacker could change the hash algorithm to
> something like 6.  Now the receiver doesn't know if this is a legitimate
> message from a later version of PGP that supports hash algorithm 6, or
> whether it is a messed up message by an attacker.  If we choose a fixed
> hash algorithm this ambiguity cannot arise.

True. So it is up to the group to decide if the extra flexibility of
permitting several hash-functions is worth this potential attack...

> I would prefer to leave this field out.  If you use the new packet format
> at all, you get the MDC, using a fixed hash of SHA-1.

Quite acceptable, if you ask me.

> >    n byte random data used as IV (n=blocksize of the cipher)	
> 
> OK.  I continue to believe that a *conventional* IV is most desirable in
> terms of explaining what we are doing to others in the field.  The "pseudo
> IV" we have now is hard to explain.

1. A conventional IV is less desirable from security point of view.
2. If you have trouble explaining this approach to others in the
   field - I suggest that those others are in the wrong field.
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

Date: Wed, 12 May 1999 09:59:48 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: Agree with PRZs MDC suggestion
Mail-Followup-To: [email-masked]
Sender: [email-masked]

[email-masked] writes:

> >    1 byte version  (should be 1)
> 
> This is probably a good idea.  If perturbed by an attacker to a later

Yes and the reason for this is simply to extend the range of possible
packet formats (view it as a packet subtype).

> attacker could execute a rollback attack by changing a V2 to a V1.
> We can deal with that at that time by making sure that V2 and V1 look

And he could also do this by changing the packet type.

> >    1 byte MDC method (should be 2 to match SHA, or 0 to disable MDC)
> 
> This one worries me.  It allows an attacker to turn a 2 into a 0.  Also,

I see your point.  The reason I suggest this is that there are a lot
of people who prefer to use RIPE-MD160 and this way we have te
opportunity to do just this.  The packet format may also be used for
some very small applications which use a subset of OpenPGP and don't
implement SHA1 at all.  My solution to this is to say in the standard,
that this SHOULD be SHA1 and an implementation SHOULD fail if this 
condition is not met. 

> whether it is a messed up message by an attacker.  If we choose a fixed
> hash algorithm this ambiguity cannot arise.

I guess we will have new hash algorithms with a larger digest size in the
near future and this way we can more easily extend the specs to make
it possible to use this hash (Frankly, don't see any need in a MDC for 
a larger hash, but if some one wants and has only implemented this
larger hash ...).

> >    1 byte number of extra bytes (m) at the end of the encrypted text
> >           From now on CFB encrypted with an IV of all zeroes without
> >           any strange syncing.

This is fine for automatic parsing of messages to let the parse know
how may bytes he has to hold back. 

> terms of explaining what we are doing to others in the field.  The "pseudo
> IV" we have now is hard to explain.  I had to go to some lengths in
> getting our FIPS 140 certification (a standard security certification)

I can't remember that the Internet Standards Process (BCP9) or our
chapter says anything about FIPS certification.  PGPG is a widely
deployed quasi-standard and believed to be really good secure.

If you need some certification it is matter of your company to work 
it out.

> >    2 byte the last two bytes of the random data.
> 
> You have not shown whether these are encrypted.  I presume that they are,

Ah sure.  It is what we are currently using.

> My proposal was that we have four bytes, two random ones and then those
> same two random ones repeated.  These would all be encrypted.  It's not

But that will be not better than the current practice.  It is okay for
PK encryption but when using a symmetric-only encryption it may not
detect wrong passphrases in all cases.  But okay, we catch this with
the MDC and therefore I think it is good enough.

>    Make the "pseudo-IV" prefix partially non-random - i.e. the last two 
>    bytes being checksum for the other 14. No big deal security-wise and
>    noticeable help in detecting the right key.
> 
> This isn't too bad for 128 bit block ciphers like Twofish or AES, but as
> a general principle we would need to apply it to all ciphers, including
> 64 bit block ciphers.  I don't like taking away 16 of the 64 bits of IV

So we could always use 128 bits and use only the lower half for 64 bit
blocksize ciphers.  But okay, with the MDC we don't really need it.

> I agree that it would be sensible to encourage the new format when we go
> to new block ciphers.  Unfortunately the next version of PGP will have
> Twofish support without MDC, since we were not able to come to consensus

Ahhh great:  I'm holding back Twofish support for GnuPG for many weeks
now, only to have the chance to use 128 bit block ciphers as a
criteria to decide whether to use MDCed encryption - but NAI has already
decided to make facts and thereby ignoring the discussion at the WG.
But sure, it is your companies decision - tssss.

BTW, how did you solve the ambiguities in the rfc regarding the use of
synced CFB and length of IVs? 

> By this, do you mean the special sync operation after reading the pseudo
> IV and check bytes?

Yes.
#define CIPHER_MODE_PHILS_CFB 3

Date: Wed, 12 May 1999 10:14:11 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: Agree with PRZs MDC suggestion
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Tom Zerucha <[email-masked]> writes:

> >    Encrypted_Data -+- Data_Containter_Packet -+- Onepass
> >                    !                          !- Plaintext	
> >                    !                          !- Signature  		
> >                    !- MDC_Packet
> 
> Not true.  Just as you run the encryptor and get two or more packets out

Partly true, for my implementaion such a scheme would make for
sense ;-) 

> No one has yet told me why this is any less secure, slower, or harder than
> tacking the 20 bytes onto the end of the plaintext.
> 
> How many lines of code did each method take?  How many cpu-seconds?

You know that I implemented this in GnuPG (it is in 0.9.6, use
--force-mdc).  But the way I implemented it was more a hack.  Using a
different packet than the signature packet would have made more sense
as it will lead to a cleaner implementation.

I dropped this to check my proposol and Phil's and it turned out that
Phil's was the easiest to implement.  Holding back the 20 bytes is
really easy if you are already doing some buffering and it can be
coded in a way to minimize any performance penalty (which is anyway in
the MDC calculation).

> a hack than holding back 20 bytes.  Don't assume everyone is running on
> big machines with an OS or API calls to handle this and CPU cycles to

Not CPU cycles but larger buffers are needed.

> It may be easy to add in your implementation, and you may not be trying to
> do stream I/O and have something that handles errant packet boundaries

GnuPG handles everything has stream (with the strange partial header
scheme of PGP 5 which claims to save some bytes :-)

> of adding algorithms).  Holding back 20 bytes when I am already against
> the memory limitations is going to be very painful.

As Hal already said, the extra memory needed for the hashing context
outweights some 20 bytes.

> I have pointed out that we can do it without bloating the code.  But it

Actually the signature packet hack bloated my code (although a
different type of packet won't do so).

> If this is going to require another layer, then all such algorithms using
> this new method should be given a MAY level of compliance and not SHOULD

I only wanted to get a faster consensus, therefore I suggested SHOUlD
- but it has now turned out that NAI is doing anyway there own way, we
can use MAY and an implementor can decide whether to print a warning
or now.

[Really fine that we have a holiday tomorrow :-), back on Monday]

Date: Tue, 11 May 1999 17:10:08 -0700
From: [email-masked]
To: [email-masked], [email-masked]
Subject: Re: Agree with PRZs MDC suggestion
Cc: [email-masked]
Sender: [email-masked]

 Tom Zerucha, <[email-masked]>, writes:

> In effect what we have now (with buffering or pipes between threads) is:
>
> ciphertext | dearmor | pkdecrypt | symdecrypt | sigver | deliteral
>
> There may be multiple sigvers, one per level of nesting (I use a stack
> instead of spawning another layer).
>
> What will happen is that this will insert something between the symdecrypt
> and the sigver sections.  It will function nearly the same as the sigver,
> except we are creating a completely new and disjoint syntax for handling
> the new packet.
>
> For me, it is really ugly to add a new layer when the existing one can
> easily be modified to work and provide the same function.
>
> Instead we fiddle with the definitions to make it incompatible with the
> existing layers just enough so it must be a new layer, but realize that
> all this new verbage simply exists to forcibly create a new layer, and not
> for any functional reason.

These statements are only valid in the context of your implementation.
I have implemented it in a different way which did not require adding any
new layers.  I simply added calls to the hash function in the decryption
module, as well as the 20 byte holdback buffer.  As it happened I
already had a buffer in the decryption module so modifying it to hold
back 20 bytes was easy.  There were then two extra functions added to
the decryption module, one to finalize and retrieve the hash value,
and one to retrieve the value from the holdback buffer (which holds the
final 20 bytes at the end of processing).  These are then compared at
the end of the packet.  It was not a difficult change.

I don't believe we should judge the difficulty based on just how it
affects your implementation.  If you would like some help I suspect we
could work with you to make similar modifications to your symdecrypt
module.

> I asked what didn't work about extending "signature" packets to
> "verification" packets (with the zero algorithm or something similar -
> or even keeping the signature packet format with a different ID number
> for MDC only packets).
>   
> No one has yet told me why this is any less secure, slower, or harder than
> tacking the 20 bytes onto the end of the plaintext.

I did mention this, in my original message on this topic, when I wrote:

   We have also discussed providing integrity protection via some
   modification to the signature packet format rather than by a new form
   of encrypted packet.  There would be a special kind of "signature" which
   would just consist of a hash of the message to protect its integrity.
   
   However, Phil argues that this kind of integrity protection is inherently
   tied to the use of encryption.  It has no functional effect if not used
   in conjunction with encryption.  This is unlike our other signatures,
   which are cryptographically useful transformations even on their own.
   Because of this close tie to the encryption functionality it makes most
   sense to make it part of the encrypted packet.

> How many lines of code did each method take?  How many cpu-seconds?

Which is the most architecturally attractive way to do it?  Which method
is the most logical and coherent?  Which method would you use if you
were designing from scratch, rather than trying to shoehorn it into an
existing implementation so as to change it as little as possible?

> Altering one byte to add a definition to the signature packet is less of
> a hack than holding back 20 bytes.  Don't assume everyone is running on
> big machines with an OS or API calls to handle this and CPU cycles to
> spare.

Holding back 20 bytes does not take a big machine, or any OS or API calls.
It is a simple circular buffer and about half a page of code.

> I don't.  If you are going to do this then at least force an EOF and
> append 20 bytes without any packet information (i.e. the new stream
> packets would indicate an end where the message ends, but there would be
> 20 bytes (or whatever) extra following not encapsulated in any packet).

Let's not go down the path of putting bytes outside a packet.  That would
violate all of our conventions.

> It may be easy to add in your implementation, and you may not be trying to
> do stream I/O and have something that handles errant packet boundaries
> easily.  This is by no means universal.
>
> One of my implementations is for the Palm Pilot.  Adding a layer instead
> of a few lines in an existing layer) is a really big deal there (exclusive
> of adding algorithms).  Holding back 20 bytes when I am already against
> the memory limitations is going to be very painful.

Surely a 20 byte holdback buffer can't be a major problem, when adding the
new hash context is going to take at least 84 bytes of ram.

> I have pointed out that we can do it without bloating the code.  But it
> seems everyone wants to bloat it.  Assuming PRZ isn't doing another
> "hit-and-run", what does HE think of the alternatives?

Phil is out of the country now, but I have spoken at great length to him
about this over the past month.  I assure you that Phil is THE strongest
supporter of integrating the MDC feature with a new encryption packet.
I cannot over emphasize how strongly he opposes doing it as a hack of
the signature packet.

I showed earlier how inappropriate the signature packet is for this
purpose.  I listed all the fields and showed how few of them made any
sense in this context.  I can understand that this is the path of least
resistance for kludging this feature into existing code, but we would
prefer an approach which makes sense architecturally.  Signature packets
are not appropriate for this purpose.

> If this is going to require another layer, then all such algorithms using
> this new method should be given a MAY level of compliance and not SHOULD
> because of the larger impact on the existing code base.
>
> Conversely, extending the existing structure is easy enough to warrant
> being a SHOULD.

As far as I know, there are three implementations that are affected:
your reference implementation, the Gnu Privacy Guard, and the commercial
PGP from Network Associates.  If we can come to agreement then we can get
these changes into all of these implementations, and make it a SHOULD as
Werner suggested.

Hal Finney
Network Associates, Inc.

Date: Tue, 11 May 1999 16:52:58 -0700
From: [email-masked]
To: [email-masked], [email-masked]
Subject: Re: Agree with PRZs MDC suggestion
Sender: [email-masked]

Werner Koch, <[email-masked]>, writes:
> We should invent a new encrypted data packet which is used for
> encrypted messages with MDC.  Suggestion:
>
>    Packet number ???
>
>    1 byte version  (should be 1)
>    1 byte MDC method (should be 2 to match SHA, or 0 to disable MDC)
>    1 byte number of extra bytes (m) at the end of the encrypted text
>           From now on CFB encrypted with an IV of all zeroes without
>           any strange syncing.
>    n byte random data used as IV (n=blocksize of the cipher)	
>    2 byte the last two bytes of the random data.
>    k byte message
>    m byte hash used for MD

In my other message I pointed out the problem that an attacker could
perturb some of these header values.  With that in mind let us look at
these fields:

>    1 byte version  (should be 1)

This is probably a good idea.  If perturbed by an attacker to a later
version, the software will refuse to process the packet.  We need
to consider though whether, if we later move to a higher version, an
attacker could execute a rollback attack by changing a V2 to a V1.
We can deal with that at that time by making sure that V2 and V1 look
very different (assuming we ever need to create a V2).

>    1 byte MDC method (should be 2 to match SHA, or 0 to disable MDC)

This one worries me.  It allows an attacker to turn a 2 into a 0.  Also,
is there an implication that it can be something other than 2 or 0?  Like,
1 means MD5?  If so, this again offers an attacker more opportunities to
mess with the receiver.  The attacker could change the hash algorithm to
something like 6.  Now the receiver doesn't know if this is a legitimate
message from a later version of PGP that supports hash algorithm 6, or
whether it is a messed up message by an attacker.  If we choose a fixed
hash algorithm this ambiguity cannot arise.

I would prefer to leave this field out.  If you use the new packet format
at all, you get the MDC, using a fixed hash of SHA-1.

>    1 byte number of extra bytes (m) at the end of the encrypted text
>           From now on CFB encrypted with an IV of all zeroes without
>           any strange syncing.

We would then not need this, as the value would always be 20.

>    n byte random data used as IV (n=blocksize of the cipher)	

OK.  I continue to believe that a *conventional* IV is most desirable in
terms of explaining what we are doing to others in the field.  The "pseudo
IV" we have now is hard to explain.  I had to go to some lengths in
getting our FIPS 140 certification (a standard security certification)
to show that our way was just as good as the regular way.

>    2 byte the last two bytes of the random data.

You have not shown whether these are encrypted.  I presume that they are,
and that these are meant to be check bytes used to detect when we have the
right session key.  This way of doing it does not work well when the IV
is unencrypted, as is done in virtually every other cipher in the world
except PGP.  With an unencrypted IV the two check bytes are known, thus
putting two bytes of known plaintext right at the start of the message.
Since one of the goals of the new encryption packet is to regularize our
methods and bring them into conformance with the practices used by other
professionals, I believe we should do check bytes slightly differently.

My proposal was that we have four bytes, two random ones and then those
same two random ones repeated.  These would all be encrypted.  It's not
known plaintext although there is a certain amount of redundancy in the
data, which redundancy is necessary for them to serve as check bytes.

>    k byte message
>    m byte hash used for MD

These, too, would both presuambly be encrypted.  The hash size should be
fixed if we fix a hash algorithm.

> Uri proposed another scheme for better detection of wrong keys - we 
> should consider to use this.

His proposal, from http://www.imc.org/ietf-open-pgp/mail-archive/msg02471.html:

   Make the "pseudo-IV" prefix partially non-random - i.e. the last two 
   bytes being checksum for the other 14. No big deal security-wise and
   noticeable help in detecting the right key.

This isn't too bad for 128 bit block ciphers like Twofish or AES, but as
a general principle we would need to apply it to all ciphers, including
64 bit block ciphers.  I don't like taking away 16 of the 64 bits of IV
in that case.  I can't name a specific attack this would cause but it
doesn't feel right to give up that much of the IV.

Also, of course this only works with the pseudo-IV.  As I wrote above, our
use of a pseudo-IV is an oddball quirk that no one else does.  In order to
generate support for the standard we should try to move away from peculiar
features like this and towards the conventional ways of doing things.

> "If a cipher with a blocksize > 64 bits is used, this new packet 
>  format SHOULD be used".

I agree that it would be sensible to encourage the new format when we go
to new block ciphers.  Unfortunately the next version of PGP will have
Twofish support without MDC, since we were not able to come to consensus
here (and it doesn't look like we are coming any closer).

> To clarify thinks for the old encypted data packet (9), we should
> say that the special CFB mode is used with all blocksizes. 

By this, do you mean the special sync operation after reading the pseudo
IV and check bytes?

Hal Finney
Network Associates, Inc.

From: Cyberspace Policy Institute <[email-masked]>
Subject: URGENT: Need crypto product info!
To: [email-masked], [email-masked]
Date: Tue, 11 May 1999 19:42:22 -0400 (EDT)
Cc: [email-masked]
Sender: [email-masked]

Please forward this message to others who are interested on the topic. A

WWW-version of this message can be found at
http://www.seas.gwu.edu/seas/institutes/cpi/cryptosurvey/call4info.html

Please excuse us for the cross-postings

**************************************************************
           NON-U.S. CRYPTOGRAPHIC PRODUCT SURVEY
                  CALL FOR INFORMATION
**************************************************************

The George Washington University and NAI Labs, The Security Research
Division of Network Associates (formerly the research division of
Trusted Information Systems) are conducting a survey to identify
cryptographic products manufactured outside the United States and are
examining product specifications to assess their functionality and
security.

We are soliciting input from those with knowledge of cryptographic
products through the use of this survey form.  If you know of
cryptographic products that are manufactured in countries other than the
United States, please complete this form and submit it to the Cyberspace
Policy Institute (CPI) NO LATER THAN TUESDAY MAY 18, 1999. You may
submit this form via email to [email-masked] or fax at (202) 994-5505
in Washington D.C.

In addition, we ask you to send or post this survey to anyone or place
that would have knowledge of cryptographic products. Inquiries about
this survey may be made to the Cyberspace Policy Institute at
[email-masked] or (202) 994-5512. This survey may also be found on the
CPI Web site at http://www.seas.gwu.edu/seas/institutes/cpi.

Your cooperation is greatly appreciated.

Professor Lance J. Hoffman, The George Washington University
David Balenson, NAI Labs, The Security Research Division of Network Associates

**************************************************************

           NON-U.S. CRYPTOGRAPHIC PRODUCT SURVEY

DATE:

COMPLETED BY:

Your Name:
Phone:
E-mail:

NAME AND ADDRESS OF MANUFACTURER

Name:
Address:
City:                    State:                  Zip Code:
Country:
URL:

MANUFACTURER CONTACT INFORMATION

Name:                                Title:
Phone:                               FAX:
E-mail:                              800#:

PRODUCT DESCRIPTION

Name (including model and version information):

Product-specific URL:

Is it software-only, hardware-only, or a software/hardware combination?

What does it encrypt (e.g., disk, file, communications, FAX, voice,
magnetic tape, electronic mail)?

If embedded software or hardware, what platforms does it support (e.g.,
PC, Mac, UNIX workstation, IBM mainframe), else if standalone hardware,
what interfaces does it support (RS-232, telephone, V.24, V.35)?

If software, is it in the form of a kit or as an end-user program, else
if hardware, what is the embodiment (e.g., chip, board, PCMCIA card,
smart card, box, phone)?

What algorithms does it employ for data encryption (including
proprietary algorithms and key length)?

If applicable, what algorithms does it employ for key management
(including proprietary algorithms and key length)?

If applicable, what algorithms does it employ for data authentication
(including proprietary algorithms)?

How is the product sold or distributed (e.g., store front, mail order,
telephone order, World Wide Web, anonymous ftp over the Internet)?

If applicable, what is the quantity one purchase price?

(Optional) Approximate number of units sold or distributed?

(Optional) Approximate date product was first available?

Please provide a list of the names and relationships of any associated
companies (e.g., parent company, sister company, distributors). Include
full address and contact name, title, phone, FAX, and e-mail address.
Other information:

PLEASE PROVIDE A COPY OF ANY RELEVANT PRODUCT LITERATURE.

Send completed forms and product literature via e-mail to
[email-masked] or via fax to the Cyberspace Policy Institute at 
202-994-5505 in Washington D.C.

THANK YOU!

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This survey is part of an ongoing worldwide study of cryptographic
products started in April 1994 by Trusted Information Systems and 
Dr. Lance J. Hoffman of the George Washington University.
The December 1997 summary results of the survey are available on the
World Wide Web at
http://www.nai.com/products/security/tis_research/crypto/crypt_surv.asp.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Date: Tue, 11 May 1999 17:24:52 -0400
From: Tom Zerucha <[email-masked]>
To: Werner Koch <[email-masked]>
cc: [email-masked]
Subject: Re: Agree with PRZs MDC suggestion
Sender: [email-masked]

yOn Sun, 9 May 1999, Werner Koch wrote:

> Hello,
> 
> After implementing the MDC by using the signature packets and
> verifiyng that Tom's and my implementation are interoperable, I
> started over and tried to implement my suggestion to use
> use a special MDC packet instead of a signature packet.
> 
>    (1) new encrypted data packet
>    (2) mdc packet with the encrypted hash over (1)
> 
> The problem here is that (2) is encrypted with the same key as (1)
> and actually is part of (1).  We must encrypt only the hash inside 
> of (2), so that the parse can distinguish both packets.  It is quiet
> obvious, that passing the decryption context from (1) to (2) is not 
> very easy.  What we would need to have a good solution, is a conatiner
> packet which replaces the old encrypted data packet
> 
>    Encrypted_Data -+- Data_Containter_Packet -+- Onepass
>                    !                          !- Plaintext	
>                    !                          !- Signature  		
>                    !- MDC_Packet

Not true.  Just as you run the encryptor and get two or more packets out
currently for signatures, and thus you don't need to "pass a decryption
context" from the 1 pass header to the plaintext to the Signature, you
wouldn't need to do this for the MDC, any more than you do if the MDC is
not a separate packet.

In effect what we have now (with buffering or pipes between threads) is:

ciphertext | dearmor | pkdecrypt | symdecrypt | sigver | deliteral

There may be multiple sigvers, one per level of nesting (I use a stack
instead of spawning another layer).

What will happen is that this will insert something between the symdecrypt
and the sigver sections.  It will function nearly the same as the sigver,
except we are creating a completely new and disjoint syntax for handling
the new packet.

For me, it is really ugly to add a new layer when the existing one can
easily be modified to work and provide the same function.

Instead we fiddle with the definitions to make it incompatible with the
existing layers just enough so it must be a new layer, but realize that
all this new verbage simply exists to forcibly create a new layer, and not
for any functional reason.

I asked what didn't work about extending "signature" packets to
"verification" packets (with the zero algorithm or something similar -
or even keeping the signature packet format with a different ID number
for MDC only packets).
  
No one has yet told me why this is any less secure, slower, or harder than
tacking the 20 bytes onto the end of the plaintext.

How many lines of code did each method take?  How many cpu-seconds?

> The bottom line is, that Phil's original suggestion to put the hash
> at the end of the encrypted message is the easiest way to address it.

The MDC is more easily added where it is already being generated through
existing control paths in the code, simply altering the output format
slightly.  How can something that is already there be harder to add than
something completely new?

> I know that it is annoying to hold back the last 20 bytes, but compared
> to the hacked signature packets, I thing it is okay to to this. 

Altering one byte to add a definition to the signature packet is less of
a hack than holding back 20 bytes.  Don't assume everyone is running on
big machines with an OS or API calls to handle this and CPU cycles to
spare.

I don't.  If you are going to do this then at least force an EOF and
append 20 bytes without any packet information (i.e. the new stream
packets would indicate an end where the message ends, but there would be
20 bytes (or whatever) extra following not encapsulated in any packet).

It may be easy to add in your implementation, and you may not be trying to
do stream I/O and have something that handles errant packet boundaries
easily.  This is by no means universal.

One of my implementations is for the Palm Pilot.  Adding a layer instead
of a few lines in an existing layer) is a really big deal there (exclusive
of adding algorithms).  Holding back 20 bytes when I am already against
the memory limitations is going to be very painful.

I have pointed out that we can do it without bloating the code.  But it
seems everyone wants to bloat it.  Assuming PRZ isn't doing another
"hit-and-run", what does HE think of the alternatives?

If this is going to require another layer, then all such algorithms using
this new method should be given a MAY level of compliance and not SHOULD
because of the larger impact on the existing code base.

Conversely, extending the existing structure is easy enough to warrant
being a SHOULD.

Date: Mon, 10 May 1999 09:35:30 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: Agree with PRZs MDC suggestion
Mail-Followup-To: [email-masked]
Sender: [email-masked]

[email-masked] writes:

[ About attacks flipping some bits in the headers to 
  make the receiver think the message has no MDC ]

> I suggest that we should design the packets, if possible, to prevent
> this attack.  What do others feel?  Do we care about this kind of attack?
> Should we take steps to prevent it, or should we allow it to happen?

I think the easiest solution and the one we did at other places too
is to say:

"Implementations SHOULD use the MDC for ciphers with a blocksize of 64
bit.  Implementations MUST use the MDC for ciphers with a blocksize
other than 64.  If an implemenations detects a violation of the above
it SHOULD notify the user about this.  It MUST do this for messages
encrypted with non-64 bit blocksize cipher."

Or something similar.

Date: Sun, 9 May 1999 18:08:17 -0700
From: [email-masked]
To: [email-masked], [email-masked]
Subject: Re: Agree with PRZs MDC suggestion
Sender: [email-masked]

An attacker can modify encrypted messages to a limited extent.  In CFB
mode, if he xors one bit of the ciphertext, it has two effects.  It xors
the corresponding bit of the plaintext, and it also turns the following
block of plaintext into complete garbage.  The remainder of the message
is unchained.

Attackers can also delete entire blocks of messages.  If they do it at
the end, this has no obvious effect.  If they do it at the beginning,
they can supply an IV so that everything decrypts OK (but missing the
first blocks of the encrypted messages).  If they do it in the middle,
there will be one block of garbage after the spot where the deleted
blocks would go.

Attackers can also rearrange blocks of messages, or moving groups of
blocks from one point to another, or duplicating groups of blocks in
various ways.  This will normally put a block of garbage at the join
points when the messages are decrypted.

It is important to realize that these blocks of garbage or noise will
not necessarily expose the attacker's actions.  They may be overlooked
by the receiver.  They may be located in a part of the message which
he does not study closely (like mail headers or data tables).  They may
be at the very beginning or end of the message where the important data
is in the middle, or vice versa.  We can't assume that blocks of noise
will always be detected.  (And of course the truncation attack leaves
no noise blocks.)

Our goal with the MDC feature is to detect these kinds of transformations.
As we have been discussing, including a hash of the message within the
encrypted data should accomplish this.

One possible attack we need to then consider is whether a message sent
in this form can be transformed by an attacker so that the receiver does
not attempt to do the MDC verification.  The attacker might be able to
change the format of the message so that it looks like a non-MDC message,
using some of the tools above.

As a simple example, if we include a bit in the message header that
tells whether the message has MDC protection, and the attacker guessed
that that bit was on, he could turn it off by xoring the right place in
the ciphertext.  This would introduce a burst of noise in the following
block of the message, but depending on the block size and the message
format, this might still allow the message to decrypt successfully.

The receiver would not be fooled into thinking that he had an
MDC-protected message which was untouched, but he would be fooled into
thinking that the message had been sent without MDC protection when in
fact the sender had intended to protect it.

I believe it is possible to provide for this level of protection, but it
will put some constraints on the design.  Anything in the headers which
the attacker could tweak to disable the MDC checking (like changing a hash
algorithm value) would have to be such that the change will be detected.
There could be another checksum in the headers itself, or the headers
could be structured so that the block of noise is guaranteed to corrupt
crucial data, or the data structures could be such that MDC checking
can't be disabled.

I suggest that we should design the packets, if possible, to prevent
this attack.  What do others feel?  Do we care about this kind of attack?
Should we take steps to prevent it, or should we allow it to happen?

Hal Finney
Network Associates

Date: Sun, 9 May 1999 20:50:54 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Agree with PRZs MDC suggestion
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Hello,

After implementing the MDC by using the signature packets and
verifiyng that Tom's and my implementation are interoperable, I
started over and tried to implement my suggestion to use
use a special MDC packet instead of a signature packet.

   (1) new encrypted data packet
   (2) mdc packet with the encrypted hash over (1)

The problem here is that (2) is encrypted with the same key as (1)
and actually is part of (1).  We must encrypt only the hash inside 
of (2), so that the parse can distinguish both packets.  It is quiet
obvious, that passing the decryption context from (1) to (2) is not 
very easy.  What we would need to have a good solution, is a conatiner
packet which replaces the old encrypted data packet

   Encrypted_Data -+- Data_Containter_Packet -+- Onepass
                   !                          !- Plaintext	
                   !                          !- Signature  		
                   !- MDC_Packet

I think this is the most clear solution but far too complicate for
the our goal.

The bottom line is, that Phil's original suggestion to put the hash
at the end of the encrypted message is the easiest way to address it.
I know that it is annoying to hold back the last 20 bytes, but compared
to the hacked signature packets, I thing it is okay to to this. 

We should invent a new encrypted data packet which is used for
encrypted messages with MDC.  Suggestion:

   Packet number ???

   1 byte version  (should be 1)
   1 byte MDC method (should be 2 to match SHA, or 0 to disable MDC)
   1 byte number of extra bytes (m) at the end of the encrypted text
          From now on CFB encrypted with an IV of all zeroes without
          any strange syncing.
   n byte random data used as IV (n=blocksize of the cipher)	
   2 byte the last two bytes of the random data.
   k byte message
   m byte hash used for MD

Uri proposed another scheme for better detection of wrong keys - we 
should consider to use this.

"If a cipher with a blocksize > 64 bits is used, this new packet 
 format SHOULD be used".

To clarify thinks for the old encypted data packet (9), we should
say that the special CFB mode is used with all blocksizes.