Subject: ANNOUNCE: ISOC Netw. & Distr. Sys. Security Symp. (NDSS'02)

From: [email-masked]
Date: Thu, 29 Nov 2001 09:26:52 -0500 (EST)

R E G I S T E R   N O W ! !

THE INTERNET SOCIETY'S
2002 NETWORK AND DISTRIBUTED SYSTEM SECURITY SYMPOSIUM (NDSS'02)
February 7-8, 2002
Catamaran Resort Hotel, San Diego, California

General Chair:   Cliff Neuman, USC Information Sciences Institute
Program Chairs:  Paul Van Oorschot, Entrust
                 Virgil Gligor, University of Maryland

ONLINE INFORMATION AND REGISTRATION:  http://www.isoc.org/ndss02

EARLY REGISTRATION DISCOUNT DEADLINE:  January 11, 2002

The 9th annual NDSS Symposium brings together researchers, implementers, and
users of network and distributed system security technologies to discuss
today's important security issues and challenges. The Symposium provides a
mix of technical papers and panel presentations that describe promising new
approaches to security problems that are practical and, to the extent
possible, have been implemented. NDSS fosters the exchange of technical
information and encourages the Internet community to deploy available
security technologies and develop new solutions to unsolved problems.

THIS YEAR'S TOPICS INCLUDE:
* Wireless Security
* Analyzing the Anonymity of Anonymous Networking Protocols
* Intrusion Detection and Defending Against Network Attacks
* Detecting Steganographic Content on the Web
* Server-Aided Digital Signatures
* PKI, Certificates and Privilege Management
* Various Aspects of Transport Layer Security/TLS

PRE-CONFERENCE TECHNICAL TUTORIALS:
* Major IETF Security Standards:  PKIX, IPsec, SSL/TLS, Dr. Stephen Kent
* Crash Course in SSL and TLS, Mr. Eric Rescorla
* Building Secure Software, Dr. Gary McGraw
* Wirelss LAN Security:  Problems & Solutions, Dr. William Arbaugh
* Group Security, Dr. Thomas Harjono and Mr. Hugh Harney

For further information about NDSS'02 REGISTRATION contact Michele Estadt
at the Internet Society at +1-703-326-9880 ext 104 or send e-mail to
[email-masked]

SPONSORSHIP OPPORTUNITIES AVAILABLE!
Take advantage of this high visibility event.  Contact Martin Kupres at the
Internet Society EMEA office at +41 22 807 1444 or send e-mail to
[email-masked].

THE INTERNET SOCIETY is a non-governmental organization for global
cooperation and coordination for the Internet and its internetworking
technologies and applications.

Date: Thu, 29 Nov 2001 09:26:52 -0500 (EST)
From: [email-masked]
To: [email-masked]
Subject: ANNOUNCE: ISOC Netw. & Distr. Sys. Security Symp. (NDSS'02)
Sender: [email-masked]

                     R E G I S T E R   N O W ! !

THE INTERNET SOCIETY'S
2002 NETWORK AND DISTRIBUTED SYSTEM SECURITY SYMPOSIUM (NDSS'02)
February 7-8, 2002
Catamaran Resort Hotel, San Diego, California

General Chair:   Cliff Neuman, USC Information Sciences Institute
Program Chairs:  Paul Van Oorschot, Entrust
                 Virgil Gligor, University of Maryland

ONLINE INFORMATION AND REGISTRATION:  http://www.isoc.org/ndss02

EARLY REGISTRATION DISCOUNT DEADLINE:  January 11, 2002

The 9th annual NDSS Symposium brings together researchers, implementers, and
users of network and distributed system security technologies to discuss
today's important security issues and challenges. The Symposium provides a
mix of technical papers and panel presentations that describe promising new
approaches to security problems that are practical and, to the extent
possible, have been implemented. NDSS fosters the exchange of technical
information and encourages the Internet community to deploy available
security technologies and develop new solutions to unsolved problems.

THIS YEAR'S TOPICS INCLUDE:
* Wireless Security
* Analyzing the Anonymity of Anonymous Networking Protocols
* Intrusion Detection and Defending Against Network Attacks
* Detecting Steganographic Content on the Web
* Server-Aided Digital Signatures
* PKI, Certificates and Privilege Management
* Various Aspects of Transport Layer Security/TLS

PRE-CONFERENCE TECHNICAL TUTORIALS:
* Major IETF Security Standards:  PKIX, IPsec, SSL/TLS, Dr. Stephen Kent
* Crash Course in SSL and TLS, Mr. Eric Rescorla
* Building Secure Software, Dr. Gary McGraw
* Wirelss LAN Security:  Problems & Solutions, Dr. William Arbaugh
* Group Security, Dr. Thomas Harjono and Mr. Hugh Harney

For further information about NDSS'02 REGISTRATION contact Michele Estadt
at the Internet Society at +1-703-326-9880 ext 104 or send e-mail to
[email-masked]

SPONSORSHIP OPPORTUNITIES AVAILABLE!
Take advantage of this high visibility event.  Contact Martin Kupres at the
Internet Society EMEA office at +41 22 807 1444 or send e-mail to
[email-masked].

THE INTERNET SOCIETY is a non-governmental organization for global
cooperation and coordination for the Internet and its internetworking
technologies and applications.

Date: Thu, 29 Nov 2001 08:32:43 -0500
From: John J Kane <[email-masked]>
To: [email-masked]
Subject: prefer "- From " instead of ">From "??
Sender: [email-masked]

Implementation note:
For implementations which emit out-of-spec workarounds
to forestall mangling of "From " in transit, it has been
pointed out that stuffing "From " with "- " safely masks
the offending sequence.  On the receiving end, the stuffed
line automatically reverts cleanly to the original text,
without any special handling.

This may be the sanest way to handle that case.
Comments?

--
John J. Kane

Date: Wed, 28 Nov 2001 16:07:58 +0100
From: Thomas Roessler <[email-masked]>
To: whom it may concern: ;
Subject: MIME polymorphism
Reply-To: [email-masked]
Sender: [email-masked]

The two major e-mail security protocols currently proposed - S/MIME 
and PGP/MIME - both build on the fundamental framework of 
multipart/signed messages specified in RFC 1847.  In this framework, 
the data to be signed is formatted as a single MIME part (which may, 
of course, contain nested sub-parts).  This MIME part is then hashed 
for the signature.  The hash does, in particular, include all the 
meta infomration present on the MIME level, including the body 
part's content type.  That way, the signature does, for instance, 
include the information whether some PostScript code which was 
signed should be interpreted by a postscript interpreter for display 
(application/postscript), or whether this code should just be 
displayed as plain text (text/plain). In theory, with 
multipart/signed, the actual data and the information how it must be 
interpreted is both signed and protected.

This theory fails on two levels: First, knowing a file's content 
type is not sufficient to guarantee correct interpretation.  This 
has been demonstrated before; think about differences in the 
interpretation of certain special characters when documents are 
exchanged between some Microsoft Word versions for the Windows and 
Macintosh platforms. [4]

Second, the theory is based on the assumption that the 
interpretation of the MIME meta information contained in Content-* 
headers is well-defined. This assumption is violated with malformed 
MIME messages which contain contradictory information: When there 
are, for instance, multiple boundary parameters for a single 
multipart/* attachment, implementations will generally follow the 
mantra of being liberal in what they accept, and just choose one.
When there are multiple Content-Type headers present on a single 
attachment, implementations will likewise be liberal, and choose one 
(or even mix information from the two headers).

Since the choices made differ between MIME implementations, it is 
for instance easily possible to create an e-mail mesage with a 
multipart/mixed body which seems to contain different content, 
depending on whether it's displayed with mutt [5] or pine [6].

Note that this problem does not only apply to digital signatures, 
but also to virus scanners: If these try to be liberal with respect 
to malformed MIME messages, they may easily check attachments for 
viruses which will never be seen by users - and, likewise, they may 
not scan those attachments which are actually displayed by users' 
software.

To prevent this problem from occuring, security services must not be 
liberal in what they accept, or try to hide possible problems from 
users. Instead of software silently making choices, ambiguities must 
be treated as malicious, and users must be warned.

References:

 1. Galvin, Murphy, Crocker, Freed: Security Multiparts for MIME: 
    Multipart/Signed and Multipart/Encrypted. RFC 1847, October 1995.

 2. Freed, Borenstein: Multipurpose Internet Mail Extensions (MIME) 
    Part One: Format of Internet Message Bodies.  RFC 2045, November 
    1996.

 3. Elkins, Del Torto, Levien, Roessler: MIME Security with OpenPGP. 
    RFC 3156, August 2001.

 4. Fox, Zu einem prinzipiellen Problem digitaler Signaturen, 
    Datenschutz und Datensicherheit (DuD) 7/1998, pp. 386-388.

 5. Mutt home page: <http://www.mutt.org/>
 
 6. Pine Information Center: <http://www.washington.edu/pine/>

-- 
Thomas Roessler                        http://log.does-not-exist.org/

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: Parser abilities, and MDCs (Re: pointers to openpgp-interopknowledge  base?)
Date: Mon, 19 Nov 2001 09:40:58 +0000 (UTC)
Organization: IKS GmbH Jena
Lines: 22
NNTP-Posting-Host: taranis.iks-jena.de
NNTP-Posting-Date: Mon, 19 Nov 2001 09:40:58 +0000 (UTC)
Sender: [email-masked]

* Florian Weimer wrote:
>Werner Koch <[email-masked]> writes:
>> On Thu, 08 Nov 2001 10:34:44 +0200, disastry  said:
>> rfc2440b03> extends until the end of the file. In general, an implementation
>> rfc2440b03> SHOULD NOT use indeterminate length packets except where the end
>> rfc2440b03> of the data will be clear from the context,
>>
>> > it does not talks about compression,
>>
>> Well, the "clear from context" is exactly the case for compressed
>> packets because the zip algorithm has its own length management.
>
>As far as I understand this description, "clear from context" means
>"clear from the OpenPGP context", e.g., the packet is contained in a
>larger packet which has got a length limitation, or it is the last one
>in an OpenPGP message.

Yes and no. ;-) The senctence was coined by describing the 2.6.2ff.
implementation. This implementation does terminate the packet on the end of
compressed data as Werner said, but never generate further packets as
Florian remarked. So Werner is right by implementation and Florian is right
by phenomenology.

Date: Sat, 17 Nov 2001 01:10:45 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: interop/encryption to pgp2
Mail-Followup-To: [email-masked]
Sender: [email-masked]

--7AUc2qLy4jB3hD7Z
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Nov 16, 2001 at 05:05:25PM -0800, Ingo Luetkebohle wrote:
> Hi,
>=20
> David Shaw just pointed out that PGP2.6.2 chokes when it receives a
> message that has been encrypted to a v4 key, even when it has been
> encrypted to a v3 key, too.=20
>=20
> I can only assume that this is because public-key encrypted session
> key packets allow non-RSA cipher material.  Can anybody who has a
> working knowledge of the old code confirm this?

It can also be the size of the key.  V4 RSA keys that are greater than
2048 bits long will cause PGP 2.6.2 to fail with various odd errors.
V4 RSA keys <=3D 2048 bits long can be mixed in with v3 keys without
causing any problems.

David

--=20
David Shaw          |  Technical Lead
<[email-masked]>  |  Enterprise Content Delivery
617-250-3028        |  Akamai Technologies

--7AUc2qLy4jB3hD7Z
Content-Type: application/pgp-signature
Content-Disposition: inline

--7AUc2qLy4jB3hD7Z--

Date: Fri, 16 Nov 2001 20:29:05 -0800
To: Derek Atkins <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: interop/encryption to pgp2
Cc: [email-masked]
Sender: [email-masked]

At 8:30 PM -0500 11/16/01, Derek Atkins wrote:

>Basically, the only thing you can do is, if you're using -ANY-
>non-RFC1991 packets, you should emit a leading "nonce" header that
>declares the message to be a non-RFC1991 message.  IIRC, in PGP 5.0 we
>did this via a two-byte leading sequence followed by the three ASCII
>characters P, G, and P.  I'd have to go look at the code to figure out
>what the leading bytes were.

Marker Packet -- Section 5.8 of 2440.

I'll note that while OpenPGP encourages interoperating with 2.6.2, it is
not required. It is not quite deprecated, but there are weasel words in
2440 that permit "breaking" 2440 in a few cases for 2.6.2 compatibility.

So 2.6.2 compatibility will get you a golf clap, but it shouldn't stand in
the way of getting us to Draft Standard.

	Jon

	Jon

To: [email-masked]
Cc: [email-masked]
Subject: Re: interop/encryption to pgp2
From: Derek Atkins <[email-masked]>
Date: 16 Nov 2001 20:30:48 -0500
Lines: 56
Sender: [email-masked]

PGP 2.6.2 does not handle any new-style packets, even if
it's only part of a message.  If PGP 2.6.2 doesn't understand
_any_ packet, it will barf.

Basically, the only thing you can do is, if you're using -ANY-
non-RFC1991 packets, you should emit a leading "nonce" header that
declares the message to be a non-RFC1991 message.  IIRC, in PGP 5.0 we
did this via a two-byte leading sequence followed by the three ASCII
characters P, G, and P.  I'd have to go look at the code to figure out
what the leading bytes were.

-derek

Ingo Luetkebohle <[email-masked]> writes:

> --1UWUbFP1cBYEclgG
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
> 
> Hi,
> 
> David Shaw just pointed out that PGP2.6.2 chokes when it receives a
> message that has been encrypted to a v4 key, even when it has been
> encrypted to a v3 key, too.=20
> 
> I can only assume that this is because public-key encrypted session
> key packets allow non-RSA cipher material.  Can anybody who has a
> working knowledge of the old code confirm this?
> 
> If this is the case, would it be possible to introduce a v4 packet of
> that type? Would that be ignored by PGP2, so that having both v3 and
> v4 public key encrypted session key packets would work with pgp2?
> 
> Ingo
> 
> --1UWUbFP1cBYEclgG
> Content-Type: application/pgp-signature
> Content-Disposition: inline
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: Weitere Infos: siehe http://www.gnupg.org
> 
> iD8DBQE79bfVzZDBZDStzlsRAvfoAJ9No97fDMgoVCdCIEVRPu5rV+mJuQCeJB/P
> XkZYDFmyylSMnNKMxtUNn3o=
> =5kFE
> -----END PGP SIGNATURE-----
> 
> --1UWUbFP1cBYEclgG--

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

Date: Fri, 16 Nov 2001 17:05:25 -0800
From: Ingo Luetkebohle <[email-masked]>
To: [email-masked]
Subject: interop/encryption to pgp2
Reply-To: [email-masked]
Sender: [email-masked]

--1UWUbFP1cBYEclgG
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

David Shaw just pointed out that PGP2.6.2 chokes when it receives a
message that has been encrypted to a v4 key, even when it has been
encrypted to a v3 key, too.=20

I can only assume that this is because public-key encrypted session
key packets allow non-RSA cipher material.  Can anybody who has a
working knowledge of the old code confirm this?

If this is the case, would it be possible to introduce a v4 packet of
that type? Would that be ignored by PGP2, so that having both v3 and
v4 public key encrypted session key packets would work with pgp2?

Ingo

--1UWUbFP1cBYEclgG
Content-Type: application/pgp-signature
Content-Disposition: inline

--1UWUbFP1cBYEclgG--

To: [email-masked]
Subject: Re: Parser abilities, and MDCs (Re: pointers to openpgp-interopknowledge  base?)
From: Florian Weimer <[email-masked]>
Date: 16 Nov 2001 17:00:56 +0100
Lines: 22
Sender: [email-masked]

Werner Koch <[email-masked]> writes:

> On Thu, 08 Nov 2001 10:34:44 +0200, disastry  said:
> 
> rfc2440b03> extends until the end of the file. In general, an implementation
> rfc2440b03> SHOULD NOT use indeterminate length packets except where the end
> rfc2440b03> of the data will be clear from the context,
> 
> > it does not talks about compression,
> 
> Well, the "clear from context" is exactly the case for compressed
> packets because the zip algorithm has its own length management.

As far as I understand this description, "clear from context" means
"clear from the OpenPGP context", e.g., the packet is contained in a
larger packet which has got a length limitation, or it is the last one
in an OpenPGP message.

-- 
Florian Weimer 	                  [email-masked]
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898

Date: Thu, 8 Nov 2001 19:38:13 -0800
To: [email-masked] (Peter Gutmann)
From: John  W Noerenberg II <[email-masked]>
Subject: segmented packets (was Re: Parser abilities, and MDCs (Re: pointers to openpgp-interopknowledge base?))
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At 9:50 AM +1300 11/9/01, Peter Gutmann wrote:
>John  W Noerenberg II <[email-masked]> writes:
>
>>What I'm mainly concerned with as far as interoperability on this point is
>>whether implementations support segmented packets, and the interpretation of
>>of the data is consistent across implementations.
>
>Mine doesn't.  If I get a huge amount of demand for it (which seems unlikely,
>since none of the PGP versions I've got installed seem to produce them under
>normal usage) I may add decode-only support for them.

I've got an example that uses segmented packets generated with PGP 
7.0.3!  What I did was encrypt and sign a 2K text file.  I can't tell 
you why PGP 7.0.3 uses a segmented packet, but it certainly does.

-- 

john noerenberg
[email-masked]
   ----------------------------------------------------------------------
   While the belief we  have found the Answer can separate us
   and make us forget our humanity, it is the seeking that continues
   to bring us together, the makes and keeps us human.
   -- Daniel J. Boorstin, "The Seekers", 1998
   ----------------------------------------------------------------------

Date: Fri, 9 Nov 2001 09:50:25 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Parser abilities, and MDCs (Re: pointers to openpgp-interopknowledge base?)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

John  W Noerenberg II <[email-masked]> writes:

>What I'm mainly concerned with as far as interoperability on this point is
>whether implementations support segmented packets, and the interpretation of
>of the data is consistent across implementations.

Mine doesn't.  If I get a huge amount of demand for it (which seems unlikely,
since none of the PGP versions I've got installed seem to produce them under
normal usage) I may add decode-only support for them.

Peter.

Date: Thu, 8 Nov 2001 11:53:43 -0800
To: [email-masked] (Peter Gutmann)
From: John  W Noerenberg II <[email-masked]>
Subject: Re: Parser abilities, and MDCs (Re: pointers to openpgp-interopknowledge base?)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 7:02 AM +1300 11/9/01, Peter Gutmann wrote:
>Urgh, I hope no-one interprets it that way.  The partial-length encoding is
>incredibly painful to use with its silly power-of-two restriction (you can't
>just say "This is what I've got so far, the next lot starts here" but have to
>chop it up into little power-of-two length pieces just to fit the *&#^$&#*
>length-encoding mechanism).  GPG uses the definite-length format where it can
>and 0xA3 where it can't (compressed data), something I agree with
>wholeheartedly.

What I'm mainly concerned with as far as interoperability on this 
point is whether implementations support segmented packets, and the 
interpretation of of the data is consistent across implementations.
-- 

john noerenberg
[email-masked]
   ----------------------------------------------------------------------
   While the belief we  have found the Answer can separate us
   and make us forget our humanity, it is the seeking that continues
   to bring us together, the makes and keeps us human.
   -- Daniel J. Boorstin, "The Seekers", 1998
   ----------------------------------------------------------------------

Date: Thu, 8 Nov 2001 11:58:41 -0800
To: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[email-masked]>
From: John  W Noerenberg II <[email-masked]>
Subject: Re: pointers to openpgp-interop knowledge base?
Cc: [email-masked]
Sender: [email-masked]

At 1:24 PM +0900 11/6/01, Kazu Yamamoto 
(=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) wrote:
>Another PGP parser can be found:
>	http://pgp.iijlab.net/pgpdump.html
>
>Web interface is also available.

Thanks, Kazu.  I'll have a look.

At 12:19 PM -0800 11/6/01, Len Sassaman wrote:
>GnuPG has such a parser built into it. Also, there's a perl script written
>by Mark E. Shoulson called pgpacket3.1 that tries to do the same thing.

It will be interesting to compare the different parsers.  I suspect 
each will have their uses.
-- 

john noerenberg
[email-masked]
   ----------------------------------------------------------------------
   While the belief we  have found the Answer can separate us
   and make us forget our humanity, it is the seeking that continues
   to bring us together, the makes and keeps us human.
   -- Daniel J. Boorstin, "The Seekers", 1998
   ----------------------------------------------------------------------

Date: Thu, 8 Nov 2001 11:59:01 -0800
From: [email-masked]
To: [email-masked], [email-masked]
Subject: Re: Parser abilities, and MDCs (Re: pointers to openpgp-interopknowledge base?)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Derek Atkins writes:
> The reason Colin and I came up with this idea was the belief that
> 	a) we might want to encode data longer than 32 bits, and
> 	b) we needed a way to differentiate ourselves with the
> 	   then-existing PGP 2.x length-encoding scheme

Actually at NAI we have used this scheme to be able to handle > 2^32
bit files for one of our applications.  It was an astonishingly easy
modification to the code to be able to handle such large buffers, thanks
to Derek's and Colin's design, which we are still using.  In fact it
really came down to a two-line change to set the flag to use partial body
length packets in this case, and everything else worked automatically.
Most of the work was in identifying that the file was > 2^32 bits and
changing the APIs to pass that information into the place where it
was needed.

Hal

To: [email-masked] (Peter Gutmann)
Cc: [email-masked], [email-masked]
Subject: Re: Parser abilities, and MDCs (Re: pointers to openpgp-interopknowledge base?)
From: Derek Atkins <[email-masked]>
Date: 08 Nov 2001 14:35:33 -0500
Lines: 41
Sender: [email-masked]

Well, the whole point of indefinite-length encoding was to encode
something when you didn't know how long it was.  For example:

run-some-command | pgp | some-other-command

In this case, you don't know how long the input is going to be,
therefore you want to use indefinite-length encoding.  On the
other hand, if you can 'stat()' the source file ahead of time,
you should DEFINITELY use definite-length encoding.

-derek

[email-masked] (Peter Gutmann) writes:

> Derek Atkins <[email-masked]> writes:
> >>If only it were that easy.  Consider what happens when someone says "You have a
> >>900K transfer buffer, stream data through it".
> >
> >Do you mean you have 900K to transfer, or you have a buffer of 900K that you
> >can use to buffer something larger?  In either case, I'd use the largest
> >buffer-size that fits (i.e. 512K in this case) and just eat the rest of the
> >buffer.
> 
> I don't control it, I'm told "Here's an xK buffer, employ it optimally" (as a
> generalisation of that, any encoding method which forces a certain
> implementation style to the exclusion of others is a bad idea.  In this
> instance it makes it extremely painful to use arbitrary-sized buffers).
> 
> >it's what we came up with at the time.
> 
> There's a simple solution, which is to avoid it where possible (it's not
> actually needed anywhere except maybe a few special-case situations, so you can
> use definite-length encoding and 0xA3 in most cases).
> 
> Peter.

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

Date: Fri, 9 Nov 2001 08:25:52 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Parser abilities, and MDCs (Re: pointers to openpgp-interopknowledge base?)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Derek Atkins <[email-masked]> writes:
>>If only it were that easy.  Consider what happens when someone says "You have a
>>900K transfer buffer, stream data through it".
>
>Do you mean you have 900K to transfer, or you have a buffer of 900K that you
>can use to buffer something larger?  In either case, I'd use the largest
>buffer-size that fits (i.e. 512K in this case) and just eat the rest of the
>buffer.

I don't control it, I'm told "Here's an xK buffer, employ it optimally" (as a
generalisation of that, any encoding method which forces a certain
implementation style to the exclusion of others is a bad idea.  In this
instance it makes it extremely painful to use arbitrary-sized buffers).

>it's what we came up with at the time.

There's a simple solution, which is to avoid it where possible (it's not
actually needed anywhere except maybe a few special-case situations, so you can
use definite-length encoding and 0xA3 in most cases).

Peter.

To: [email-masked] (Peter Gutmann)
Cc: [email-masked], [email-masked]
Subject: Re: Parser abilities, and MDCs (Re: pointers to openpgp-interopknowledge base?)
From: Derek Atkins <[email-masked]>
Date: 08 Nov 2001 13:57:45 -0500
Lines: 40
Sender: [email-masked]

[email-masked] (Peter Gutmann) writes:

> If only it were that easy.  Consider what happens when someone says "You have a
> 900K transfer buffer, stream data through it".  Instead of being able to drop a

Do you mean you have 900K to transfer, or you have a buffer of 900K
that you can use to buffer something larger?  In either case, I'd use
the largest buffer-size that fits (i.e. 512K in this case) and just
eat the rest of the buffer.

> simple 32-bit length at the start and read in 899,996 bytes, encrypt, and write
> it out again, I have to break off a 512K chunk, then a 256K chunk, then a 64K
> chunk, then a 32K chunk, then an 8K chunk, then a 4K chunk, etc etc etc.
> Because the amount of expansion is variable-length, depending on the size of
> the I/O buffer I have to precalculate the encoding expansion beforehand and
> reduce the data amount read by that amount to see what it'll take to optimally
> fill the buffer, and because I have to keep dropping in partial-length headers
> all over the place I can't do a single I/O but have to do it all in dribs and
> drabs, and in general do a lot of unnecessary work (both in terms of writing
> code and CPU time) and waste a lot more space in encoding than simply using a
> 32-bit length would have.

The reason Colin and I came up with this idea was the belief that
	a) we might want to encode data longer than 32 bits, and
	b) we needed a way to differentiate ourselves with the
	   then-existing PGP 2.x length-encoding scheme

So, based on these constraints, we couldn't use a simple 32-bit length
encoding without adding extra bytes to the overhead.  Perhaps this was
a poor choice, but it's what we came up with at the time.

> Peter.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

Date: Fri, 9 Nov 2001 07:46:24 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Parser abilities, and MDCs (Re: pointers to openpgp-interopknowledge base?)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

[email-masked] writes:

>[email-masked] (Peter Gutmann) writes:
>>Urgh, I hope no-one interprets it that way.  The partial-length encoding is
>>incredibly painful to use with its silly power-of-two restriction (you can't
>>just say "This is what I've got so far, the next lot starts here" but have to
>>chop it up into little power-of-two length pieces just to fit the *&#^$&#*
>>length-encoding mechanism).  GPG uses the definite-length format where it can
>>and 0xA3 where it can't (compressed data), something I agree with
>>wholeheartedly.
>
>Come on, Peter...  If you have to buffer 4K-bytes, is that so horrible?

If only it were that easy.  Consider what happens when someone says "You have a
900K transfer buffer, stream data through it".  Instead of being able to drop a
simple 32-bit length at the start and read in 899,996 bytes, encrypt, and write
it out again, I have to break off a 512K chunk, then a 256K chunk, then a 64K
chunk, then a 32K chunk, then an 8K chunk, then a 4K chunk, etc etc etc.
Because the amount of expansion is variable-length, depending on the size of
the I/O buffer I have to precalculate the encoding expansion beforehand and
reduce the data amount read by that amount to see what it'll take to optimally
fill the buffer, and because I have to keep dropping in partial-length headers
all over the place I can't do a single I/O but have to do it all in dribs and
drabs, and in general do a lot of unnecessary work (both in terms of writing
code and CPU time) and waste a lot more space in encoding than simply using a
32-bit length would have.

Peter.

To: [email-masked] (Peter Gutmann)
Cc: [email-masked], [email-masked]
Subject: Re: Parser abilities, and MDCs (Re: pointers to openpgp-interopknowledge base?)
From: Derek Atkins <[email-masked]>
Date: 08 Nov 2001 13:30:28 -0500
Lines: 24
Sender: [email-masked]

[email-masked] (Peter Gutmann) writes:

> Urgh, I hope no-one interprets it that way.  The partial-length encoding is
> incredibly painful to use with its silly power-of-two restriction (you can't
> just say "This is what I've got so far, the next lot starts here" but have to
> chop it up into little power-of-two length pieces just to fit the *&#^$&#*
> length-encoding mechanism).  GPG uses the definite-length format where it can
> and 0xA3 where it can't (compressed data), something I agree with 
> wholeheartedly.

Come on, Peter...  If you have to buffer 4K-bytes, is that so horrible?
Besides, if you're doing a streaming application where you don't want
to buffer, you're better off packetizing anyways instead of making one
large stream.

> Peter.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

Date: Fri, 9 Nov 2001 07:02:39 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Parser abilities, and MDCs (Re: pointers to openpgp-interopknowledge base?)
Sender: [email-masked]

[email-masked] writes:

>rfc2440b03>4.2.1. Old-Format Packet Lengths
>rfc2440b03>[snip]
>rfc2440b03>   The meaning of the length-type in old-format packets is:
>rfc2440b03>   3 - The packet is of indeterminate length.  The header is 1 octet
>rfc2440b03>       long, and the implementation must determine how long the packet
>rfc2440b03>       is. If the packet is in a file, this means that the packet
>rfc2440b03>       extends until the end of the file. In general, an implementation
>rfc2440b03>       SHOULD NOT use indeterminate length packets except where theend
>rfc2440b03>       of the data will be clear from the context,
>
>it does not talks about compression, so I think it should be the same for any
>packet type

In general indefinite-length packets are a pain, you can avoid them in all
cases except compressed-data where you don't know the length in advance (and
maybe a few oddball streaming applications).  Although the standard doesn't say
it, common sense would dictate using the definite-length encoding for all but
compressed data.

>rfc2440b03>4.2.3. Packet Length Examples
>rfc2440b03>[snip]
>rfc2440b03>   An implementation MAY use Partial Body Lengths for data packets,be
>                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>rfc2440b03>   they literal, compressed, or encrypted. The first partial length
>                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>rfc2440b03>   MUST be at least 512 octets long. Partial Body Lengths MUST NOT be
>rfc2440b03>   used for any other packet types.
>
>so it is ok for all data packets..

Urgh, I hope no-one interprets it that way.  The partial-length encoding is
incredibly painful to use with its silly power-of-two restriction (you can't
just say "This is what I've got so far, the next lot starts here" but have to
chop it up into little power-of-two length pieces just to fit the *&#^$&#*
length-encoding mechanism).  GPG uses the definite-length format where it can
and 0xA3 where it can't (compressed data), something I agree with 
wholeheartedly.

Peter.

To: [email-masked]
Cc: [email-masked]
Subject: Re: Parser abilities, and MDCs (Re: pointers to openpgp-interopknowledge  base?)
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Thu, 08 Nov 2001 12:19:16 +0100
Lines: 30
Sender: [email-masked]

On Thu, 08 Nov 2001 10:34:44 +0200, disastry  said:

rfc2440b03> extends until the end of the file. In general, an implementation
rfc2440b03> SHOULD NOT use indeterminate length packets except where the end
rfc2440b03> of the data will be clear from the context,

> it does not talks about compression,

Well, the "clear from context" is exactly the case for compressed
packets because the zip algorithm has its own length management.

> but gpg implements this different way than in RFC1991 and RFC2440:

Not if you give --openpgp or when the recipient uses a v4 key.  I used
the other method to implement the indefinite length packets before I
knew about the OpenPGP WG.

> other interoperability problem is that gpg puts
> signature after the data packet, pgp expect it before..
> I think it is because gpg wants to do all in
> one pass without seeking or using temporary files.

Exactly. I have suggested to write a wrapper which swaps the sequence.

  Werner

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

Date: Thu, 08 Nov 2001 10:34:44 +0200
From: [email-masked]
Organization: disastry.NO.SPaM.NET
To: [email-masked]
Subject: Re: Parser abilities, and MDCs (Re: pointers to openpgp-interopknowledge  base?)
Sender: [email-masked]

Werner Koch wrote:

> On Tue, 6 Nov 2001 23:17:56 -0500, Michael Young said:
> 
> > answer.  The issue was that GnuPG used an old-style indeterminate-length
> > packet for the plaintext before the MDC (see my message of August 23
> 
> But only if the plaintext is a compressed packet - right?
> 
>   Werner

rfc2440b03> 4.2.1. Old-Format Packet Lengths
rfc2440b03> [snip]
rfc2440b03>    The meaning of the length-type in old-format packets is:
rfc2440b03>    3 - The packet is of indeterminate length.  The header is 1 octet
rfc2440b03>        long, and the implementation must determine how long the packet
rfc2440b03>        is. If the packet is in a file, this means that the packet
rfc2440b03>        extends until the end of the file. In general, an implementation
rfc2440b03>        SHOULD NOT use indeterminate length packets except where the end
rfc2440b03>        of the data will be clear from the context,

it does not talks about compression,
so I think it should be the same for any packet type

rfc2440b03> 4.2.3. Packet Length Examples
rfc2440b03> [snip]
rfc2440b03>    An implementation MAY use Partial Body Lengths for data packets, be
                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
rfc2440b03>    they literal, compressed, or encrypted. The first partial length
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
rfc2440b03>    MUST be at least 512 octets long. Partial Body Lengths MUST NOT be
rfc2440b03>    used for any other packet types.

so it is ok for all data packets..

rfc1991> 4.1  Packet structure fields
rfc1991> [snip]
rfc1991>       11 - no packet length supplied, unknown packet length
rfc1991> [snip]
rfc1991>    A value of 11 is currently used in one place: on compressed data.
rfc1991>    That is, a compressed data block currently looks like <A3 01 . .  .>,
rfc1991>    where <A3>, binary 10 1000 11, is an indefinite-length packet. The
rfc1991>    proper interpretation is "until the end of the enclosing structure",
rfc1991>    although it should never appear outermost (where the enclosing
rfc1991>    structure is a file).

'currently used in one place' is not the same as 'MUST/SHOULD be used in one place'.
so I think it's ok to use 'unknown packet length' for other than compressed packets

but gpg implements this different way than in RFC1991 and RFC2440:

doc\DETAILS> Packet Headers
doc\DETAILS> [snip]
doc\DETAILS> +  It works like this: After the CTB (with a length field of 11) a
doc\DETAILS> +  marker field is used, which gives the length of the following datablock.
doc\DETAILS> +  This is a simple 2 byte field (MSB first) containing the amount of data
doc\DETAILS> +  following this field, not including this length field. After this datablock
doc\DETAILS> +  another length field follows, which gives the size of the next datablock.
doc\DETAILS> +  A value of 0 indicates the end of the packet. The maximum size of a
doc\DETAILS> +  data block is limited to 65534, thereby reserving a value of 0xffff for
doc\DETAILS> +  future extensions.

other interoperability problem is that gpg puts
signature after the data packet, pgp expect it before..
I think it is because gpg wants to do all in
one pass without seeking or using temporary files.

__
Disastry  http://disastry.dhs.org/
http://disastry.dhs.org/pgp <----PGP plugins for Netscape and MDaemon
 ^--GPG for Win32 (supports loadable modules and IDEA)
 ^----PGP 2.6.3ia-multi05 (supports IDEA, CAST5, BLOWFISH, TWOFISH,
      AES, 3DES ciphers and MD5, SHA1, RIPEMD160, SHA2 hashes)

From: "vedaal" <[email-masked]>
To: <[email-masked]>
Subject: Re: Parser abilities, and MDCs (Re: pointers to openpgp-interop knowledge base?)
Date: Wed, 7 Nov 2001 13:09:37 -0500
Sender: [email-masked]

----- Original Message -----
From: "Werner Koch" <[email-masked]>
To: "Michael Young" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, November 07, 2001 3:10 AM
Subject: Re: Parser abilities, and MDCs (Re: pointers to openpgp-interop
knowledge base?)

>
> On Tue, 6 Nov 2001 23:17:56 -0500, Michael Young said:
>
> > answer.  The issue was that GnuPG used an old-style indeterminate-length
> > packet for the plaintext before the MDC (see my message of August 23
>
> But only if the plaintext is a compressed packet - right?
>
>   Werner
----- Original Message -----
From: "Werner Koch" <[email-masked]>
To: "Michael Young" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, November 07, 2001 3:10 AM
Subject: Re: Parser abilities, and MDCs (Re: pointers to openpgp-interop
knowledge base?)

>
> On Tue, 6 Nov 2001 23:17:56 -0500, Michael Young said:
>
> > answer.  The issue was that GnuPG used an old-style indeterminate-length
> > packet for the plaintext before the MDC (see my message of August 23
>
> But only if the plaintext is a compressed packet - right?
>
>   Werner

here is the url for the pgpdump web interface:
http://xdv.org/pgpdump/

here is the output for a message encrypted to an rsa key using gpg with
twofish as the algorithm:

PGPdump Results
Old: Public-Key Encrypted Session Key Packet(tag 1)(268 bytes)
New version(3) Key ID - f1 56 64 88 f7 7a ff 7b
Pub alg - RSA Encrypt or Sign(pub 1) RSA m^e mod n(2047 bits) -
78 02 54 44 fd 0b ec 0d 44 de 38 f8 95 f4 8d 89 0a 92 4a 47 4e f8 84 55 38
47 24 1a 3e 91 36 9f 72 32 21 54 43
f5 8b 4f be 1d ce 4c ec ac 87 89 85 f0 ae 2c a7 48 c8 e0 31 aa 42 88 68 41
51 56 84 6b bc 0a a1 9d 50 9b f8 7b 35 96 82 d7 9b 77 e6 95 b1 83 77 13 f2
bb c1 0b 28 9a e8 f9 ac 09 10 8d 93 84 92 5b 95 8c 7a a9 43 44 6d 38 a7 40
46 ef a6 86 2c bc 1c ae 2b 27 0d 48 34 d9 c3 89 d3 7b ef a9 b3 b7 dd 9d 87
80 30 26 8f b1 0d a6 a7 ba d0 aa 6c 3e 76 6d 82 ac 72 88 14 eb 90 8f 8e b8
29 bf ed 5a 07 46 93 02 ae 0e d4 46 3f df 6d 29 6b 70 70 a6 20 8a 95 83 4c
dc 7e 69 e9 69 56 a1 a6 8d fd ab 79 38 1d 93 da b8 1f d1 78 84 84 7b 48 74
d8 66 94 64 5d 8a 88 61 fb 14 de ba 4e 33 1c 6f ba 84 70 02 28 11 4f 05 ba
7d 4f 2e c6 f4 92 7a 99 cc 5d e6 98 e3 4f 24 7c df f9 57
-> m = sym alg(1 byte) + checksum(2 bytes) + PKCS-1 block type 02
New: Symmetrically Encrypted and MDC Packet(tag 18)(70 bytes)
Ver 1 Encrypted data (plain text + MDC SHA1(20 bytes))

PGPdump Interface, Copyright (c) 2001, Stefan H. Holek, [email-masked]

is there any additional mdc information necessary/desirable to be displayed?

vedaal

Date: Wed, 7 Nov 2001 10:50:17 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Cc: John W Noerenberg II <[email-masked]>
Subject: Re: pointers to openpgp-interop knowledge base?
Mail-Followup-To: [email-masked], John W Noerenberg II <[email-masked]>
Sender: [email-masked]

On Tue, Nov 06, 2001 at 12:19:45PM -0800, Len Sassaman wrote:
> 
> On Mon, 5 Nov 2001, John  W Noerenberg II wrote:
> 
> > I've heard tell of similar programs, but I don't have particular
> > knowledge of any. --
> 
> GnuPG has such a parser built into it. Also, there's a perl script written
> by Mark E. Shoulson called pgpacket3.1 that tries to do the same thing.

The new (currently in test) GnuPG also comes with "gpgsplit" which
breaks OpenPGP messages into their constituent packets.  It's quite
handy for comparing the output of two different programs.

David

-- 
David Shaw          |  Technical Lead
<[email-masked]>  |  Enterprise Content Delivery
617-250-3028        |  Akamai Technologies

To: "Michael Young" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Parser abilities, and MDCs (Re: pointers to openpgp-interop knowledge base?)
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Wed, 07 Nov 2001 09:10:39 +0100
Lines: 13
Sender: [email-masked]

On Tue, 6 Nov 2001 23:17:56 -0500, Michael Young said:

> answer.  The issue was that GnuPG used an old-style indeterminate-length
> packet for the plaintext before the MDC (see my message of August 23

But only if the plaintext is a compressed packet - right?

  Werner

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

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Parser abilities, and MDCs (Re: pointers to openpgp-interop knowledge base?)
Date: Tue, 6 Nov 2001 23:17:56 -0500
Sender: [email-masked]

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

> using the pgp dump web interface,  it identified the message as using mdc
> packets, [also as expected], but listed the algorithm as 1  {a 'default '
> listing for 'idea' once an  rsa key is identified, even though 'idea' was
> not used?}

The algorithm identifier lives in material encrypted under the public key.
Without the private key, all the parser could do is guess.  (Does this
parser have the ability to decrypt the contents even if the unprotected
private key were present?)

The MDC packet itself is encrypted under the session key.  Again, the
parser wouldn't be able to verify it.  When you say it "identified the
message
as using mdc packets", I presume you mean that it noted that a
"symmetrically encrypted integrity protected data packet" (tag 18)
was present at the beginning, not that there was a valid MDC packet, right?

On that note, I've asked a couple of times about the way GnuPG
generates these packets, but I have never seen an authoritative
answer.  The issue was that GnuPG used an old-style indeterminate-length
packet for the plaintext before the MDC (see my message of August 23
and any followup discussion for details).  Should this be legal?

Date: Wed, 07 Nov 2001 10:43:58 +0900 (JST)
To: [email-masked]
Cc: [email-masked]
Subject: Re: pointers to openpgp-interop knowledge base?
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[email-masked]>
Sender: [email-masked]

From: "vedaal" <[email-masked]>
Subject: Re: pointers to openpgp-interop knowledge base?

> using the pgp dump web interface,  it identified the message as using mdc
> packets, [also as expected], but listed the algorithm as 1  {a 'default '
> listing for 'idea' once an  rsa key is identified, even though 'idea' was
> not used?}

Please send such a report directly to me, not to the entire list.

Please send me a sample packet which causes your problem. I will fix it if
it's a bug.

--Kazu

Date: Tue, 6 Nov 2001 12:19:45 -0800 (PST)
From: Len Sassaman <[email-masked]>
To: John  W Noerenberg II <[email-masked]>
cc: <[email-masked]>
Subject: Re: pointers to openpgp-interop knowledge base?
Sender: [email-masked]

On Mon, 5 Nov 2001, John  W Noerenberg II wrote:

> I've heard tell of similar programs, but I don't have particular
> knowledge of any. --

GnuPG has such a parser built into it. Also, there's a perl script written
by Mark E. Shoulson called pgpacket3.1 that tries to do the same thing.

From: "vedaal" <[email-masked]>
To: <[email-masked]>
Subject: Re: pointers to openpgp-interop knowledge base?
Date: Tue, 6 Nov 2001 14:33:41 -0500
Sender: [email-masked]

----- Original Message -----
From: "Kazu Yamamoto (????)" <[email-masked]>
To: <[email-masked]>
Sent: Monday, November 05, 2001 11:24 PM
Subject: Re: pointers to openpgp-interop knowledge base?

> Another PGP parser can be found:
> http://pgp.iijlab.net/pgpdump.html
>
> Web interface is also available.
>
> --Kazu

have tried the web interface, with a peculiar result:

encrypted a message to an rsa key using gpg with the preference set to
twofish,

decrypting with gpg showed algorithm 10, as expected.

using the pgp dump web interface,  it identified the message as using mdc
packets, [also as expected], but listed the algorithm as 1  {a 'default '
listing for 'idea' once an  rsa key is identified, even though 'idea' was
not used?}

is this just the web interface, or does the parser do this too?

vedaal

Date: Tue, 06 Nov 2001 13:24:24 +0900 (JST)
To: [email-masked]
Subject: Re: pointers to openpgp-interop knowledge base?
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[email-masked]>
Sender: [email-masked]

From: John W Noerenberg II <[email-masked]>
Subject: Re: pointers to openpgp-interop knowledge base?

> I have a program to contribute which will read openpgp files and 
> report on their structure.  John Callas wrote the original version, 
> and I've been updating it for 2440.  It's not a complete 
> implementation of 2440.  But it locates packet boundaries, identifies 
> packet types, and describes the plaintext portions of packets.

Another PGP parser can be found:
	http://pgp.iijlab.net/pgpdump.html

Web interface is also available.

--Kazu

Date: Mon, 5 Nov 2001 12:45:33 -0800
To: Len Sassaman <[email-masked]>
From: John  W Noerenberg II <[email-masked]>
Subject: Re: pointers to openpgp-interop knowledge base?
Cc: <[email-masked]>
Sender: [email-masked]

At 12:29 PM -0800 11/4/01, Len Sassaman wrote:
>
>I could keep throwing things off the top of my head -- but shouldn't we
>have some formal system for listing all of this?

Yes.

Both Brian Smith and John Kane have volunteered to maintain the 
information.  I've asked them to collaborate on maintaining the 
pages.  My preference is we set something up under openpgp.org site. 
openpgp.org is a computer at Phil Zimmermann's house.  There's other 
stuff I would like to see there, but interoperability info would be a 
Real Good Thing to get 2440 to DRAFT.

I have a program to contribute which will read openpgp files and 
report on their structure.  John Callas wrote the original version, 
and I've been updating it for 2440.  It's not a complete 
implementation of 2440.  But it locates packet boundaries, identifies 
packet types, and describes the plaintext portions of packets.

If people send me files, I'll run them through my parser, and tell 
you what happens.  The program runs on my Mac, but should be 
reasonably portable to other systems.  I'll publish it on 
openpgp.org, as soon as we make a suitable place.  I've heard tell of 
similar programs, but I don't have particular knowledge of any.
-- 

john noerenberg
[email-masked]
   ----------------------------------------------------------------------
   While the belief we  have found the Answer can separate us
   and make us forget our humanity, it is the seeking that continues
   to bring us together, the makes and keeps us human.
   -- Daniel J. Boorstin, "The Seekers", 1998
   ----------------------------------------------------------------------

Date: Mon, 05 Nov 2001 11:21:57 +0200
From: [email-masked]
Organization: disastry.NO.SPaM.NET
To: [email-masked]
Subject: Re: pointers to openpgp-interop knowledge base?
Sender: [email-masked]

Len Sassamanwrote:
> 
> GnuPG of any version produces messages signed with v3 keys encrypted in v3
> format that PGP cannot decrypt.

except PGP 2.6.3ia-multi05,
I modified it so that it can decrypt/verify these GnuPG produced non OpenPGP compliant messages.

> In the implementation nits, it is noted that PGP 5.x cannot verify v4 sigs
> on non-v4 material. Actually, 6.x cannot either, but 7.x and greater can.

even PGP 7.x have problems with v4 sigs.
it can verify v4 clearsignatures and detached signatures but not one pass signatures.

PGP 6.5.8ckt06 can verify all v4 signatures.

> Then there's the ElGamal signing-keys that GnuPG generates. I don't know
> what else supports them.

PGP 6.5.8ckt06 does.

__
Disastry  http://disastry.dhs.org/
http://disastry.dhs.org/pgp <----PGP plugins for Netscape and MDaemon
 ^--GPG for Win32 (supports loadable modules and IDEA)
 ^----PGP 2.6.3ia-multi05 (supports IDEA, CAST5, BLOWFISH, TWOFISH,
      AES, 3DES ciphers and MD5, SHA1, RIPEMD160, SHA2 hashes)

Date: Sun, 4 Nov 2001 12:29:25 -0800 (PST)
From: Len Sassaman <[email-masked]>
To: <[email-masked]>
Subject: Re: pointers to openpgp-interop knowledge base?
Sender: [email-masked]

On Sun, 4 Nov 2001, vedaal wrote:

> messages from any pgp version can be read and verified by gpg {with the
> idea plugin},
> except if a shared key/split key system is used
> [gpg can encrypt to a split key, but not sign or decrypt with a shared key
> system]
>
> messages from gpg using the throw-key id switch, cannot be read by 'any'
> version
> of pgp {except for Disastry's 2.6.3i multi 5}
>
> messages from gpg using mdc, cannot be read by any pgp version prior to
> 7.xx
> {6.5.8ckt is an exception, having a patch to ignore the mdc packets}
>
> messages from 7.xx using twofish or aes, cannot be decrypted by pgp
> versions prior
> to 7.xx, but signatures can be verified
> {again, 6.5.8ckt is an exception}
>
> messages using an RSA v4 key, can be decrypted, and can be verified, by pgp
> versions
> prior to 7.xx, but, for some reason, not, if the message is 'both' signed
> and encrypted
>
> messages signed with ripemd-160 or sha-1, can be verified by all pgp
> versions greater
> than 2.6.x, even if they do not use them to sign with for a particular key
> type
>
>
> hope this is useful,
>
> please correct if there are any mistakes or oversights,

Well, you've left out GnuPG versions. GnuPG hasn't always been able to
handle everything you mention.

GnuPG of any version produces messages signed with v3 keys encrypted in v3
format that PGP cannot decrypt.

In the implementation nits, it is noted that PGP 5.x cannot verify v4 sigs
on non-v4 material. Actually, 6.x cannot either, but 7.x and greater can.

Then there's the ElGamal signing-keys that GnuPG generates. I don't know
what else supports them.

Also, signing subkeys are probably a problem with a lot of other
implementations as well.

We have no idea what Hushmail's interop status is, since there appears to
be no way to either get access to Hushmail users' public keys in order to
verify their signatures, or import non-Hushmail users' keys into the
Hushmail system to encrypt to them.

...etc.

I could keep throwing things off the top of my head -- but shouldn't we
have some formal system for listing all of this?

--

Len Sassaman

Security Architect            |  "Now it's all change --
Technology Consultant         |   It's got to change more."
                              |
http://sion.quickie.net       |              --Joe Jackson

From: "vedaal" <[email-masked]>
To: <[email-masked]>
Subject: Re: pointers to openpgp-interop knowledge base?
Date: Sun, 4 Nov 2001 12:07:00 -0500
Sender: [email-masked]

- ----- Original Message ----- 
From: "Peter Gutmann" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Sunday, November 04, 2001 9:22 AM
Subject: Re: pointers to openpgp-interop knowledge base?

> I've found that just using the various options of PGP 5.0 (which is
> not-quite- OpenPGP), 6.5.x, and GPG will give you all the quirks and
> peculiarities you need.  Once you've made sure you can read what they
> produce, you should also check that they can read what you produce.
> 
> Peter.

short summary of intercompatibility, and incompatibilities:

messages from any pgp version can be read and verified by gpg {with the
idea plugin},
except if a shared key/split key system is used
[gpg can encrypt to a split key, but not sign or decrypt with a shared key
system]

messages from gpg using the throw-key id switch, cannot be read by 'any'
version
of pgp {except for Disastry's 2.6.3i multi 5}

messages from gpg using mdc, cannot be read by any pgp version prior to
7.xx
{6.5.8ckt is an exception, having a patch to ignore the mdc packets}

messages from 7.xx using twofish or aes, cannot be decrypted by pgp
versions prior
to 7.xx, but signatures can be verified
{again, 6.5.8ckt is an exception}

messages using an RSA v4 key, can be decrypted, and can be verified, by pgp
versions
prior to 7.xx, but, for some reason, not, if the message is 'both' signed
and encrypted

messages signed with ripemd-160 or sha-1, can be verified by all pgp
versions greater
than 2.6.x, even if they do not use them to sign with for a particular key
type

hope this is useful,

please correct if there are any mistakes or oversights,

thanks,

vedaal

Date: Mon, 5 Nov 2001 03:22:41 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re:  pointers to openpgp-interop knowledge base?
Sender: [email-masked]

John J Kane <[email-masked]> wrote:
>Are there any sources online for the following?
>
>  * contact info for people involved in interop testing
>  * examples of non-conformant output (for testing)
>  * examples of conformant output which have been documented to break certain
>    implementations

I've found that just using the various options of PGP 5.0 (which is not-quite-
OpenPGP), 6.5.x, and GPG will give you all the quirks and peculiarities you
need.  Once you've made sure you can read what they produce, you should also
check that they can read what you produce.

Peter.

From: Brian Smith <[email-masked]>
To: "'John J Kane'" <[email-masked]>, [email-masked]
Subject: RE: pointers to openpgp-interop knowledge base?
Date: Sun, 4 Nov 2001 00:47:51 -0000 
Sender: [email-masked]

http://www.openpgp.org/technical/interoperability/

However, the information there is pretty limited.  If anyone has
contributions of the types described below, send them to me and I'll see
that they're added to the site.

Brian Smith
Hush Communications

>  -----Original Message-----
> From: 	John J Kane [mailto:[email-masked]] 
> Sent:	03 November 2001 18:06
> To:	[email-masked]
> Subject:	pointers to openpgp-interop knowledge base?
> 
> ________________________________________________________
> 
> This message has NOT been ENCRYPTED and has NOT been SIGNED
> ________________________________________________________
> 
> 
> Are there any sources online for the following?
> 
>   * contact info for people involved in interop testing
>   * examples of non-conformant output (for testing)
>   * examples of conformant output which have been
>     documented to break certain implementations
> 
> Should a page be set up to host this information?
> 
> --
> JJK
> 
> 

Date: Sat, 03 Nov 2001 13:06:12 -0500
From: John J Kane <[email-masked]>
To: [email-masked]
Subject: pointers to openpgp-interop knowledge base?
Sender: [email-masked]

Are there any sources online for the following?

  * contact info for people involved in interop testing
  * examples of non-conformant output (for testing)
  * examples of conformant output which have been
    documented to break certain implementations

Should a page be set up to host this information?

--
JJK