Subject: PGP Partitioned Encoding Format

From: [email-masked] ("Hal Finney")
Date: Mon, 28 Feb 2005 15:35:57 -0800 (PST)

A few weeks ago I sent a message describing PGP Corporation's new
notation packet, used to distinguish PGP-MIME support from the legacy
"partitioned" format.  I got some feedback from that, but I need to make
it clear that this is an informative comment and that PGP is using its
own private namespace for notation packets.  PGP is trying to "play nice"
by using this namespace and not the global namespace which the working
group manages.

PGP-MIME is well documented but the partitioned format used by earlier
versions of PGP has not been clearly described.  I am providing more
detailed documentation of the partitioned format which has been used by
previous and current versions of PGP software in this message.  The new
notation packet can be used to indicate support for this partitioned
format and/or for PGP-MIME.

Hal Finney
PGP Corporation

======================================================================

PGP Partitioned Encoding Format Technote

Copyright 2004-2005 PGP Corporation
All Rights Reserved

Introduction

"Partitioned Encoding" refers generally to the way PGP software
encrypted email in the days before the PGP/MIME specification. No
equivalent specification exists for messages encoded with PGP software
from that era. Partitioned Encoding is a term given to the evolved form
of this method of encoding. The primary goals of all additions to the
Partitioned Encoding format are backwards compatibility and email client
compatibility. Whereas PGP/MIME represents "correct" Internet standard
behavior resulting in efficient but potentially incompatible behavior,
Partitioned Encoding holds as its only goal the ability for all that
came before to decrypt the format either automatically or manually. This
document describes the general format of such messages and details a
few special cases.

Although the preferred encoding for new messages is PGP/MIME, Partitioned
Encoding is still in use, and in some scenarios is the most desirable
format. Because all PGP software can decrypt Partitioned Encoding
messages, this format is the best choice when backward compatibility is
important. Partitioned encoding has evolved over the years, the dialect
described here is the format used by current PGP products (PGP Universal).

One other example where Partitioned Encoding is often the best encoding to
use is when sending PGP email to mobile devices. Because the two primary
standard formats for secure email, PGP/MIME and S/MIME, encrypt the entire
body of an email including attachments as one part, a mobile device is
prevented from downloading only specific segments of the message which
can be very desirable in low-bandwidth scenarios.

Partitioned Encoding Overview

Each MIME part of a message is processed individually resulting in an
encoded MIME message much like the original but with encrypted/signed
content. The overall structure of a message is generally retained. A
text message with three attachments encrypts to an encrypted text message
with three encrypted attachments. An email follows Partitioned Encoding
via the following algorithm:

For every MIME part in a message, starting with the first:
  If the part is a multipart container:
    recursively encode the sub-parts.
  For all other part types>
    If the part is text/plain
      encrypt/sign the part.
    If the part is binary or a text type other than plain:
      encrypt/sign the part as an attachment
      when encrypting, headers are X- prefixed to prevent mail clients from interpreting them
      when clear signing, corresponding <filename>.sig attachments are created

Each of these steps is further described below, with examples. For sake
of simplicity, not shown above is the special handling for the "Outlook
Plugin" dialect of Partitioned Encoding. This format is covered in a
separate section, below.

Example 1 shows a simple RFC-822 message and the resulting messages
after signing and encrypting. The straight-forward method used to encode
the email should be apparent. In both instances, the message content is
replaced by the PGP SDK output.

Example 1.  A simple message

> To: [email-masked]
> From: Damon Cokenias <[email-masked]>
> Subject: Simple Message
> Date: Mon, 1 Nov 2004 16:21:00 -0800
>
> Soylent Green is PEOPLE!

Signed

> To: [email-masked]
> From: Damon Cokenias <[email-masked]>
> Subject: Simple Message
> Date: Mon, 1 Nov 2004 16:21:00 -0800
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Soylent Green is PEOPLE!
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP Universal 1.2.2
>
> iQA/AwUBQYwc3wNUXR15SGMCEQJQfACfYFtobpQgt7/U2FTsHyiLOVQB6tgAni3T
> +Es5k0Bz4RGryRpM7CqxLqnw
> =LC7J
> -----END PGP SIGNATURE-----

Signed and Encrypted

> To: [email-masked]
> From: Damon Cokenias <[email-masked]>
> Subject: Simple Message
> Date: Mon, 1 Nov 2004 16:21:00 -0800
>
> -----BEGIN PGP MESSAGE-----
> Version: PGP Universal 1.2.2
>
> qANQR1DBwU4DjrZ+IglRIpQQB/4gPDVMliQnlJDeQmCiYe1iP56nZ476z0MB9vbI
> OP3z0lypOxJ871vh2EXf3EGITSkay+KdEY2CpSV2alqiBf21S5GS0llZ61IvDGo1
> gDyGiNGBkfNazAyNGYAYYkvNvjamPLmHfyqZqHEfCDDhqiIfXEIykUMImrFEHMsH
> UIvc1aPKxoaFsmzsSinIRYYSOZ/Gx29xXhrJhxJMXaSsnMp2Np/cOqcH6gK8wDrN
> FuurFRnW+up/O9iAw2moeOUqR2DocvRI7MJMkxArLCaGJL2zUxpIzRtedYlI8lRu
> ZE5ROP2rdinDnNf4JoI+2TMigA1R8GZiEKNcWIko+dQlMBqdB/4nghxYYW/PMm/B
> K47yrAqza8GxQEtzGDaOTsDioiH7bQThGG5qlna7odUTY4elHjNiT0qCHg0FCGZN
> iE+uIMBOBFFmZFzDOnmMtp9vuPLmI1+YpaHDfbwX3tQV3hdj2RFC2ofHB5Eh5Mzm
> 9T+5QPV9iUQDcDkus0/+3P/TPmtvAL/QB5WPUuNX7piZbsp7pvQn9BvT2i/ulZDn
> wPSoREhllnRjs3aTg5XrWkHFQ8I3QFfFhIVam9jHITwlAGkMmV7oK4flllAyK4Ui
> vJ+PsCVejuC1ZmSBbb97sw26+jSvr+PLO5ftvAi0FFb6Q2Dx1nYaE9UbAHX9JbC2
> 0qneMzIS0lYBjO7LVgoBDD4ayRqwAuu3RXqAzm02/JSpsIbD5Gr3bcLdvdKVCrCT
> IsCV2QEMYx4wiy3HjarYEO+z5Pztwcdx7PiTF8GAvMyfhmVxBpdqROM+Y6Jx0w==
> =JZf0
> -----END PGP MESSAGE-----

The second example, below, is more complex, showing a multipart message
composed of a text part and two binary attachments. Each MIME part
in the message is signed/encrypted separately. The text portion is
signed/encrypted exactly as in the first example. The binary attachments
get special treatment, however.

Signing/Encrypting Binary Parts

If the binary attachment being signed/encrypted does not have a filename,
it is given one. The attachment's name is "Attachment" + a number +
an extension. The number is a simple counter, starting at one, used to
ensure uniqueness. The extension is a three letter code inferred from
the part's MIME type. An anonymous binary attachment with Content-Type
of image/jpeg might be named "Attachment1.jpg", for example.

When a binary part is encrypted, the part's file name is hidden in
the encrypted data. The publicly-viewable name of an encrypted binary
part is always a generic name. Encrypted binary have a MIME type of
application/octet-stream. An encrypted part's headers are prefixed with
"X-Content-PGP-Universal-Saved-" to prevent them from being interpreted
by mail clients. When the part is decrypted, the process is reversed
and the original headers are reunited with the content. PGP products
before PGP Universal do not preserve these headers, but also generally
required manual opening of the attachments to decrypt them and thus no
functionality is lost for those scenarios.

When a binary part is clear-signed, a new attachment is created
to hold the signature. The MIME type of this attachment is
application/octet-stream. The signature attachment has the same name
as the signed part with ".sig" appended. These "detached signatures"
are base64 encoded.

Example 2.  A more complex message

> Mime-Version: 1.0
> To: [email-masked]
> Content-Type: multipart/mixed;
> 	boundary="BOUNDARY-0000-1234"
> From: Damon Cokenias <[email-masked]>
> Subject: New Products
> Date: Mon, 1 Nov 2004 16:01:00 -0700
>
> --BOUNDARY-0000-1234
> Content-Transfer-Encoding: 7bit
> Content-Type: text/plain;
> 	charset=US-ASCII
>
> All,
>
> Marketing materials for our new product line are enclosed. Please have
> feedback ready by Thursday lunch!
>
> --BOUNDARY-0000-1234
> Content-Transfer-Encoding: base64
> Content-Type: image/gif;
> 	x-unix-mode=0644;
> 	name="soylent-beige.gif"
> Content-Disposition: inline;
> 	filename=soylent-beige.gif
>
> R0lGODlhDgAZAOZ9AF6pzm2x02yx02Ks0GOs0Gqw0kadx7LW6HCz1HS11Weu0dvs9EGaxrTX6dLn
> 8ValzFmnzVemzE6hylimzXe31kedx12pzk+hykufyW+y01Kjy0ygydTo8t3t9XK01FSky9jq83G0
> 1InA23i31luozkmeyGiv0czk8KTP5NDm8VqnzXO11fb6/PX6/HK01aDM4vL4+8Le7I7D3UugyaPO
>
>           .       .       .    (cut)     .       .       .       
>
> a40HBBk0LIYtewYMTllgQxU+hCIXGAZwT1JBfHZkgwMfZhtbQHNpOEU8gxYQL18bXDo9Am1hxgBe
> Dz9JJXUIUTuDCgRWVw8aEkwJDCmDAiYHRiQRchcUBkeDlgRoIKYLngkflMxwMIhDDgcFmoiYdscN
> mkJVMhQgMgAAog4JENhQ93HEFCH2EIEIMOJMiACIOKgoACWOB0Q1KkSQwYYCojF5UMRooKZRo0AA
> Ow==
>
> --BOUNDARY-0000-1234
> Content-Transfer-Encoding: base64
> Content-Type: image/gif;
> 	x-unix-mode=0644;
> 	name="soylent-taupe.gif"
> Content-Disposition: inline;
> 	filename=soylent-taupe.gif
>
> R0lGODlhDgAZAOZ9AF6pzm2x02yx02Ks0GOs0Gqw0kadx7LW6HCz1HS11Weu0dvs9EGaxrTX6dLn
> 8ValzFmnzVemzE6hylimzXe31kedx12pzk+hykufyW+y01Kjy0ygydTo8t3t9XK01FSky9jq83G0
> 1InA23i31luozkmeyGiv0czk8KTP5NDm8VqnzXO11fb6/PX6/HK01aDM4vL4+8Le7I7D3UugyaPO
>
>           .       .       .    (cut)     .       .       .       
>
> a40HBBk0LIYtewYMTllgQxU+hCIXGAZwT1JBfHZkgwMfZhtbQHNpOEU8gxYQL18bXDo9Am1hxgBe
> Dz9JJXUIUTuDCgRWVw8aEkwJDCmDAiYHRiQRchcUBkeDlgRoIKYLngkflMxwMIhDDgcFmoiYdscN
> mkJVMhQgMgAAog4JENhQ93HEFCH2EIEIMOJMiACIOKgoACWOB0Q1KkSQwYYCojF5UMRooKZRo0AA
> Ow==
>
> --BOUNDARY-0000-1234--

Signed

> Mime-Version: 1.0
> To: [email-masked]
> Content-Type: multipart/mixed;
> 	boundary="BOUNDARY-0000-1234"
> From: Damon Cokenias <[email-masked]>
> Subject: New Products
> Date: Mon, 1 Nov 2004 16:01:00 -0700
>
> --BOUNDARY-0000-1234
> Content-Transfer-Encoding: 7bit
> Content-Type: text/plain;
> 	charset=US-ASCII
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> All,
>
> Marketing materials for our new product line are enclosed. Please have
> feedback ready by Thursday lunch!
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP Universal 1.2.2
>
> iQA/AwUBQZEXQmMQlGdKg9VZEQLl6QCgwFM2xtYzN0mJWcK9eYkU0ejiUqsAoOr6esBx8e1X
> mGBERfNK9ff0adY7
> -----END PGP SIGNATURE-----
>
> --BOUNDARY-0000-1234
> Content-Transfer-Encoding: base64
> Content-Type: image/gif;
> 	x-unix-mode=0644;
> 	name="soylent-beige.gif"
> Content-Disposition: attachment;
> 	filename=soylent-beige.gif
>
> R0lGODlhDgAZAOZ9AF6pzm2x02yx02Ks0GOs0Gqw0kadx7LW6HCz1HS11Weu0dvs9EGaxrTX6dLn
> 8ValzFmnzVemzE6hylimzXe31kedx12pzk+hykufyW+y01Kjy0ygydTo8t3t9XK01FSky9jq83G0
> 1InA23i31luozkmeyGiv0czk8KTP5NDm8VqnzXO11fb6/PX6/HK01aDM4vL4+8Le7I7D3UugyaPO
>
>           .       .       .    (cut)     .       .       .       
>
> a40HBBk0LIYtewYMTllgQxU+hCIXGAZwT1JBfHZkgwMfZhtbQHNpOEU8gxYQL18bXDo9Am1hxgBe
> Dz9JJXUIUTuDCgRWVw8aEkwJDCmDAiYHRiQRchcUBkeDlgRoIKYLngkflMxwMIhDDgcFmoiYdscN
> mkJVMhQgMgAAog4JENhQ93HEFCH2EIEIMOJMiACIOKgoACWOB0Q1KkSQwYYCojF5UMRooKZRo0AA
> Ow==
>
> --BOUNDARY-0000-1234
> Content-Transfer-Encoding: base64
> Content-Type: image/gif;
> 	x-unix-mode=0644;
> 	name="soylent-taupe.gif"
> Content-Disposition: attachment;
> 	filename=soylent-taupe.gif
>
> R0lGODlhDgAZAOZ9AF6pzm2x02yx02Ks0GOs0Gqw0kadx7LW6HCz1HS11Weu0dvs9EGaxrTX6dLn
> 8ValzFmnzVemzE6hylimzXe31kedx12pzk+hykufyW+y01Kjy0ygydTo8t3t9XK01FSky9jq83G0
>
>           .       .       .    (cut)     .       .       .       
>
> Dz9JJXUIUTuDCgRWVw8aEkwJDCmDAiYHRiQRchcUBkeDlgRoIKYLngkflMxwMIhDDgcFmoiYdscN
> mkJVMhQgMgAAog4JENhQ93HEFCH2EIEIMOJMiACIOKgoACWOB0Q1KkSQwYYCojF5UMRooKZRo0AA
> Ow==
>
> --BOUNDARY-0000-1234
> Content-Type: application/octet-stream;
> 	name="soylent-beige.gif.sig"
> Content-Disposition: attachment;
> 	filename="soylent-beige.gif.sig"
> Content-Transfer-Encoding: base64
>
> iQA/AwUAQZEXQmMQlGdKg9VZEQKnbgCg5dMjmJEnqAHpUrCKP/Xu8pB8JCgAn2shn2AKp913
> HAJt+LwN0AdtSDn3
> --BOUNDARY-0000-1234
> Content-Type: application/octet-stream;
> 	name="soylent-taupe.gif.sig"
> Content-Disposition: attachment;
> 	filename="soylent-taupe.gif.sig"
> Content-Transfer-Encoding: base64
>
> iQA/AwUAQZEXQmMQlGdKg9VZEQKnbgCg5BusKlATEhfNiRbGhSlrUYlbPg4AnRLoX03Vo48H
> NoWukVfqSGyiQFV+
> --BOUNDARY-0000-1234--

Signed and Encrypted

> Mime-Version: 1.0
> To: [email-masked]
> Content-Type: multipart/mixed;
> 	boundary="BOUNDARY-0000-1234"
> From: Damon Cokenias <[email-masked]>
> Subject: New Products
> Date: Mon, 1 Nov 2004 16:01:00 -0700
>
> --BOUNDARY-0000-1234
> Content-Transfer-Encoding: 7bit
> Content-Type: text/plain;
> 	charset=US-ASCII
>
> -----BEGIN PGP MESSAGE-----
> Version: 0
>
> qANQR1DBwEwD42FWyEinTuQBB/wKGj60HNiMWCFZckprmNCIFSkfD0ZpRyYg0L65
> bbydP5KnPo266C5CEy4T11E2Xp11tMh6WjvRqalV8FDONpFLhV89k2JvX+rQ6W+o
> nbd5cW5XiflO2+5t/IlMdzSrdpr2Wn9GgZss0T/5FA7E1ayj2SNjffIVfKuXHDEk
>
>           .       .       .    (cut)     .       .       .       
>
> Td3A+VZ7VWkJPQKruA+IMnShEUsaFcfVSkpylSzwrcL1g5M7We1LGHgtGXT/ejJ0
> H3FeNtDw97dsmcc9oNFOHqwvQPt+h5dQfi3fGsT8Lw45VAePRjezZOn1zfVlf3Rc
> idkUaO2aW9A=
> =RqCL
> -----END PGP MESSAGE-----
>
> --BOUNDARY-0000-1234
> X-Content-PGP-Universal-Saved-Content-Disposition: inline;
>         filename="Attachment1.pgp"
> X-Content-PGP-Universal-Saved-Content-Type: image/gif;
>         x-unix-mode=0644;
>         name="Attachment1.pgp"
> X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: base64
> Content-Type: application/octet-stream;
>         name="Attachment1.pgp"
> Content-Disposition: attachment;
>         filename="Attachment1.pgp"
>
> -----BEGIN PGP MESSAGE-----
> Version: 0
>
> qANQR1DBwEwD42FWyEinTuQBB/9yRpLW7rIulg2VxJTZps+MghHEaBptaYfA24Rf
> RvGv0y0xQDEpFYB5BY4BBbgUK+124K4c4ulaMGRMqsbqwTtzedUvqzuWEIqLdrhE
> 437c3hev2b3MiG/gVLz07O9S0FgZ1GxzTywWiCJSNIO1pKSRXN1BwDD2Yy7MLh9m
> 4uxYZzMMr0QTonzf1RoDCWm0tPL8n2sSR4D96yw+c0+FaFmPUEWtdHl43D1n752Y
>
>           .       .       .    (cut)     .       .       .       
>
> 1p5271ir9IBuQnHGd9azBhAxV+MndAcwhW006FF0H2Aw1DUWwJGA8ebXyVs8/Lp+
> nQYVAc88tl6seKo3dPCMGlTaBbVbmSHoqJadhqf6zl5+6nnFAlT31UmPlfOz
> =h4y5
> -----END PGP MESSAGE-----
>
> --BOUNDARY-0000-1234
> X-Content-PGP-Universal-Saved-Content-Disposition: inline;
>         filename="Attachment2.pgp"
> X-Content-PGP-Universal-Saved-Content-Type: image/gif;
>         x-unix-mode=0644;
>         name="Attachment2.pgp"
> X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: base64
> Content-Type: application/octet-stream;
>         name="Attachment2.pgp"
> Content-Disposition: attachment;
>         filename="Attachment2.pgp"
>
> -----BEGIN PGP MESSAGE-----
> Version: 0
>
> qANQR1DBwEwD42FWyEinTuQBB/0bA0TCswweIaDGLJXpTsrlMpEhCmNjGh53qeek
> /4r1XEwYPRVho/lUAaxtDNJ3mcAXekdlLxAtxdDRpypdRUz7yjPtcEB7P9wN8uWf
> 7AylCYd7ABvFmerenRZZ7Bc9TjHJWxnuoUWDsKlfeaOxqNgeiSZY4Q20HY0YZnTI
>
>           .       .       .    (cut)     .       .       .       
>
> D0urDVE2fFlpxjLPrPBrKf7wbo1+3ZUHjOgeElQTgChMOF5SgizEJlk2OLZoq/IO
> Ktu7v7jcQGPsKEyOC0Dzzhn33AeB06cU1sJV7gha6vrn0qfIXZQmGk3mzf4=
> =N7Wi
> -----END PGP MESSAGE-----
>
> --BOUNDARY-0000-1234--

HTML and RTF Encoding

PGP messages created by the PGP Plugin for Outlook (Windows) originally
defined a special attachment for storing HTML and RTF content for
compatibility purposes. PGP Universal has adopted this same formatting
for all HTML and RTF messages when using Partitioned Encoding. These
messages are readily identified by the presence of an attachment
called "PGPexch.htm.pgp", "PGPexch.htm.asc", "PGPexch.rtf.pgp" or
"PGPexch.rtf.asc". The attachment contains the encrypted RTF or HTML
portion of a multipart/alternative message.

This encoding should be used when signing/encrypting a
multipart/alternative message composed of exactly one plain text part and
one HTML part. Doing so ensures maximum compatibility for Windows users
with older PGP software. A multipart/alternative part with plain/html
subparts will become a multipart/mixed with an encrypted plain subpart
and an encrypted HTML attachment. A special header ("X-PGP-MIME-Structure:
alternative") is added to indicate this transformation was performed. This
header is not required for proper decoding.

When decrypting such messages, the "PGPexch.htm.pgp" or "PGPexch.htm.asc"
attachment will become the HTML alternative for the main body
text. Because RTF is not used for Internet mail, do not make RTF
attachments part of the message body. The RTF should be decrypted, but
should remain an attachment. The RTF attachment is useful only to Outlook.

Example 3.  A multipart/alternative message with html and text parts

> Mime-Version: 1.0
> To: [email-masked]
> From: Damon Cokenias <[email-masked]>
> Subject: Outlook Encoding
> Date: Mon, 1 Nov 2004 16:21:00 -0800
> Content-Type: multipart/alternative;
>      boundary="BOUNDARY-0000-1234"
>
> This is a multipart message in MIME format.
>
> --BOUNDARY-0000-1234
> Content-Type: text/plain
>
> Soylent Green is PEOPLE!
>
> --BOUNDARY-0000-1234
> Content-Type: text/html;
>         charset=US-ASCII
>
> <html><body bgcolor="black" text="green">
> Soylent Green is <b>PEOPLE!</b>
> </body></html>
>
> --BOUNDARY-0000-1234--

Signed and Encrypted

> Mime-Version: 1.0
> To: [email-masked]
> From: Damon Cokenias <[email-masked]>
> Subject: Outlook Encoding
> Date: Mon, 1 Nov 2004 16:21:00 -0800
> Content-Type: multipart/mixed;
> 	boundary="BOUNDARY-0000-1234"
>
> This is a multipart message in MIME format.
>
> --BOUNDARY-0000-1234
> Content-Type: text/plain;
> 	charset="us-ascii"
> Content-Transfer-Encoding: 7bit
>
> -----BEGIN PGP MESSAGE-----
> Version: 0
>
> qANQR1DBwEwD42FWyEinTuQBB/9KEBufHfz139ZuQCBushTxOenNzF5QzgqLkfTB
> h1a6y9XOfp1lox0Unx2s0cDcD1Vq2Ca/1kJvpYuPdnKyhwHSUZK9sE1RMSLM9sj/
> ng1FMHemyNb5NN+8T5jYFEE8KQlrNwpJfHXTgOkmeBrH749I2oHV/yhezYI9YqKI
>
>           .       .       .    (cut)     .       .       .       
>
> yIbvwHvS6HJeLjUylmRX+hplo2k/31JVg4b52z9Od3XEPptMYpvEKkpJUve6b3P2
> uLdxaT3vKep15UcdqitsbVVISxr6XZ+DZq4NKkrR73tt4eLhQlTWgZoYgac6QLuM
> Cg==
> =NOiI
> -----END PGP MESSAGE-----
>
> --BOUNDARY-0000-1234
> X-Content-PGP-Universal-Saved-Content-Type: text/html;
> 	charset=US-ASCII
> Content-Type: application/octet-stream;
> 	name="PGPexch.htm.pgp"
> Content-Disposition: attachment
> X-PGP-MIME-Structure: alternative
>
> -----BEGIN PGP MESSAGE-----
> Version: 0
>
> qANQR1DBwEwD42FWyEinTuQBB/467rWcjfuimgRk44ifIqog/CpjSlitDbv/T+Kr
> JZqgEBP5CxwiO8G/Bgf2PpYOz2iiTDRycfFgwOktmkBvAYSatipSCwAWJ/UPcXXA
> uqQEnKyq+tZIibE9fDrbzObvgIHbe2M7HofiobQ0UAVb3/KaQphRM2sJ0ATotIbp
>
>           .       .       .    (cut)     .       .       .       
>
> TjQiuNqJfYlyWUrPUg7dTeSdSOnIm/zqLVQxm/+NB9SWaY+G3eqqBg6M/ytNaUwd
> jjBHOHh+6wPfkegmWP/8wxI58n6SV9d5OQ==
> =aD+v
> -----END PGP MESSAGE-----
>
> --BOUNDARY-0000-1234--

References

RFC 2440 OpenPGP Message Format
RFC 3156 MIME Security with Pretty Good Privacy

To: [email-masked]
Subject: PGP Partitioned Encoding Format
Date: Mon, 28 Feb 2005 15:35:57 -0800 (PST)
From: [email-masked] ("Hal Finney")
Sender: [email-masked]

A few weeks ago I sent a message describing PGP Corporation's new
notation packet, used to distinguish PGP-MIME support from the legacy
"partitioned" format.  I got some feedback from that, but I need to make
it clear that this is an informative comment and that PGP is using its
own private namespace for notation packets.  PGP is trying to "play nice"
by using this namespace and not the global namespace which the working
group manages.

PGP-MIME is well documented but the partitioned format used by earlier
versions of PGP has not been clearly described.  I am providing more
detailed documentation of the partitioned format which has been used by
previous and current versions of PGP software in this message.  The new
notation packet can be used to indicate support for this partitioned
format and/or for PGP-MIME.

Hal Finney
PGP Corporation

======================================================================

PGP Partitioned Encoding Format Technote

Copyright 2004-2005 PGP Corporation
All Rights Reserved

Introduction

"Partitioned Encoding" refers generally to the way PGP software
encrypted email in the days before the PGP/MIME specification. No
equivalent specification exists for messages encoded with PGP software
from that era. Partitioned Encoding is a term given to the evolved form
of this method of encoding. The primary goals of all additions to the
Partitioned Encoding format are backwards compatibility and email client
compatibility. Whereas PGP/MIME represents "correct" Internet standard
behavior resulting in efficient but potentially incompatible behavior,
Partitioned Encoding holds as its only goal the ability for all that
came before to decrypt the format either automatically or manually. This
document describes the general format of such messages and details a
few special cases.

Although the preferred encoding for new messages is PGP/MIME, Partitioned
Encoding is still in use, and in some scenarios is the most desirable
format. Because all PGP software can decrypt Partitioned Encoding
messages, this format is the best choice when backward compatibility is
important. Partitioned encoding has evolved over the years, the dialect
described here is the format used by current PGP products (PGP Universal).

One other example where Partitioned Encoding is often the best encoding to
use is when sending PGP email to mobile devices. Because the two primary
standard formats for secure email, PGP/MIME and S/MIME, encrypt the entire
body of an email including attachments as one part, a mobile device is
prevented from downloading only specific segments of the message which
can be very desirable in low-bandwidth scenarios.

Partitioned Encoding Overview

Each MIME part of a message is processed individually resulting in an
encoded MIME message much like the original but with encrypted/signed
content. The overall structure of a message is generally retained. A
text message with three attachments encrypts to an encrypted text message
with three encrypted attachments. An email follows Partitioned Encoding
via the following algorithm:

For every MIME part in a message, starting with the first:
  If the part is a multipart container:
    recursively encode the sub-parts.
  For all other part types>
    If the part is text/plain
      encrypt/sign the part.
    If the part is binary or a text type other than plain:
      encrypt/sign the part as an attachment
      when encrypting, headers are X- prefixed to prevent mail clients from interpreting them
      when clear signing, corresponding <filename>.sig attachments are created

Each of these steps is further described below, with examples. For sake
of simplicity, not shown above is the special handling for the "Outlook
Plugin" dialect of Partitioned Encoding. This format is covered in a
separate section, below.

Example 1 shows a simple RFC-822 message and the resulting messages
after signing and encrypting. The straight-forward method used to encode
the email should be apparent. In both instances, the message content is
replaced by the PGP SDK output.

Example 1.  A simple message

> To: [email-masked]
> From: Damon Cokenias <[email-masked]>
> Subject: Simple Message
> Date: Mon, 1 Nov 2004 16:21:00 -0800
>
> Soylent Green is PEOPLE!

Signed

> To: [email-masked]
> From: Damon Cokenias <[email-masked]>
> Subject: Simple Message
> Date: Mon, 1 Nov 2004 16:21:00 -0800
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Soylent Green is PEOPLE!
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP Universal 1.2.2
>
> iQA/AwUBQYwc3wNUXR15SGMCEQJQfACfYFtobpQgt7/U2FTsHyiLOVQB6tgAni3T
> +Es5k0Bz4RGryRpM7CqxLqnw
> =LC7J
> -----END PGP SIGNATURE-----

Signed and Encrypted

> To: [email-masked]
> From: Damon Cokenias <[email-masked]>
> Subject: Simple Message
> Date: Mon, 1 Nov 2004 16:21:00 -0800
>
> -----BEGIN PGP MESSAGE-----
> Version: PGP Universal 1.2.2
>
> qANQR1DBwU4DjrZ+IglRIpQQB/4gPDVMliQnlJDeQmCiYe1iP56nZ476z0MB9vbI
> OP3z0lypOxJ871vh2EXf3EGITSkay+KdEY2CpSV2alqiBf21S5GS0llZ61IvDGo1
> gDyGiNGBkfNazAyNGYAYYkvNvjamPLmHfyqZqHEfCDDhqiIfXEIykUMImrFEHMsH
> UIvc1aPKxoaFsmzsSinIRYYSOZ/Gx29xXhrJhxJMXaSsnMp2Np/cOqcH6gK8wDrN
> FuurFRnW+up/O9iAw2moeOUqR2DocvRI7MJMkxArLCaGJL2zUxpIzRtedYlI8lRu
> ZE5ROP2rdinDnNf4JoI+2TMigA1R8GZiEKNcWIko+dQlMBqdB/4nghxYYW/PMm/B
> K47yrAqza8GxQEtzGDaOTsDioiH7bQThGG5qlna7odUTY4elHjNiT0qCHg0FCGZN
> iE+uIMBOBFFmZFzDOnmMtp9vuPLmI1+YpaHDfbwX3tQV3hdj2RFC2ofHB5Eh5Mzm
> 9T+5QPV9iUQDcDkus0/+3P/TPmtvAL/QB5WPUuNX7piZbsp7pvQn9BvT2i/ulZDn
> wPSoREhllnRjs3aTg5XrWkHFQ8I3QFfFhIVam9jHITwlAGkMmV7oK4flllAyK4Ui
> vJ+PsCVejuC1ZmSBbb97sw26+jSvr+PLO5ftvAi0FFb6Q2Dx1nYaE9UbAHX9JbC2
> 0qneMzIS0lYBjO7LVgoBDD4ayRqwAuu3RXqAzm02/JSpsIbD5Gr3bcLdvdKVCrCT
> IsCV2QEMYx4wiy3HjarYEO+z5Pztwcdx7PiTF8GAvMyfhmVxBpdqROM+Y6Jx0w==
> =JZf0
> -----END PGP MESSAGE-----

The second example, below, is more complex, showing a multipart message
composed of a text part and two binary attachments. Each MIME part
in the message is signed/encrypted separately. The text portion is
signed/encrypted exactly as in the first example. The binary attachments
get special treatment, however.

Signing/Encrypting Binary Parts

If the binary attachment being signed/encrypted does not have a filename,
it is given one. The attachment's name is "Attachment" + a number +
an extension. The number is a simple counter, starting at one, used to
ensure uniqueness. The extension is a three letter code inferred from
the part's MIME type. An anonymous binary attachment with Content-Type
of image/jpeg might be named "Attachment1.jpg", for example.

When a binary part is encrypted, the part's file name is hidden in
the encrypted data. The publicly-viewable name of an encrypted binary
part is always a generic name. Encrypted binary have a MIME type of
application/octet-stream. An encrypted part's headers are prefixed with
"X-Content-PGP-Universal-Saved-" to prevent them from being interpreted
by mail clients. When the part is decrypted, the process is reversed
and the original headers are reunited with the content. PGP products
before PGP Universal do not preserve these headers, but also generally
required manual opening of the attachments to decrypt them and thus no
functionality is lost for those scenarios.

When a binary part is clear-signed, a new attachment is created
to hold the signature. The MIME type of this attachment is
application/octet-stream. The signature attachment has the same name
as the signed part with ".sig" appended. These "detached signatures"
are base64 encoded.

Example 2.  A more complex message

> Mime-Version: 1.0
> To: [email-masked]
> Content-Type: multipart/mixed;
> 	boundary="BOUNDARY-0000-1234"
> From: Damon Cokenias <[email-masked]>
> Subject: New Products
> Date: Mon, 1 Nov 2004 16:01:00 -0700
>
> --BOUNDARY-0000-1234
> Content-Transfer-Encoding: 7bit
> Content-Type: text/plain;
> 	charset=US-ASCII
>
> All,
>
> Marketing materials for our new product line are enclosed. Please have
> feedback ready by Thursday lunch!
>
> --BOUNDARY-0000-1234
> Content-Transfer-Encoding: base64
> Content-Type: image/gif;
> 	x-unix-mode=0644;
> 	name="soylent-beige.gif"
> Content-Disposition: inline;
> 	filename=soylent-beige.gif
>
> R0lGODlhDgAZAOZ9AF6pzm2x02yx02Ks0GOs0Gqw0kadx7LW6HCz1HS11Weu0dvs9EGaxrTX6dLn
> 8ValzFmnzVemzE6hylimzXe31kedx12pzk+hykufyW+y01Kjy0ygydTo8t3t9XK01FSky9jq83G0
> 1InA23i31luozkmeyGiv0czk8KTP5NDm8VqnzXO11fb6/PX6/HK01aDM4vL4+8Le7I7D3UugyaPO
>
>           .       .       .    (cut)     .       .       .       
>
> a40HBBk0LIYtewYMTllgQxU+hCIXGAZwT1JBfHZkgwMfZhtbQHNpOEU8gxYQL18bXDo9Am1hxgBe
> Dz9JJXUIUTuDCgRWVw8aEkwJDCmDAiYHRiQRchcUBkeDlgRoIKYLngkflMxwMIhDDgcFmoiYdscN
> mkJVMhQgMgAAog4JENhQ93HEFCH2EIEIMOJMiACIOKgoACWOB0Q1KkSQwYYCojF5UMRooKZRo0AA
> Ow==
>
> --BOUNDARY-0000-1234
> Content-Transfer-Encoding: base64
> Content-Type: image/gif;
> 	x-unix-mode=0644;
> 	name="soylent-taupe.gif"
> Content-Disposition: inline;
> 	filename=soylent-taupe.gif
>
> R0lGODlhDgAZAOZ9AF6pzm2x02yx02Ks0GOs0Gqw0kadx7LW6HCz1HS11Weu0dvs9EGaxrTX6dLn
> 8ValzFmnzVemzE6hylimzXe31kedx12pzk+hykufyW+y01Kjy0ygydTo8t3t9XK01FSky9jq83G0
> 1InA23i31luozkmeyGiv0czk8KTP5NDm8VqnzXO11fb6/PX6/HK01aDM4vL4+8Le7I7D3UugyaPO
>
>           .       .       .    (cut)     .       .       .       
>
> a40HBBk0LIYtewYMTllgQxU+hCIXGAZwT1JBfHZkgwMfZhtbQHNpOEU8gxYQL18bXDo9Am1hxgBe
> Dz9JJXUIUTuDCgRWVw8aEkwJDCmDAiYHRiQRchcUBkeDlgRoIKYLngkflMxwMIhDDgcFmoiYdscN
> mkJVMhQgMgAAog4JENhQ93HEFCH2EIEIMOJMiACIOKgoACWOB0Q1KkSQwYYCojF5UMRooKZRo0AA
> Ow==
>
> --BOUNDARY-0000-1234--

Signed

> Mime-Version: 1.0
> To: [email-masked]
> Content-Type: multipart/mixed;
> 	boundary="BOUNDARY-0000-1234"
> From: Damon Cokenias <[email-masked]>
> Subject: New Products
> Date: Mon, 1 Nov 2004 16:01:00 -0700
>
> --BOUNDARY-0000-1234
> Content-Transfer-Encoding: 7bit
> Content-Type: text/plain;
> 	charset=US-ASCII
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> All,
>
> Marketing materials for our new product line are enclosed. Please have
> feedback ready by Thursday lunch!
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP Universal 1.2.2
>
> iQA/AwUBQZEXQmMQlGdKg9VZEQLl6QCgwFM2xtYzN0mJWcK9eYkU0ejiUqsAoOr6esBx8e1X
> mGBERfNK9ff0adY7
> -----END PGP SIGNATURE-----
>
> --BOUNDARY-0000-1234
> Content-Transfer-Encoding: base64
> Content-Type: image/gif;
> 	x-unix-mode=0644;
> 	name="soylent-beige.gif"
> Content-Disposition: attachment;
> 	filename=soylent-beige.gif
>
> R0lGODlhDgAZAOZ9AF6pzm2x02yx02Ks0GOs0Gqw0kadx7LW6HCz1HS11Weu0dvs9EGaxrTX6dLn
> 8ValzFmnzVemzE6hylimzXe31kedx12pzk+hykufyW+y01Kjy0ygydTo8t3t9XK01FSky9jq83G0
> 1InA23i31luozkmeyGiv0czk8KTP5NDm8VqnzXO11fb6/PX6/HK01aDM4vL4+8Le7I7D3UugyaPO
>
>           .       .       .    (cut)     .       .       .       
>
> a40HBBk0LIYtewYMTllgQxU+hCIXGAZwT1JBfHZkgwMfZhtbQHNpOEU8gxYQL18bXDo9Am1hxgBe
> Dz9JJXUIUTuDCgRWVw8aEkwJDCmDAiYHRiQRchcUBkeDlgRoIKYLngkflMxwMIhDDgcFmoiYdscN
> mkJVMhQgMgAAog4JENhQ93HEFCH2EIEIMOJMiACIOKgoACWOB0Q1KkSQwYYCojF5UMRooKZRo0AA
> Ow==
>
> --BOUNDARY-0000-1234
> Content-Transfer-Encoding: base64
> Content-Type: image/gif;
> 	x-unix-mode=0644;
> 	name="soylent-taupe.gif"
> Content-Disposition: attachment;
> 	filename=soylent-taupe.gif
>
> R0lGODlhDgAZAOZ9AF6pzm2x02yx02Ks0GOs0Gqw0kadx7LW6HCz1HS11Weu0dvs9EGaxrTX6dLn
> 8ValzFmnzVemzE6hylimzXe31kedx12pzk+hykufyW+y01Kjy0ygydTo8t3t9XK01FSky9jq83G0
>
>           .       .       .    (cut)     .       .       .       
>
> Dz9JJXUIUTuDCgRWVw8aEkwJDCmDAiYHRiQRchcUBkeDlgRoIKYLngkflMxwMIhDDgcFmoiYdscN
> mkJVMhQgMgAAog4JENhQ93HEFCH2EIEIMOJMiACIOKgoACWOB0Q1KkSQwYYCojF5UMRooKZRo0AA
> Ow==
>
> --BOUNDARY-0000-1234
> Content-Type: application/octet-stream;
> 	name="soylent-beige.gif.sig"
> Content-Disposition: attachment;
> 	filename="soylent-beige.gif.sig"
> Content-Transfer-Encoding: base64
>
> iQA/AwUAQZEXQmMQlGdKg9VZEQKnbgCg5dMjmJEnqAHpUrCKP/Xu8pB8JCgAn2shn2AKp913
> HAJt+LwN0AdtSDn3
> --BOUNDARY-0000-1234
> Content-Type: application/octet-stream;
> 	name="soylent-taupe.gif.sig"
> Content-Disposition: attachment;
> 	filename="soylent-taupe.gif.sig"
> Content-Transfer-Encoding: base64
>
> iQA/AwUAQZEXQmMQlGdKg9VZEQKnbgCg5BusKlATEhfNiRbGhSlrUYlbPg4AnRLoX03Vo48H
> NoWukVfqSGyiQFV+
> --BOUNDARY-0000-1234--

Signed and Encrypted

> Mime-Version: 1.0
> To: [email-masked]
> Content-Type: multipart/mixed;
> 	boundary="BOUNDARY-0000-1234"
> From: Damon Cokenias <[email-masked]>
> Subject: New Products
> Date: Mon, 1 Nov 2004 16:01:00 -0700
>
> --BOUNDARY-0000-1234
> Content-Transfer-Encoding: 7bit
> Content-Type: text/plain;
> 	charset=US-ASCII
>
> -----BEGIN PGP MESSAGE-----
> Version: 0
>
> qANQR1DBwEwD42FWyEinTuQBB/wKGj60HNiMWCFZckprmNCIFSkfD0ZpRyYg0L65
> bbydP5KnPo266C5CEy4T11E2Xp11tMh6WjvRqalV8FDONpFLhV89k2JvX+rQ6W+o
> nbd5cW5XiflO2+5t/IlMdzSrdpr2Wn9GgZss0T/5FA7E1ayj2SNjffIVfKuXHDEk
>
>           .       .       .    (cut)     .       .       .       
>
> Td3A+VZ7VWkJPQKruA+IMnShEUsaFcfVSkpylSzwrcL1g5M7We1LGHgtGXT/ejJ0
> H3FeNtDw97dsmcc9oNFOHqwvQPt+h5dQfi3fGsT8Lw45VAePRjezZOn1zfVlf3Rc
> idkUaO2aW9A=
> =RqCL
> -----END PGP MESSAGE-----
>
> --BOUNDARY-0000-1234
> X-Content-PGP-Universal-Saved-Content-Disposition: inline;
>         filename="Attachment1.pgp"
> X-Content-PGP-Universal-Saved-Content-Type: image/gif;
>         x-unix-mode=0644;
>         name="Attachment1.pgp"
> X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: base64
> Content-Type: application/octet-stream;
>         name="Attachment1.pgp"
> Content-Disposition: attachment;
>         filename="Attachment1.pgp"
>
> -----BEGIN PGP MESSAGE-----
> Version: 0
>
> qANQR1DBwEwD42FWyEinTuQBB/9yRpLW7rIulg2VxJTZps+MghHEaBptaYfA24Rf
> RvGv0y0xQDEpFYB5BY4BBbgUK+124K4c4ulaMGRMqsbqwTtzedUvqzuWEIqLdrhE
> 437c3hev2b3MiG/gVLz07O9S0FgZ1GxzTywWiCJSNIO1pKSRXN1BwDD2Yy7MLh9m
> 4uxYZzMMr0QTonzf1RoDCWm0tPL8n2sSR4D96yw+c0+FaFmPUEWtdHl43D1n752Y
>
>           .       .       .    (cut)     .       .       .       
>
> 1p5271ir9IBuQnHGd9azBhAxV+MndAcwhW006FF0H2Aw1DUWwJGA8ebXyVs8/Lp+
> nQYVAc88tl6seKo3dPCMGlTaBbVbmSHoqJadhqf6zl5+6nnFAlT31UmPlfOz
> =h4y5
> -----END PGP MESSAGE-----
>
> --BOUNDARY-0000-1234
> X-Content-PGP-Universal-Saved-Content-Disposition: inline;
>         filename="Attachment2.pgp"
> X-Content-PGP-Universal-Saved-Content-Type: image/gif;
>         x-unix-mode=0644;
>         name="Attachment2.pgp"
> X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: base64
> Content-Type: application/octet-stream;
>         name="Attachment2.pgp"
> Content-Disposition: attachment;
>         filename="Attachment2.pgp"
>
> -----BEGIN PGP MESSAGE-----
> Version: 0
>
> qANQR1DBwEwD42FWyEinTuQBB/0bA0TCswweIaDGLJXpTsrlMpEhCmNjGh53qeek
> /4r1XEwYPRVho/lUAaxtDNJ3mcAXekdlLxAtxdDRpypdRUz7yjPtcEB7P9wN8uWf
> 7AylCYd7ABvFmerenRZZ7Bc9TjHJWxnuoUWDsKlfeaOxqNgeiSZY4Q20HY0YZnTI
>
>           .       .       .    (cut)     .       .       .       
>
> D0urDVE2fFlpxjLPrPBrKf7wbo1+3ZUHjOgeElQTgChMOF5SgizEJlk2OLZoq/IO
> Ktu7v7jcQGPsKEyOC0Dzzhn33AeB06cU1sJV7gha6vrn0qfIXZQmGk3mzf4=
> =N7Wi
> -----END PGP MESSAGE-----
>
> --BOUNDARY-0000-1234--

HTML and RTF Encoding

PGP messages created by the PGP Plugin for Outlook (Windows) originally
defined a special attachment for storing HTML and RTF content for
compatibility purposes. PGP Universal has adopted this same formatting
for all HTML and RTF messages when using Partitioned Encoding. These
messages are readily identified by the presence of an attachment
called "PGPexch.htm.pgp", "PGPexch.htm.asc", "PGPexch.rtf.pgp" or
"PGPexch.rtf.asc". The attachment contains the encrypted RTF or HTML
portion of a multipart/alternative message.

This encoding should be used when signing/encrypting a
multipart/alternative message composed of exactly one plain text part and
one HTML part. Doing so ensures maximum compatibility for Windows users
with older PGP software. A multipart/alternative part with plain/html
subparts will become a multipart/mixed with an encrypted plain subpart
and an encrypted HTML attachment. A special header ("X-PGP-MIME-Structure:
alternative") is added to indicate this transformation was performed. This
header is not required for proper decoding.

When decrypting such messages, the "PGPexch.htm.pgp" or "PGPexch.htm.asc"
attachment will become the HTML alternative for the main body
text. Because RTF is not used for Internet mail, do not make RTF
attachments part of the message body. The RTF should be decrypted, but
should remain an attachment. The RTF attachment is useful only to Outlook.

Example 3.  A multipart/alternative message with html and text parts

> Mime-Version: 1.0
> To: [email-masked]
> From: Damon Cokenias <[email-masked]>
> Subject: Outlook Encoding
> Date: Mon, 1 Nov 2004 16:21:00 -0800
> Content-Type: multipart/alternative;
>      boundary="BOUNDARY-0000-1234"
>
> This is a multipart message in MIME format.
>
> --BOUNDARY-0000-1234
> Content-Type: text/plain
>
> Soylent Green is PEOPLE!
>
> --BOUNDARY-0000-1234
> Content-Type: text/html;
>         charset=US-ASCII
>
> <html><body bgcolor="black" text="green">
> Soylent Green is <b>PEOPLE!</b>
> </body></html>
>
> --BOUNDARY-0000-1234--

Signed and Encrypted

> Mime-Version: 1.0
> To: [email-masked]
> From: Damon Cokenias <[email-masked]>
> Subject: Outlook Encoding
> Date: Mon, 1 Nov 2004 16:21:00 -0800
> Content-Type: multipart/mixed;
> 	boundary="BOUNDARY-0000-1234"
>
> This is a multipart message in MIME format.
>
> --BOUNDARY-0000-1234
> Content-Type: text/plain;
> 	charset="us-ascii"
> Content-Transfer-Encoding: 7bit
>
> -----BEGIN PGP MESSAGE-----
> Version: 0
>
> qANQR1DBwEwD42FWyEinTuQBB/9KEBufHfz139ZuQCBushTxOenNzF5QzgqLkfTB
> h1a6y9XOfp1lox0Unx2s0cDcD1Vq2Ca/1kJvpYuPdnKyhwHSUZK9sE1RMSLM9sj/
> ng1FMHemyNb5NN+8T5jYFEE8KQlrNwpJfHXTgOkmeBrH749I2oHV/yhezYI9YqKI
>
>           .       .       .    (cut)     .       .       .       
>
> yIbvwHvS6HJeLjUylmRX+hplo2k/31JVg4b52z9Od3XEPptMYpvEKkpJUve6b3P2
> uLdxaT3vKep15UcdqitsbVVISxr6XZ+DZq4NKkrR73tt4eLhQlTWgZoYgac6QLuM
> Cg==
> =NOiI
> -----END PGP MESSAGE-----
>
> --BOUNDARY-0000-1234
> X-Content-PGP-Universal-Saved-Content-Type: text/html;
> 	charset=US-ASCII
> Content-Type: application/octet-stream;
> 	name="PGPexch.htm.pgp"
> Content-Disposition: attachment
> X-PGP-MIME-Structure: alternative
>
> -----BEGIN PGP MESSAGE-----
> Version: 0
>
> qANQR1DBwEwD42FWyEinTuQBB/467rWcjfuimgRk44ifIqog/CpjSlitDbv/T+Kr
> JZqgEBP5CxwiO8G/Bgf2PpYOz2iiTDRycfFgwOktmkBvAYSatipSCwAWJ/UPcXXA
> uqQEnKyq+tZIibE9fDrbzObvgIHbe2M7HofiobQ0UAVb3/KaQphRM2sJ0ATotIbp
>
>           .       .       .    (cut)     .       .       .       
>
> TjQiuNqJfYlyWUrPUg7dTeSdSOnIm/zqLVQxm/+NB9SWaY+G3eqqBg6M/ytNaUwd
> jjBHOHh+6wPfkegmWP/8wxI58n6SV9d5OQ==
> =aD+v
> -----END PGP MESSAGE-----
>
> --BOUNDARY-0000-1234--

References

RFC 2440 OpenPGP Message Format
RFC 3156 MIME Security with Pretty Good Privacy

Date: Mon, 28 Feb 2005 19:54:42 +0000
From: Ian G <[email-masked]>
Organization: http://financialcryptography.com/
To: [email-masked]
Subject: Re: Forward Secrecy
Sender: [email-masked]

Hal Finney wrote:

>http://www.links.org/dnssec/draft-brown-pgp-pfs-04.txt.
>
>   Using a series of encryption keys, each with a short lifetime,
>   reduces the information revealed by the compromise of any one private
>   key because each key protects less data.  If expired keys are
>   securely deleted, attackers will never be able to retrieve them to
>   decrypt captured ciphertext.  Therefore when a public encryption key
>   expires, an OpenPGP client MUST securely wipe the corresponding
>   private key [4].
>
>I don't agree that OpenPGP clients MUST always securely wipe expired
>private keys.  In the context of a user who wants PFS, this makes sense.
>But for a user who wants to be sure he can decrypt his messages, this
>is a bad policy.  For example, some mail systems may store the messages
>in encrypted form, and he needs to keep the key around in order to read
>those messages in the future.
>  
>

I'm inclined to think that this would be bad
practice.  If a mail system were to want to
keep mail around for encryption purposes,
I'd say it should re-encrypt the packet using
a local key.

The alternate - saving the encrypted message
in the form as it was sent over the network -
leads to all sorts of key management trouble
later on.  It means that keys have to be kept
around for as long as the oldest email, which
isn't really likely to please anyone.

>But this leads to a larger concern, which is that much of this draft
>specifies client behavior in a manner which has traditionally been out
>of scope for our working group.  We would not normally propose to give
>guidelines for UI such as the existence of a panic mode, and how clients
>should respond to it.  For example, we do not attempt to prescribe how
>client software should display signed messages, what information should
>be shown from a signature, or how to depict messages which are partially
>signed and partially unsigned.
>  
>

I'd agree with that.  Although, if PFS is to
be achieved, a certain amount of guidance
would be required ... to explain things like
"must wipe the transport key after re-encrypting."

>I won't try to go through the rest of the draft at this time.  As I said,
>I support the goal of PFS, but I am skeptical about whether it makes
>sense for our WG to promulgate such detailed advice on a relatively
>narrow aspect of security.
>  
>

One comment - the URL points to an ID, a draft
presumably heading for standards track.  Would
it make more sense to specify a more client-oriented
document if it was informational track?

iang

-- 
News and views on what matters in finance+crypto:
        http://financialcryptography.com/

To: [email-masked]
Subject: Re: Forward Secrecy
Date: Mon, 28 Feb 2005 10:41:09 -0800 (PST)
From: [email-masked] ("Hal Finney")
Sender: [email-masked]

I think we had some discussion of this a few years ago, but I don't
have my records handy.  I do like the idea of forward secrecy but I
think there are a few problems with the proposals in the draft
http://www.links.org/dnssec/draft-brown-pgp-pfs-04.txt.

   Using a series of encryption keys, each with a short lifetime,
   reduces the information revealed by the compromise of any one private
   key because each key protects less data.  If expired keys are
   securely deleted, attackers will never be able to retrieve them to
   decrypt captured ciphertext.  Therefore when a public encryption key
   expires, an OpenPGP client MUST securely wipe the corresponding
   private key [4].

I don't agree that OpenPGP clients MUST always securely wipe expired
private keys.  In the context of a user who wants PFS, this makes sense.
But for a user who wants to be sure he can decrypt his messages, this
is a bad policy.  For example, some mail systems may store the messages
in encrypted form, and he needs to keep the key around in order to read
those messages in the future.

We would need to make the wording clear that this is only for clients
operating in "PFS mode".

   Deletion should take place once all messages that could have been
   sent before expiry have been received and decrypted.  For example, as
   a user logs on, their mail client SHOULD retrieve and decrypt all
   messages from their mail server before deleting any newly-expired
   private keys.  A "panic mode" MAY bypass this step.

I guess that "panic mode" means some command the user could give to
immediately delete all expired decryption keys.

But this leads to a larger concern, which is that much of this draft
specifies client behavior in a manner which has traditionally been out
of scope for our working group.  We would not normally propose to give
guidelines for UI such as the existence of a panic mode, and how clients
should respond to it.  For example, we do not attempt to prescribe how
client software should display signed messages, what information should
be shown from a signature, or how to depict messages which are partially
signed and partially unsigned.

The PFS draft is full of detailed recommendations about client behavior.
Here, it describes how and when clients should access the mail server.
Later, it talks about clients sending various warnings to each other,
generating keys in the background, and revoking keys before exporting
the private part.  The main thrust of the draft is towards specifying
client behavior.

My principle concern is that since we have eschewed such specifications
even for the more fundamental task of communicating securely via email,
does it make sense to go into such detail for a rather more specialized
sub-task, of achieving PFS in the process?  Here is another example:

   Clients receiving messages encrypted with a revoked key MUST warn the
   sender that they should not use that public key again.  Any relevant
   key revocation certificates MUST be included in the warning.

This is not really PFS specific, and it may be a good idea, but it is
exactly the kind of thing which we have left out of the OpenPGP spec.
There are too many issues involved in the design of a mail user agent
for a secure email system, for us to try to capture them in a spec.

I won't try to go through the rest of the draft at this time.  As I said,
I support the goal of PFS, but I am skeptical about whether it makes
sense for our WG to promulgate such detailed advice on a relatively
narrow aspect of security.

Hal Finney

Date: Mon, 28 Feb 2005 16:59:37 +0000
From: Ben Laurie <[email-masked]>
To: Derek Atkins <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: OpenPGP Agenda for IETF-62
Sender: [email-masked]

Derek Atkins wrote:
> OpenPGP is scheduled to meet at IETF-62 in Minneapolis:
> 
> TUESDAY, March 8, 2005
> 0900-1130 Morning Sessions
> SEC  openpgp    An Open Specification for Pretty Good Privacy WG
> 
> 
> The Agenda for this meeting:
> 
> ?? - ??    PFS (Ben Laurie?)

Sure thing.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

From: Derek Atkins <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: OpenPGP Agenda for IETF-62
Date: Mon, 28 Feb 2005 11:42:58 -0500
Sender: [email-masked]

OpenPGP is scheduled to meet at IETF-62 in Minneapolis:

TUESDAY, March 8, 2005
0900-1130 Morning Sessions
SEC  openpgp    An Open Specification for Pretty Good Privacy WG

The Agenda for this meeting:

:00 - :05  Agenda Bashing
           Find Secretary / Jabber Scribe
:05 - :35  draft-ietf-openpgp-rfc2440bis editorial status (Jon Callas?)
:35 - ??   Discussion of Open Issues (Jon?)
?? - ??    PFS (Ben Laurie?)

Proposed names are suggested presenters and may be changed.

-derek
-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

From: Florian Weimer <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: Rick van Rein <[email-masked]>, [email-masked]
Subject: Re: Tighter MPI spec
Date: Sun, 27 Feb 2005 23:21:47 +0100
Sender: [email-masked]

* Jon Callas:

> This language has been sitting in 2440 and followons since '97. No one 
> has ever had a problem implementing it, no one has had an 
> interoperability issue with bignums. Not PGP, nor GnuPG, nor Hushmail, 
> nor Cryptix, nor Forum, nor Bouncy Castle, nor anyone else.

Not true.  GnuPG had a bug in MPI handling because it followed the
language in RFC 2440 too verbatim. 8-)

(You added a hint to 2440bis a few years ago, so others hopefully
won't make the same mistake.)

Date: Sat, 26 Feb 2005 12:45:16 +0000
From: Ben Laurie <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: OpenPGP <[email-masked]>
Subject: Re: More questions and comments on rfc2440bis-12
Sender: [email-masked]

Jon Callas wrote:
> 
> On other certification types:
> 
> Apart from what David said about GnuPG, no one has ever done any sort of 
> certification other than the 0x10 certification signatures. (By that I 
> mean that there's never been a program that actually went to the trouble 
> of creating a UI that effectively said, "How good do you think this 
> certification is?")
> 
> At one point, we removed them from OpenPGP because no one used them. 
> They were put in because the working group liked the expressiveness of 
> the language even if no one was expressing themselves that way. I think 
> that discussion is still valid and don't see a reason to change it. The 
> different degrees of certification are in the OpenPGP language because 
> we as a group think they should be there.

OK, then the explanation could perhaps be improved.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

Cc: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Tighter MPI spec
Date: Fri, 25 Feb 2005 18:12:04 -0800
To: Rick van Rein <[email-masked]>
Sender: [email-masked]

On 25 Feb 2005, at 11:52 AM, Rick van Rein wrote:
> The specification of the MPI format has a *flaw* that forces compliant
> implementations to do more work than desired or intended.  This is
> outright embarassing in a standard.
>

Perhaps I'm just stupid, but I don't see what the ambiguity is, or what 
needs to be fixed, other than that you've changed the explanatory 
example. Especially with Ben Laurie's comment that unused bits MBZ, I 
don't see any any room for even willful error in it.

This language has been sitting in 2440 and followons since '97. No one 
has ever had a problem implementing it, no one has had an 
interoperability issue with bignums. Not PGP, nor GnuPG, nor Hushmail, 
nor Cryptix, nor Forum, nor Bouncy Castle, nor anyone else.

I know I'm in the fog of jetlag and flu, but I don't see how your 
example of [00 05 22] could possibly be interpreted as a decimal 17. I 
can see how you might think it 0x22 (decimal 34) with a bad length, or 
a 2 with a bad length and garbage in the unused bits (now clarified by 
Ben Laurie). I think that the point you're trying to make is that is is 
conceivable that [00 05 31] a 17.

However, the existing text says:

    These octets form a big-endian number; a big-endian number can be
    made into an MPI by prefixing it with the appropriate length.

and

    The length field of an MPI describes the length starting from its
    most significant non-zero bit. Thus, the MPI [00 02 01] is not
    formed correctly. It should be [00 01 01].

Even without the MBZ clarification, I think this tells us that the 
*natural* formation of a 17 as an MPI to be [00 05 11]. The second 
paragraph says that [00 06 11] is not legal because the sixth bit of 
0x11 is zero, and that [00 05 31] is not legal because that sixth bit 
is now the most significant non-zero bit. Bis13 (which presently only I 
have) adds in:

    Unused bits of an MPI MUST be zero.

which seems to me to remove all realms for misinterpretation.

The first paragraph shows that the natural way to form an MPI would 
bring you to [00 05 11]. The second shows that [00 05 i] where i > 0x1f 
is not legal. Please help me understand how I would evaluate [00 05 
22], [00 05 44], and [00 05 88] to be a 17. Without the MBZ 
clarification, I can see how they might be naively be seen to be 2, 4, 
and 8 respectively, but I think that the MBZ clarification removes even 
the naive misunderstanding. I just don't see how they're 17. Let me 
know and I'll fix it, really I will.

	Jon

From: Jon Callas <[email-masked]>
Subject: Re: More questions and comments on rfc2440bis-12
Date: Fri, 25 Feb 2005 16:08:20 -0800
To: OpenPGP <[email-masked]>
Sender: [email-masked]

On other certification types:

Apart from what David said about GnuPG, no one has ever done any sort 
of certification other than the 0x10 certification signatures. (By that 
I mean that there's never been a program that actually went to the 
trouble of creating a UI that effectively said, "How good do you think 
this certification is?")

At one point, we removed them from OpenPGP because no one used them. 
They were put in because the working group liked the expressiveness of 
the language even if no one was expressing themselves that way. I think 
that discussion is still valid and don't see a reason to change it. The 
different degrees of certification are in the OpenPGP language because 
we as a group think they should be there.

	Jon

To: Ian G <[email-masked]>
Cc: Hal Finney <[email-masked]>, [email-masked]
Subject: Re: DSA hash algorithms
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[email-masked]
Date: Fri, 25 Feb 2005 23:00:57 +0100
Sender: [email-masked]

On Fri, 25 Feb 2005 20:23:25 +0000, Ian G said:

> I also lean to the first solution.  I do not

Same here. 

  Werner

Date: Fri, 25 Feb 2005 15:48:34 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: [ISSUE] Minor language nits
Mail-Followup-To: [email-masked]
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

Three minor language nits:

In section 5.2.3. Version 4 Signature Packet Format:

     - 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.

There needs to be a "the" between "for" and "following".  Note also
the same problem one paragraph later for the item discussing the
unhashed subpacket data.

=============================

Throughout the document, references to RFCs are written
inconsistently.  For example, there are 3 references to "RFC 1991"
(with the space), and 2 references to "RFC1991" (without the space).
I like it with the space, though I really don't care which way things
go so long as it is consistent.  (It's not just 1991 - all the RFC
references in the draft are mixed between the two styles).

=============================

There are a few spots in the draft where "PGP" is used when "OpenPGP"
should have been used (when referring to the standard, rather than the
product):

  Section 2.3 (Compression) has one in the second paragraph.

  Section 5.2.1 (Signature Types) has one in the discussion of the 0x13
  signature class.

  Section 5.7 (Symmetrically Encrypted Data Packet) has one when
  discussing "PGP's variant of Cipher Feedback (CFB) mode".

David

Date: Fri, 25 Feb 2005 20:23:25 +0000
From: Ian G <[email-masked]>
Organization: http://financialcryptography.com/
To: Hal Finney <[email-masked]>
CC: [email-masked]
Subject: Re: DSA hash algorithms
Sender: [email-masked]

Hal Finney wrote:

>I suggest that we do one of two things.  We could change the spec to
>require SHA-1 with DSA keys, and then when NIST comes out with DSA-2
>which uses SHA-2 (which they have been promising for years now), we will
>then support the larger hashes.  Or we could change the spec to allow
>any hash >= 160 bits to be used with DSA keys.  We could follow the NIST
>recommendation in http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf
>and use just the left 160 bits of the larger hash.
>
>I lean towards the first solution, even though hash rollback attacks
>require the ability to completely reverse hashes and not just find
>collisions, so we really do seem safe from them.  I feel uncomfortable
>going out with a spec that intentionally opens itself up to a preventable
>attack.  But it's frustrating that NIST has dragged its feet and not
>come up with a DSA standard that allows other hashes.  It is tempting
>to allow SHA-2 with DSA as an interim measure.
>  
>

I also lean to the first solution.  I do not
judge the size of the market in digital
signatures to be anywhere significant
enough to worry about, and the attacks
so far mooted are all in the theoretical,
unvalidated domain.

Secondly, if someone wants something
stronger than DSA, they can use RSA.

It's good to review the possibilities though.

(I'm sure NIST have also received their
wake up call by now ;-)

iang

-- 
News and views on what matters in finance+crypto:
        http://financialcryptography.com/

To: [email-masked]
Path: not-for-mail
From: Lutz Donnerhacke <[email-masked]>
Newsgroups:  iks.lists.ietf-open-pgp
Subject:  Re: DSA hash algorithms
Date: Fri, 25 Feb 2005 20:07:08 +0000 (UTC)
Organization:  IKS GmbH Jena
Lines: 20
NNTP-Posting-Host: belenus.iks-jena.de
NNTP-Posting-Date: Fri, 25 Feb 2005 20:07:08 +0000 (UTC)
Sender: [email-masked]

* "Hal Finney" wrote:
> (Although RIPEMD-160 has not been attacked, the earlier RIPEMD hash was
> broken last year, and it seems plausible that the new attacks could work
> against RIPEMD-160 as well.)

IBTD. By the same argument applies to the SHA-2 family. It is senseless.

> I suggest that we do one of two things.  We could change the spec to
> require SHA-1 with DSA keys, and then when NIST comes out with DSA-2
> which uses SHA-2 (which they have been promising for years now), we will
> then support the larger hashes.  Or we could change the spec to allow
> any hash >= 160 bits to be used with DSA keys.  We could follow the NIST
> recommendation in http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf
> and use just the left 160 bits of the larger hash.

Because every hash of 160bit will do, I'd propose to be as flexible as
possible. We can provide a general statement about hashes in all contexts:
 "If the digest is larger than expected, only the leftmost bits count."

I do not know if those truncated hashes provide the same level of security ...

Date: Fri, 25 Feb 2005 20:52:02 +0100
From: Rick van Rein <[email-masked]>
Subject: Re: Tighter MPI spec
To: Jon Callas <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

Hello Jon,

> We're attempting to get to last call on the document.

That places things in perspective, of course.

> we don't 
> need small changes that add no particular value.

The specification of the MPI format has a *flaw* that forces compliant
implementations to do more work than desired or intended.  This is
outright embarassing in a standard.

> While these changes 
> may make things clearer for you, they're likely to irritate someone 
> else.

Agreeable.

> I don't find the MPI changes to be clearer. I find them less clear,

My goal is to take away the ambguity.  The exact wording is just a way
to get that done.  Any other phrasing would be fine.

Hope this helps,
 -Rick

To: [email-masked]
Subject: DSA hash algorithms
Date: Fri, 25 Feb 2005 11:22:21 -0800 (PST)
From: [email-masked] ("Hal Finney")
Sender: [email-masked]

Jon and I (who both work for PGP Corp.) were looking at the situation with
DSA hash algorithms.  The recent attack on SHA-1, reducing its strength
from 2^80 down to 2^69, is motivating a move towards the SHA-2 family.
PGP is migrating towards SHA-2 as the default hash algorithm for use
with RSA signatures.

We discussed the pros and cons of allowing SHA-2 with DSA signatures.
It's a complicated issue, cryptographically and technologically, which
I could write more about.  But in the process we reviewed the language
in the RFC draft about the issue.

Section 5.2.2, Version 3 Signature Packet Format, says:

   DSA signatures MUST use hashes with a size of 160 bits, to match q,
   the size of the group generated by the DSA key's generator value.
   The hash function result is treated as a 160 bit number and used
   directly in the DSA signature algorithm.

Section 13, Security Considerations, says:

     * The DSA algorithm will work with any 160-bit hash, but it is
       sensitive to the quality of the hash algorithm, if the hash
       algorithm is broken, it can leak the secret key. The Digital
       Signature Standard (DSS) specifies that DSA be used with SHA-1.
       RIPEMD-160 is considered by many cryptographers to be as strong.
       An implementation should take care which hash algorithms are
       used with DSA, as a weak hash can not only allow a signature to
       be forged, but could leak the secret key.

     * There is a somewhat-related potential security problem in
       signatures. If an attacker can find a message that hashes to the
       same hash with a different algorithm, a bogus signature
       structure can be constructed that evaluates correctly.

       For example, suppose Alice DSA signs message M using hash
       algorithm H. Suppose that Mallet finds a message M' that has the
       same hash value as M with H'. Mallet can then construct a
       signature block that verifies as Alice's signature of M' with
       H'. However, this would also constitute a weakness in either H
       or H' or both. Should this ever occur, a revision will have to
       be made to this document to revise the allowed hash algorithms.

Presently, then, we allow DSA signatures to use other hashes than SHA-1,
but they have to be exactly 160 bits.  The only other 160 bit hash we
support is RIPEMD-160.  The language allows this hash, but technically
disallows any of the SHA-2 family hashes from being used with our DSA
signatures.

This is unfortunate, because it makes us vulnerable to hash rollback
attacks, as described in the last paragraph above, but does not let us
move to what are thought to be the strongest hashes in the standard,
SHA-256 and SHA-512.  So in a way we have the worst of both worlds: hash
rollbacks because we don't fix on SHA-1 as the DSS does; but inability
to respond flexibly to attacks on the current hashes.

(Although RIPEMD-160 has not been attacked, the earlier RIPEMD hash was
broken last year, and it seems plausible that the new attacks could work
against RIPEMD-160 as well.)

I suggest that we do one of two things.  We could change the spec to
require SHA-1 with DSA keys, and then when NIST comes out with DSA-2
which uses SHA-2 (which they have been promising for years now), we will
then support the larger hashes.  Or we could change the spec to allow
any hash >= 160 bits to be used with DSA keys.  We could follow the NIST
recommendation in http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf
and use just the left 160 bits of the larger hash.

I lean towards the first solution, even though hash rollback attacks
require the ability to completely reverse hashes and not just find
collisions, so we really do seem safe from them.  I feel uncomfortable
going out with a spec that intentionally opens itself up to a preventable
attack.  But it's frustrating that NIST has dragged its feet and not
come up with a DSA standard that allows other hashes.  It is tempting
to allow SHA-2 with DSA as an interim measure.

BTW, I'm not sure about the comment above about weak hashes exposing
secret keys with DSA.  I can't bring such an attack to mind.  Does anyone
have a reference to that?

Hal Finney

Date: Fri, 25 Feb 2005 13:11:28 -0500
From: David Shaw <[email-masked]>
To: Ben Laurie <[email-masked]>
Cc: OpenPGP <[email-masked]>
Subject: Re: More questions and comments on rfc2440bis-12
Mail-Followup-To: Ben Laurie <[email-masked]>, OpenPGP <[email-masked]>
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

On Fri, Feb 25, 2005 at 05:18:14PM +0000, Ben Laurie wrote:
> 
> David Shaw wrote:
> >On Wed, Feb 23, 2005 at 11:37:19AM +0000, Ben Laurie wrote:
> >
> >>In 5.2.1:
> >>
> >>"0x10: Generic certification of a User ID and Public Key packet."
> >>
> >>Does this mean that the signature is over the User ID packet and the 
> >>Public Key packet, concatenated, in that order? Or what?
> >
> >
> >5.2.1 is just an overview.  The nitty-gritty on how to make each type
> >is specified in 5.2.4. Computing Signatures.
> >
> >
> >>Also, what on earth does:
> >>
> >>      Note that all PGP "key signatures" are this type of
> >>      certification.
> >
> >
> >PGP doesn't generate 0x11, 0x12, or 0x13 signatures, and when it
> >encounters them treats them all as if they were 0x10.
> 
> When you say "PGP" you mean, presumably, some version(s) of the software 
> - which? I presume modern ones do generate them all?

All versions I've ever seen, including 2, 5, 6, 7, and 8, and all
sub-versions of that list.

I see 0x11, 0x12, and 0x13 as sort of a vestigal tail in OpenPGP.
They're not really useful for much, and are pretty much ignored.
Certainly 0x12 doesn't have less validity than 0x13 in the usual
definition of the web of trust.

David

Date: Fri, 25 Feb 2005 17:18:14 +0000
From: Ben Laurie <[email-masked]>
To: David Shaw <[email-masked]>
Cc: OpenPGP <[email-masked]>
Subject: Re: More questions and comments on rfc2440bis-12
Sender: [email-masked]

David Shaw wrote:
> On Wed, Feb 23, 2005 at 11:37:19AM +0000, Ben Laurie wrote:
> 
>>In 5.2.1:
>>
>>"0x10: Generic certification of a User ID and Public Key packet."
>>
>>Does this mean that the signature is over the User ID packet and the 
>>Public Key packet, concatenated, in that order? Or what?
> 
> 
> 5.2.1 is just an overview.  The nitty-gritty on how to make each type
> is specified in 5.2.4. Computing Signatures.
> 
> 
>>Also, what on earth does:
>>
>>       Note that all PGP "key signatures" are this type of
>>       certification.
> 
> 
> PGP doesn't generate 0x11, 0x12, or 0x13 signatures, and when it
> encounters them treats them all as if they were 0x10.

When you say "PGP" you mean, presumably, some version(s) of the software 
- which? I presume modern ones do generate them all?

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

Date: Fri, 25 Feb 2005 16:59:10 +0000
From: Ben Laurie <[email-masked]>
To: Ian G <[email-masked]>
Cc: Jon Callas <[email-masked]>, OpenPGP <[email-masked]>
Subject: Re: Forward Secrecy
Sender: [email-masked]

Ian G wrote:
> 
> Jon Callas wrote:
> 
>>
>> I think this is a great idea and ought to be part of the WG's scope. 
>> I'd even like to see some of the OTR work brought in here.
>>
>> I don't see why this shouldn't just get a good buffing and go.
> 
> 
> 
> As long as it doesn't hold up the draft, that
> would be fine!  How about we set a deadline
> on the draft, and go to the next step on it?

It is an independent I-D.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

Date: Fri, 25 Feb 2005 16:52:39 +0000
From: Ian G <[email-masked]>
Organization: http://financialcryptography.com/
To: Jon Callas <[email-masked]>
CC: OpenPGP <[email-masked]>
Subject: Re: Forward Secrecy
Sender: [email-masked]

Jon Callas wrote:

>
> I think this is a great idea and ought to be part of the WG's scope. 
> I'd even like to see some of the OTR work brought in here.
>
> I don't see why this shouldn't just get a good buffing and go.

As long as it doesn't hold up the draft, that
would be fine!  How about we set a deadline
on the draft, and go to the next step on it?

iang

-- 
News and views on what matters in finance+crypto:
        http://financialcryptography.com/

Date: Fri, 25 Feb 2005 11:27:16 -0500
From: David Shaw <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: More questions and comments on rfc2440bis-12
Mail-Followup-To: OpenPGP <[email-masked]>
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

On Wed, Feb 23, 2005 at 11:37:19AM +0000, Ben Laurie wrote:
> 
> In 5.2.1:
> 
> "0x10: Generic certification of a User ID and Public Key packet."
> 
> Does this mean that the signature is over the User ID packet and the 
> Public Key packet, concatenated, in that order? Or what?

5.2.1 is just an overview.  The nitty-gritty on how to make each type
is specified in 5.2.4. Computing Signatures.

> Also, what on earth does:
> 
>        Note that all PGP "key signatures" are this type of
>        certification.

PGP doesn't generate 0x11, 0x12, or 0x13 signatures, and when it
encounters them treats them all as if they were 0x10.

By default GnuPG generates 0x10, but the user can request another
type.  Also by default GnuPG ignores 0x11 signatures completely, but
treats treats 0x12 and 0x13 the same as 0x10.

David

Cc: OpenPGP <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: Forward Secrecy
Date: Fri, 25 Feb 2005 07:59:26 -0800
To: Ben Laurie <[email-masked]>
Sender: [email-masked]

I think this is a great idea and ought to be part of the WG's scope. 
I'd even like to see some of the OTR work brought in here.

I don't see why this shouldn't just get a good buffing and go.

	Jon

Cc: OpenPGP <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: Tighter MPI spec (and on keychains)
Date: Fri, 25 Feb 2005 07:38:09 -0800
To: Rick van Rein <[email-masked]>
Sender: [email-masked]

I don't see any reason we need to change either of these.

We're attempting to get to last call on the document. While there's at 
least one open discussion (which I'll try to get to soon), we don't 
need small changes that add no particular value. While these changes 
may make things clearer for you, they're likely to irritate someone 
else. Whatever you may think about the present wordings, they are the 
devil we know and the devil that we've agreed on.

I don't find the MPI changes to be clearer. I find them less clear, but 
that could be a combination of the hour of the day and that I 
understand the way things are. And as Ian said, keyrings are out of 
scope. The reason they are that way is so that someone can store keys 
however they want and still call it a keyring.

This document shows how the data structures are laid out. There are 
many higher-level things you can do with them.

	Jon

Date: Thu, 24 Feb 2005 11:23:06 -0800
To: [email-masked]
Cc: 
Subject: Re: Forward Secrecy // sorry,  ignore my previous message //
From: <[email-masked]>
Sender: [email-masked]

sorry,

i didn't read it through carefully,

as long as the private key is revoked and no backups made,

it does provide a 'lot' of extra security

sorry,

vedaal

Concerned about your privacy? Follow this link to get
secure FREE email: http://www.hushmail.com/?l=2

Free, ultra-private instant messaging with Hush Messenger
http://www.hushmail.com/services-messenger?l=434

Promote security and make money with the Hushmail Affiliate Program: 
http://www.hushmail.com/about-affiliate?l=427

Date: Thu, 24 Feb 2005 11:01:28 -0800
To: [email-masked]
Cc: 
Subject: Re: Forward Secrecy
From: <[email-masked]>
Sender: [email-masked]

On Thu, 24 Feb 2005 08:16:03 -0800 Ben Laurie <[email-masked]> 
wrote:

>http://www.links.org/dnssec/draft-brown-pgp-pfs-04.html
>http://www.links.org/dnssec/draft-brown-pgp-pfs-04.txt
>
>Forward Secrecy Extensions for OpenPGP

>Comments, please!

the site lists the following statement:

"If expired keys are securely deleted, attackers will never be able 
to retrieve them to decrypt captured ciphertext. Therefore when a 
public encryption key expires, an OpenPGP client MUST securely wipe 
the corresponding private key"

it would also need the suggestion/requirement that the OpenPGP 
client
NOT be allowed to make a 'backup' of the private key,
something now routinely done by default

but even if it does so, and does not make any backups,
it is still not foolproof,
it just requires the adversary to do 'more work'

assuming the sender corresponds with 'n' different recipients,
and sends a new subkey packet to each of them for each encryption,

if the adversary can intercept each e-mail message, and stores 
them,
then the adversary now needs the 'n' long-term private keys of the 
recipients, and can then recover the subkeys and the messages

so, the security still depends on the recipient's long term
private keys not being compromised, as it did without the use of 
the subkeys

but if the sender doesn't encrypt to self, and encrypts only to the 
receiver,
how is the security improved by having different subkeys each time 
for that receiver?

vedaal

Concerned about your privacy? Follow this link to get
secure FREE email: http://www.hushmail.com/?l=2

Free, ultra-private instant messaging with Hush Messenger
http://www.hushmail.com/services-messenger?l=434

Promote security and make money with the Hushmail Affiliate Program: 
http://www.hushmail.com/about-affiliate?l=427

Date: Thu, 24 Feb 2005 16:16:03 +0000
From: Ben Laurie <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Forward Secrecy
Sender: [email-masked]

This I-D has been through WG last call back in 2001 or so. At that 
point, something went wrong and it got sat on. Unfortunately, I didn't 
have time before the deadline to convert it to the new format, but it 
now is, and I'd like to try to introduce it as a work item for the WG. 
I'll send it to the I-D editor, but in the meantime, its available here:

http://www.links.org/dnssec/draft-brown-pgp-pfs-04.html
http://www.links.org/dnssec/draft-brown-pgp-pfs-04.txt

Forward Secrecy Extensions for OpenPGP

"The confidentiality of encrypted data depends on the secrecy of the key 
needed to decrypt it. If one key is able to decrypt large quantities of 
data, its compromise will be disastrous. This memo describes three 
methods for limiting this vulnerability for OpenPGP messages: reducing 
the lifetime of confidentiality keys; one-time keys; and the additional 
use of lower-layer security services."

Comments, please!

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

Date: Thu, 24 Feb 2005 12:35:51 +0000
From: Ian G <[email-masked]>
Organization: http://financialcryptography.com/
To: OpenPGP <[email-masked]>
Subject: Re: Tighter MPI spec (and on keychains)
Sender: [email-masked]

(on the keyrings only)

Rick van Rein wrote:

>Another thing.  In 3.6 on Keyrings, I was confused whether it described a
>message format or a storage format.  Only the former seems interesting in
>the scope of this spec.  I therefore propose the following.
>
>CHANGE
>   A keyring is a collection of one or more keys in a file or database.
>   Traditionally, a keyring is simply a sequential list of keys, but
>   may be any suitable database. It is beyond the scope of this
>   standard to discuss the details of keyrings or other databases.
>INTO
>   A keyring is conceptually a set of at least one public key.  To put
>   a keyring in an OpenPGP message, it is represented as the concatenation
>   of the keys in the ring.
>  
>

Are you trying to make it into a message?

I never heard of a 'keyring message'  ... if it isn't
defined and nobody has wanted it until now, I'd
have thought there was no value in complicating
things by adding it now.

The reason that the comment is there at all is because
even though it is out of scope, there needs to be a
signal that tells people that.  There have always
been lots of discussions about 'what about the
keyring, it isn't defined!' and this is meant to
clearly indicated that ... it isn't defined.

>Note: The original statement speaks of "one or more" keys.  I therefore
>      said "at least one" but models are often complicated by treating the
>      zero case differently -- could the "one or more" be strikken?  Or
>      would this cause unacceptable backward compatibility problems?
>  
>

If this is about keyrings, then it is a potential tightening
in something that is agreed as out of scope.  As it is out
of scope, it can't be authoritive!

iang

-- 
News and views on what matters in finance+crypto:
        http://financialcryptography.com/

Date: Thu, 24 Feb 2005 10:30:32 +0100
From: Rick van Rein <[email-masked]>
Subject: Tighter MPI spec (and on keychains)
To: OpenPGP <[email-masked]>
Sender: [email-masked]

Hello Jon and others,

According to bis-12, the following MPI values are acceptable encodings
of decimal 17:  [00 05 11], [00 05 22], [00 05 44] and [00 05 88]
I bet this is unintentional.  I therefore propose these changes:

CHANGE
   An MPI consists of two pieces: a two-octet scalar that is the length
   of the MPI in bits followed by a string of octets that contain the
   actual integer.
INTO
   An MPI consists of two pieces: a two-octet scalar that is the length
   of the MPI in bits followed by a string of octets that contain the
   actual integer.  The second part is prefixed with (8-MPI.length) mod 8
   zero-valued bits.

CHANGE
   These octets form a big-endian number; a big-endian number can be
   made into an MPI by prefixing it with the appropriate length.
INTO
   These octets form a big-endian number; a big-endian number can be
   made into an MPI by prefixing it with the appropriate bit length.

AFTER
   The length field of an MPI describes the length starting from its
   most significant non-zero bit. Thus, the MPI [00 02 01] is not
   formed correctly. It should be [00 01 01].
APPEND
   The bits of the MPI end in the last bit of the last octet.  Thus,
   the MPI [00 05 44] is not formed correctly. It should be [00 05 11].

Another thing.  In 3.6 on Keyrings, I was confused whether it described a
message format or a storage format.  Only the former seems interesting in
the scope of this spec.  I therefore propose the following.

CHANGE
   A keyring is a collection of one or more keys in a file or database.
   Traditionally, a keyring is simply a sequential list of keys, but
   may be any suitable database. It is beyond the scope of this
   standard to discuss the details of keyrings or other databases.
INTO
   A keyring is conceptually a set of at least one public key.  To put
   a keyring in an OpenPGP message, it is represented as the concatenation
   of the keys in the ring.

Note: The original statement speaks of "one or more" keys.  I therefore
      said "at least one" but models are often complicated by treating the
      zero case differently -- could the "one or more" be strikken?  Or
      would this cause unacceptable backward compatibility problems?

Cheers,
 -Rick

Date: Wed, 23 Feb 2005 11:37:19 +0000
From: Ben Laurie <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: More questions and comments on rfc2440bis-12
Sender: [email-masked]

In 5.2.1:

"0x10: Generic certification of a User ID and Public Key packet."

Does this mean that the signature is over the User ID packet and the 
Public Key packet, concatenated, in that order? Or what?

Also, what on earth does:

        Note that all PGP "key signatures" are this type of
        certification.

mean?

In 5.2.2:

    "The data being signed is hashed, and then the signature type and
    creation time from the signature packet are hashed (5 additional
    octets)."

is unclear, suggest:

"The concatenation of the data to be signed, the signature type and
creation time from the signature packet (5 additional octets) is hashed."

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

Date: Mon, 21 Feb 2005 14:35:32 -0800
To: <[email-masked]>
From: Trevor Perrin <[email-masked]>
Subject: Re: Some thoughts on a v5 key and why it shouldn't be a mess
Sender: [email-masked]

At 12:11 PM 2/21/2005 -0500, David Shaw wrote:
>[...]
>A v5 fingerprint is written "algo - colon - data", like 2:12 34 56 78
>9A BC DE F0 ...(etc).

One neat thing you could do with this sort of typed, variable-length 
fingerprint format is try out different 'algos' for shorter, more friendly 
fingerprints:

Example 1: base32 the first 125 bits of a hash output, for a 25-character 
fingerprint.

Example 2: search for a hash output beginning with 20 zero bits (< 1 sec on 
a modern machine; search is done by placing random values in a subpacket), 
then base32 the subsequent 100 bits for a 20-character fingerprint (with 
120-bit security level).

Maybe that's too weird to be standardized, but at least it could be grafted 
on easily.  I.e., a key could be known by a standard 40 or 64-character 
fingerprint, as well as a 20-character fingerprint in communities that 
support that extension.

Trevor 

Date: Mon, 21 Feb 2005 21:16:59 +0000
From: Ian G <[email-masked]>
Organization: http://financialcryptography.com/
To: [email-masked]
Subject: Re: Some thoughts on a v5 key and why it shouldn't be a mess
Sender: [email-masked]

David Shaw wrote:

>>as long as it's a new key type anyway,
>>can it be made to somehow work-around the 160 limit of the DSA,
>>for DH/DSA keys ?
>>    
>>
>
>No.  This would break compatibility with v4 keys where the 160-bit
>limit still exists.
>
>If/when a new DSA is defined with different semantics, OpenPGP can
>support that in addition to the current DSA, but the new DSA cannot
>replace the old one.  Either way, it's not really a v5 specific thing,
>as a new DSA can just as easily be used in v4 (again, without
>replacing the current DSA).
>  
>

Yes, I agree.  DSA is quite highly defined, better
to leave it alone and suffer its shortfalls for now.
Some time in the future, NIST will design a DSA-2,
and that can be added.  For now, if DSA is considered
too dodgy then RSA could be used.

iang

-- 
News and views on what matters in finance+crypto:
        http://financialcryptography.com/

From: Konrad Rosenbaum <[email-masked]>
To: [email-masked]
Subject: Re: SHA-1 broken
Date: Mon, 21 Feb 2005 20:57:07 +0100
Sender: [email-masked]

--nextPart5843842.TODgaey7Pn
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Thursday 17 February 2005 11:39, Werner Koch wrote:
> We should really start thinking on how to switch to a different hash
> algorithm.  The question is whether sha-256 is really that much more
> secure.  From my understanding it has not been developed as a
> replacement for SHA-1 but to meet the requirements of AES and to
> extend DSA.

How would SHA-256 extend DSA? DSA uses a q of 160 bit(*), which limits the=
=20
implementation to any hash that delivers 160 bits or cutting the hash back=
=20
to 160 bit.

As long as we still allow any hash to be used with DSA one can attempt a=20
downgrade attack by altering the signature to use SHA-1 and then try to=20
find a fitting text(**).

Or would that create a DSA-2 which uses a q of 256 bit?=20
How large would p be then?
Would that DSA-2 get a new Algorithm-ID or is the q of 256 bit indicator=20
enough?

(*)apart from the p of 1024 bit
(**)yes, I know 2^69 is still a lot of computation and the attack wasn't=20
about finding a duplicate for a specific message, but....

	Konrad

--nextPart5843842.TODgaey7Pn
Content-Type: application/pgp-signature

--nextPart5843842.TODgaey7Pn--

Date: Mon, 21 Feb 2005 19:52:31 +0000
From: Ian G <[email-masked]>
Organization: http://financialcryptography.com/
To: David Shaw <[email-masked]>
CC: [email-masked]
Subject: Re: Some thoughts on a v5 key and why it shouldn't be a mess
Sender: [email-masked]

David Shaw wrote:

>I also suggest that this not be a part of 2440bis.  The v5 discussions
>will undoubtedly take a while, and delaying 2440bis for an unknown
>(but probably long) period of time seems a shame.
>  
>

As long as we are all agreed on that, I'm quite
keen to support a parallel track on new cleaned
up layouts.

What is the current status of 2440bis, BTW?

Is there a list of "things that must be complete" ?

It seems that every time we go around in a review
phase, another dozen minor fixes get proposed,
adopted, and then we start again!

At what point do we declare diminishing returns
to reviews?

iang

-- 
News and views on what matters in finance+crypto:
        http://financialcryptography.com/

Date: Mon, 21 Feb 2005 14:44:05 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Some thoughts on a v5 key and why it shouldn't be a mess
Mail-Followup-To: [email-masked]
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

On Mon, Feb 21, 2005 at 10:52:05AM -0800, [email-masked] wrote:
> 
> 
> 
> On Mon, 21 Feb 2005 09:11:31 -0800 David Shaw 
> <[email-masked]> wrote:
> 
> [...]
> 
> > the v5 key idea.
> 
> >It's
> >more of a "design v5 in 2005, because we need it a few years from
> >now".  
> 
> [...]
> 
> >Anyway, this is a starting point.  
> 
> >suggestions
> 
> 
> as long as it's a new key type anyway,
> can it be made to somehow work-around the 160 limit of the DSA,
> for DH/DSA keys ?

No.  This would break compatibility with v4 keys where the 160-bit
limit still exists.

If/when a new DSA is defined with different semantics, OpenPGP can
support that in addition to the current DSA, but the new DSA cannot
replace the old one.  Either way, it's not really a v5 specific thing,
as a new DSA can just as easily be used in v4 (again, without
replacing the current DSA).

David

Date: Mon, 21 Feb 2005 10:52:05 -0800
To: [email-masked]
Cc: 
Subject: Re: Some thoughts on a v5 key and why it shouldn't be a mess
From: <[email-masked]>
Sender: [email-masked]

On Mon, 21 Feb 2005 09:11:31 -0800 David Shaw 
<[email-masked]> wrote:

[...]

> the v5 key idea.

>It's
>more of a "design v5 in 2005, because we need it a few years from
>now".  

[...]

>Anyway, this is a starting point.  

>suggestions

as long as it's a new key type anyway,
can it be made to somehow work-around the 160 limit of the DSA,
for DH/DSA keys ?

vedaal

Concerned about your privacy? Follow this link to get
secure FREE email: http://www.hushmail.com/?l=2

Free, ultra-private instant messaging with Hush Messenger
http://www.hushmail.com/services-messenger?l=434

Promote security and make money with the Hushmail Affiliate Program: 
http://www.hushmail.com/about-affiliate?l=427

Date: Mon, 21 Feb 2005 12:11:31 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Some thoughts on a v5 key and why it shouldn't be a mess
Mail-Followup-To: [email-masked]
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

I had around 10 hours in a car this weekend, which gave me a good bit
of time to think some more about the v5 key idea.

I don't see this as a "drop everything and do v5" suggestion.  It's
more of a "design v5 in 2005, because we need it a few years from
now".  Attacks only get better, and if we want to be able to shrug off
a future SHA-1 break like we were able to shrug off the MD5 break, we
need to start the process.  While this is prompted by the SHA-1
problems, note that NIST was already replacing SHA-1 with the SHA-2
family by 2010 for size reasons.  Even if the recent SHA-1 problems
hadn't happened, I'd still think it was time to start designing a v5
key.

I don't think there needs to be a lot of fear over a version number
bump.  To be sure, the change from v3 to v4 was disruptive.  In one
step, the packet format, the default symmetric cipher, and the
public-key algorithm was changed.  Even the concept of a key was
altered by adding subkeys.  I'm not criticizing - the changes were
necessary for many reasons, but unfortunately they also split the user
base into "before" and "after", with interoperability problems between
the two groups.  In some (occasionally frustrating) corners, the
change hasn't even happened yet.

I don't see the change from v4 to v5 being nearly as disruptive as the
v3 to v4 change.  The straw proposal I'm putting forth here is an
incremental change over v4, large enough to be worth doing, small
enough that if the change is done carefully, it should be painless.
v4 and the proposed v5 can also quite happily co-exist without anyone
noticing or caring.  Note that I'm not talking about making a v5
signature at this point.

Here is a proposed packet format for a v5 key, interspersed with
comments.  Obviously, not every detail is given, but the general ideas
should be clear:

     - A one-octet version number (5).

     - A one-octet hash algorithm number.

This is an attempt to balance Jon's comments about 160 bits being all
that a human user can handle for a fingerprint, and the desire to not
be locked to SHA-1 in case of future trouble.  Essentially you set
this value to the fingerprint hash you want to use for this key.  The
value itself is hashed into the fingerprint (and signatures on the
key), so it cannot be changed once the key is generated.  Is is
possible for different v5 key fingerprints to be of different lengths.
A v5 fingerprint is written "algo - colon - data", like 2:12 34 56 78
9A BC DE F0 ...(etc).  The v5 keyid concept is the same as v4: the
keyid is the lower 32 or 64 bits of the fingerprint, however long it
may be.

There are some problems with this idea, not least that any
implementation that doesn't understand the hash algorithm won't be
able to use the key.  It may well be better to lock this value to
SHA-256 and be done with it.

     - A two-octet scalar octet count for the following 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 subpackets.

     - Subpacket data.

Yes, v5 keys have subpackets.  It's a bit of future-proofing since it
is a lot easier to add a subpacket than it is to go to a v6 key
format.  Note that there are no "unhashed" subpackets here.  All
subpackets are hashed into the fingerprint, and therefore are fixed at
key generation time.  The subpacket numbers do not need to be the same
as signature subpackets, but the encoding format is the same, and the
critical bit has the same meaning here as it does for signatures.

Only one subpacket comes to mind at the moment, and that is:

      Expiration time
      (4 octet time field)

      The validity period limit of the key.  This is the number of
      seconds after the key creation time that the key must expire by.
      If this is not present or has a value of zero, the key has no
      hard expiration.

This gives a "hard" expiration time which cannot be extended, unlike
the current "soft" expiration in v4.  There were a number of
disagreements over the v4 soft expirations, and while it's an
interesting discussion, at the end of the day there are good reasons
to support both.  In practice, this key subpacket sets a hard limit on
the lifetime of a key, and any soft expirations can only affect the
lifetime of the key up to that hard point.  No hard expiration acts
just like v4.  Users can mix the two to give whatever semantics they
want.

     - A four-octet number denoting the time that the key was created.

This might be better as a subpacket, but then implementers would have
to deal with the case if it was missing.

     - A one-octet number denoting the public key algorithm of this
     key.

     - A series of multiprecision integers comprising the key
     material.

Same as v4.  There is no need to change MPIs around.  There are only
so many ways to store large numbers in a row.

The v5 secret keys, like the v4 secret keys, are the same as the
public key with the secret material appended.

An additional change, which is not part of the key packet format is
that v5 keys have AES as both their "last resort" and "must implement"
ciphers.  When encrypting to v4 and v5 keys together, the default
cipher is 3DES.  One way to look at this is that cipher preferences on
a v5 key have "AES, 3DES" implicitly at the end if not explicitly used
earlier.  When combined with the implicit "3DES" already at the end of
a v4 preference list, the right thing will happen automatically.  Note
that while AES is the "must" cipher for v5, implementations that
support v4 keys must also implement 3DES.

To make the transition from v4 to v5 as invisible as possible, I'd
suggest having read support for this in implementations for as long as
possible (say, 1 year) before allowing users to create these keys.
This gives time for upgrading (and there will be a certain amount of
upgrading for other reasons during that time as well, which the v5
keys can be included with), and for various other processes that
interact with OpenPGP like keyservers to be updated.

I also suggest that this not be a part of 2440bis.  The v5 discussions
will undoubtedly take a while, and delaying 2440bis for an unknown
(but probably long) period of time seems a shame.

Anyway, this is a starting point.  Please thow darts and make
suggestions.

David

To: Ben Laurie <[email-masked]>
Cc: Jon Callas <[email-masked]>, OpenPGP <[email-masked]>
Subject: Re: Mandatory Algorithm Changes?
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[email-masked]
Date: Mon, 21 Feb 2005 15:09:59 +0100
Sender: [email-masked]

On Mon, 21 Feb 2005 12:18:10 +0000, Ben Laurie said:

> Sorry, not very well today, and it seems not thinking straight. So why
> is there an issue with compatibility?

This happens as soon as you switch your software without updating all
copies of your public key.  In particular downgrading the software is
troublesome but also upgrading sometimes (e.g. Tiger/192 has been
removed).  You might also have two different applications using the
same keypair.

For the average user the preferences work.

Shalom-Salam,

   Werner

Date: Mon, 21 Feb 2005 12:18:10 +0000
From: Ben Laurie <[email-masked]>
To: Werner Koch <[email-masked]>
Cc: Jon Callas <[email-masked]>, OpenPGP <[email-masked]>
Subject: Re: Mandatory Algorithm Changes?
Sender: [email-masked]

Werner Koch wrote:
> On Mon, 21 Feb 2005 09:23:28 +0000, Ben Laurie said:
> 
> 
>>Oops. What I said was that this seems like a candidate for having
>>flags in the PGP certificates that say what is supported by the
>>receiving application(s).
> 
> 
> Sorry, I don't understand this.  We do have these preferences since
> the very beginning.

Sorry, not very well today, and it seems not thinking straight. So why 
is there an issue with compatibility?

BTW, I see that 5.2.3.7. says "It is assumed that only algorithms listed 
are supported by the recipient's software" but this language is not 
carried forward into 5.2.3.8/9. In fact 5.2.3.9 explicitly rules out 
indicating what exactly is supported ("...the key holder's software 
might have no compression software").

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

To: Ben Laurie <[email-masked]>
Cc: Jon Callas <[email-masked]>, OpenPGP <[email-masked]>
Subject: Re: Mandatory Algorithm Changes?
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[email-masked]
Date: Mon, 21 Feb 2005 12:03:44 +0100
Sender: [email-masked]

On Mon, 21 Feb 2005 09:23:28 +0000, Ben Laurie said:

> Oops. What I said was that this seems like a candidate for having
> flags in the PGP certificates that say what is supported by the
> receiving application(s).

Sorry, I don't understand this.  We do have these preferences since
the very beginning.

Salam-Shalom,

   Werner

Date: Mon, 21 Feb 2005 09:23:28 +0000
From: Ben Laurie <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: OpenPGP <[email-masked]>
Subject: Re: Mandatory Algorithm Changes?
Sender: [email-masked]

Jon Callas wrote:
> 
> Mandatory-to-implement does not mean mandatory-to-use.
> 
> If we change 3DES to AES, things don't instantly stop working. If we do 
> that, 3DES would be a SHOULD, of course, and there will be a note that 
> says that if you don't implement 3DES there could be interoperability 
> issues.
> 
> I don't think that any reasonable implementor is going to run right out 
> and code stupidly. It will obviously take a couple of years before 
> someone can safely assume, for example, that the 
> algorithm-of-last-resort would be AES.
> 
> However, if we ever want to roll 3DES over to AES, we have to start 
> sometime. The couple of years of bake-in doesn't start until a change is 
> made. Why not now?
> 
> I'm willing to concede the point on SHA-256, I wouldn't have brought it 
> up at all if NIST hadn't said a couple days ago they're phasing out 
> SHA-1 and rolling to SHA-256.

Oops. What I said was that this seems like a candidate for having flags 
in the PGP certificates that say what is supported by the receiving 
application(s).

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

Date: Sun, 20 Feb 2005 18:44:42 +0000
From: Ben Laurie <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: OpenPGP <[email-masked]>
Subject: Re: Mandatory Algorithm Changes?
Sender: [email-masked]

To: [email-masked]
Cc: [email-masked]
Subject: Re: SHA-1 broken
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[email-masked]
Date: Fri, 18 Feb 2005 17:43:29 +0100
Sender: [email-masked]

On Fri, 18 Feb 2005 16:27:04 +0100, aboietf  said:

> 3 of the newspaper mailing lists I am on (IIRC, it was on the Heise
> Newsticker, the PC WELT newslist and the "focus.de"-newsreport).

Come on, not even semi-professionals would take PC WELT or that
general new magazine (focus) seriously. 

> Hmh - for GnuPG the article may not have been a problem as it clearly
> stated that end users doing manual decryption are _not_ susceptible to
> the attack.

GnuPG is used in many gateways and AFAIK you are also using it.

> So the article contains clear statements that crypto gateways
> which use OpenPGP and do automatic decryption, are susceptible to
                                                     ^^^^^^^^^^^
                                                     !!!!!!!!!!!
> the attack (and thus "broken").

> Aside from costing me time to explain the facts to every concerned
> customer, this situation is not very nice for our company. We

That is what service is about; explain your clients whether this is a
problem for them or not.

> if Jon writes that the OpenPGP protocol is going to be changed due to
> a discovery, than this means to a journalist that the discovery must
> be "a really important security flaw or else no one would bother to

Better to tell people about potential weaknesses than to shift them
under the carpet.  And well, from a commercial POT you get free
advertising due to such things.  There is even no competitor who does
it better - so why bother?

Anyway, such political or economic discussion is IMHO out of scope for
the WG. Feel free to use gnupg-users@ or similar to continue.

Shalom-Salam,

   Werner

Date: Fri, 18 Feb 2005 16:05:08 +0000
From: Ian G <[email-masked]>
Organization: http://financialcryptography.com/
To: Rick van Rein <[email-masked]>
CC: Jon Callas <[email-masked]>, Hal Finney <[email-masked]>, David Shaw <[email-masked]>, [email-masked]
Subject: Re: Hash Collision Shield (subpacket def)
Sender: [email-masked]

Rick van Rein wrote:

>>>I think we should not do this for several reasons, but those reasons
>>>don't matter much: we already have signature notations.
>>>      
>>>
>
>Indeed, that would be the other way of doing it.  The likeliness of
>implementations actually using it is less if they are not confronted with
>the technique though.  Is it an idea to add a bit under the notation data
>section instead?  I'm volunteering.
>  
>

If there is a way to do it already, then that
would be better than any changes.  We have
tried (ok, some of have tried) to take a razor
to OpenPGP and cut off many bows and frills.
Adding another little feature without a clear
need faces an uphill battle.

Adding a note that a notation packet could
be used as an anti-collision technique seems
like a fine idea.  As it's somewhat forward
thinking, I'm not sure where it would go tho,
possibly in the last section of security oddments?

Also, there is a discussion going on here:

http://www.educatedguesswork.org/movabletype/archives/2005/02/next_steps_for_1.html

where Craig Hughes / Dan Simon claim that
introducting random hashing increases collision
resistence, but at the expense of decreasing
other forms of resistence.

>I could never agree to such a strong break in compatibility; also
>because it would be an optional extension and lead to less complete
>implementations breaking on it.
>  
>

Yup!  It's really tough adding in little quirks
at this stage.

iang

-- 
News and views on what matters in finance+crypto:
        http://financialcryptography.com/

Subject: Re: SHA-1 broken
From: [email-masked]
To: [email-masked]
Date: Fri, 18 Feb 2005 16:27:04 +0100
Sender: [email-masked]

Werner Koch <[email-masked]> wrote on 18 Feb 2005:

 >I only know the Heise report (ct magazine and the most known IT news
 >ticker). [...]

I received articles about the alleged "security flaw in OpenPGP" on
3 of the newspaper mailing lists I am on (IIRC, it was on the Heise
Newsticker, the PC WELT newslist and the "focus.de"-newsreport).

I did not check on how many other channels similar articles were
published, as I was too busy answering phone calls and mails from
concerned customers of our crypto gateway, who wanted to know whether
our product was now "broken" or still safe.

The effect was obvious to feel: Our customers were concerned, and if
so many customers contact us, I can imagine how many potential
customers (who don't contact us) are shying away from the idea of
using automatic encryption/decryption due to those articles.

 >Their article didn't talk about a practical attack or
 >spread panic [...] The article was quite okay.

Hmh - for GnuPG the article may not have been a problem as it clearly
stated that end users doing manual decryption are _not_ susceptible to
the attack.

But imagine being in my position, i.e. the manufacturer of a product
that automatically encrypts/decrypts mail using the OpenPGP protocol.
Let me quote from the "quite okay" article that was published on
14 Feb 2004 at 13:17:

"Weakness in OpenPGP: Serge Mister and Robert Zuccherato ... have
detected a weakness in the open crypto protocol OpenPGP which has the
effect that on systems which automatically decrypt, the clear text can
be calculated [by an attacker]. ... At risk are those systems that
automatically decrypt encrypted messages. ... The crypto community is
considering to modify the OpenPGP protocol due to this weakness."

So the article contains clear statements that crypto gateways
which use OpenPGP and do automatic decryption, are susceptible to
the attack (and thus "broken").

Aside from costing me time to explain the facts to every concerned
customer, this situation is not very nice for our company. We
pioneered the crypto gateway idea more than 5 years ago (see e.g.
"www.redtenbacher.de/signatur/index.htm") and I personally did a lot
of lecturing and article writing to spread the idea of automatic
encryption/decryption via a gateway. Now the press writes that the
very basis of our security products is allegedly "broken".

Therefore, let us be aware that journalists are no crypto experts and
can easily misunderstand statements even if the original article (by
Jon et al.) was technically correct. If a journalist reads words like
"security weakness" or "broken", they just publish that "fact" without
bothering to differentiate who exactly is susceptible to the risk. And
if Jon writes that the OpenPGP protocol is going to be changed due to
a discovery, than this means to a journalist that the discovery must
be "a really important security flaw or else no one would bother to
change the protocol"! That is the simple mind of the press, and we
should take this into account when making public announcements.

- Wolfgang Redtenbacher

---------------------------------------------------------------------
Redtenbacher Software                Tel.:   +49 7159 17046
Roemerstr. 11/1                      Fax:    +49 7159 17047
D-71272 Renningen                    e-mail: [email-masked]
---------------------------------------------------------------------

Date: Fri, 18 Feb 2005 13:35:05 +0000
From: Ian G <[email-masked]>
Organization: http://financialcryptography.com/
To: Ingo Luetkebohle <[email-masked]>
CC: [email-masked]
Subject: Re: SHA-1 broken
Sender: [email-masked]

Ingo Luetkebohle wrote:

>On Fri, 2005-02-18 at 13:02 +0100, Werner Koch wrote:
>  
>
>>We should however not kick out SHA-1 from all places where it is now
>>used and replace it by SHA-256 before we understand the new attack.
>>    
>>
>
>Hmm, maybe this is stupid and it is definetely more effort
>computationally, but what about using several hashing methods
>simultaneously, mandating that all hashes have to check out?
>  
>

Scientifically, it's very hard to show that that
is an improvement in and of itself.  If the two
(or more) hashes are similar, there is no real
expectation that their security is improved.
For example, MD5 and SHA-1 are both attacked
by the same techniques, so combining them
isn't going to give any definitive advantage.

And, if one of the hashes is much stronger,
then just use that.  I.e., if we were to use both
SHA-2 and SHA-1 then in almost all circumstances,
the security of SHA-2 would dominate that of
SHA-1, so there is little point in using the latter.

Also, there is one bad side:  complexity.  The
addition of complexity is always a 'bad' as it
introduces the possibility of wierd effects.
Think of it this way, if the algorithm delivers
TRUE if (n-1) of n hashes deliver TRUE, then
we have the possibility of implementation
bugs that muck up the checking in some way
and returning TRUE on 0.

iang

PS: there is a new cryptosystem called ciphire
(sp?) that does precisely that:  it uses two
algorithms everywhere, in different ways.
Looks great on paper now, but what happens
in 3 years time when they have to replace
half the algorithms?

-- 
News and views on what matters in finance+crypto:
        http://financialcryptography.com/

Subject: Re: SHA-1 broken
From: Ingo Luetkebohle <[email-masked]>
To: Werner Koch <[email-masked]>
Cc: "\"Hal Finney\"" <[email-masked]>, [email-masked]
Date: Fri, 18 Feb 2005 13:26:55 +0100
Sender: [email-masked]

On Fri, 2005-02-18 at 13:02 +0100, Werner Koch wrote:
> We should however not kick out SHA-1 from all places where it is now
> used and replace it by SHA-256 before we understand the new attack.

Hmm, maybe this is stupid and it is definetely more effort
computationally, but what about using several hashing methods
simultaneously, mandating that all hashes have to check out?

regards

-- 
Ingo

Date: Fri, 18 Feb 2005 12:25:37 +0000
From: Ian G <[email-masked]>
Organization: http://financialcryptography.com/
To: [email-masked]
CC: Jon Callas <[email-masked]>, [email-masked], Adam Shostack <[email-masked]>
Subject: The oracle weakness and the art of disclosure
Sender: [email-masked]

Jon Callas wrote:

> I think it would have been less helpful, however, to do as a different 
> organization did the previous week over a botched IV. They said that 
> it wasn't worth fixing and no one needs that anyway and there was a 
> storm of press over here.

I personally hated the announcement ... BUT ...

It is what we should be doing.  I base this remark on
a research line in economics that I've picked up over
the last year, inspired by Adam Shostack's question
of "what is a security signal?"  This has led me to
question "what is security?"  Between the two of us
and with help from others, we've been gradually
forming an idea about what economics has to say
about all this.

The upshot is that the disclosure of weaknesses is
highly recommended.  It turns out, and I think we can
show this in economics terms, that disclosing the
protocol's weaknesses in clear and obvious detail
is a good security signal.

Now, back in the real world, many protocols and
security systems simply don't do that.  So I think
there is going to be a period of adjustment, where
those that disclose in glorious and self-flagellating
terms will be leading the others, in many senses.

iang

-- 
News and views on what matters in finance+crypto:
        http://financialcryptography.com/

To: [email-masked] ("Hal Finney")
Cc: [email-masked]
Subject: Re: SHA-1 broken
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[email-masked]
Date: Fri, 18 Feb 2005 13:02:31 +0100
Sender: [email-masked]

On Thu, 17 Feb 2005 16:49:27 -0800 (PST), "Hal Finney" said:

> alternative views that SHA-1 is just fine and/or that SHA-2 is no better.
> I don't think SHA-1 is just fine and I do think that SHA-2 is better.
> Where we go with that is still open for discussion.

I agree with your reasoning. 

We should however not kick out SHA-1 from all places where it is now
used and replace it by SHA-256 before we understand the new attack.
If we recall the DES development, the NSA knew techniques which got
invented in open research only years later.  Hopefully that is the
case with SHA-2 too.

Shalom-Salam,

   Werner

To: [email-masked]
Cc: [email-masked]
Subject: Re: SHA-1 broken
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[email-masked]
Date: Fri, 18 Feb 2005 12:51:54 +0100
Sender: [email-masked]

On Fri, 18 Feb 2005 00:39:16 +0100, aboietf  said:

> proper handling for the publication of the "oracle attack" would have
> been to point out that no mail application based on OpenPGP was
> susceptible to the circumstances of the attack, and that implementing

We don't know.

> an "oracle" is considered a Really Stupid Thing (TM).

The sad thing is that oracles are very common.  On the positive side
you have the fact that people don't interpret error messages properly
because that is too much work and just return a Bollean value - by
that they defeat this particular attack (maybe except for LANs).

> never relevant to the reality of e-mail applications. If a recipient
> is so stupid as to send me back thousands of "I can't read your mail"

Heise clearly pointed out that the attack won't work for attended
usage.

Salam-Shalom,

   Werner

To: Jon Callas <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: SHA-1 broken
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[email-masked]
Date: Fri, 18 Feb 2005 12:46:49 +0100
Sender: [email-masked]

On Thu, 17 Feb 2005 17:46:54 -0800, Jon Callas said:

> I'm sorry that the German press was so twitchy about it. I sent

I only know the Heise report (ct magazine and the most known IT news
ticker).  Their article[1] didn't talk about a practical attack or
spread panic - don't known about the trolls on their forum; I don't
read that.  The article was quite okay.  They even didn't call me -
what they usually do if there are OpenPGP or GnuPG problems.

Shalom-Salam,

   Werner

[1] http://www.heise.de/pda/newsticker/m56350.html

To: [email-masked]
Path: not-for-mail
From: Lutz Donnerhacke <[email-masked]>
Newsgroups:  iks.lists.ietf-open-pgp
Subject:  Re: SHA-1 broken
Date: Fri, 18 Feb 2005 08:30:49 +0000 (UTC)
Organization:  IKS GmbH Jena
Lines: 25
NNTP-Posting-Host: taranis.iks-jena.de
NNTP-Posting-Date: Fri, 18 Feb 2005 08:30:49 +0000 (UTC)
Sender: [email-masked]

* Jon Callas wrote:
> A key fingerprint is little more than a hash of the key material, the 
> creation time, and a few constants. There's very little place in there 
> to manufacture a collision. Fingerprints need little more than 
> one-way-ness.

IBTD, sorry.

The recent attack allows to construct two "random" messages differing in
some (few) bits generating the same hash.

So a possible attack might be to generate such a collision and search one of
the messages in existing key material from the key servers. If some key was
found containing one of those sequences, it can be replaced by a different
key by changing those few bits.

This manipulation does not change the fingerprint and might not change the
key signature nor the user certificates, so the modified key is a drop in
replacement for the old one.

The main advantage for the attacker is, that the modified key might be easily
factorised. Very likely. So the attacker can mount a MITM attack using the
web of trust to hide it.

Bad news.

Date: Fri, 18 Feb 2005 08:56:00 +0100
From: Rick van Rein <[email-masked]>
Subject: Re: Hash Collision Shield (subpacket def)
To: Jon Callas <[email-masked]>, Hal Finney <[email-masked]>
Cc: David Shaw <[email-masked]>, [email-masked]
Sender: [email-masked]

Hello,

Jon and David said a similar thing:

> >I think we should not do this for several reasons, but those reasons
> >don't matter much: we already have signature notations.

Indeed, that would be the other way of doing it.  The likeliness of
implementations actually using it is less if they are not confronted with
the technique though.  Is it an idea to add a bit under the notation data
section instead?  I'm volunteering.

> However, I also think this is a very bad idea. We already have pulled 
> things out of OpenPGP because they could be used for subliminal 
> channels,

This is definately the weak point of this strategy, as said in the header.
It applies equally to notation data encoding, of course.
But it it does seem to be the only way to make durable signatures.

Hal liked the idea but pointed out that collisions might have occurred
before the random data was hashed,  Actually that is such a strong downer
that I am now wondering what the added value of this approach would be.

> But we could specify it to work this way: we'd have a subpacket with
> the random data, and its meaning is that this stuff gets hashed first
> when we do the signature calculation.  We'd be changing the rules for
> how signatures are calculated.

I could never agree to such a strong break in compatibility; also
because it would be an optional extension and lead to less complete
implementations breaking on it.

Thanks,
 -Rick

From: Konrad Rosenbaum <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: SHA-1 broken
Date: Fri, 18 Feb 2005 08:16:37 +0100
Sender: [email-masked]

--nextPart2937758.2gYUIBvpJC
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Thursday 17 February 2005 21:18, [email-masked] wrote:
> The recent announcement of Jon Callas et al. was - in my eyes - not
> helpful at all. It solved a non-existing problem (not one single
> existing OpenPGP implementation suffered from the "oracle" effect),
> and the result in the media (at least in Germany) was rather
> catastrophic: Even the (normally pretty conservative) Heise Verlag
> published panic articles that "all automatic encrypt/decrypt systems
> based on OpenPGP are broken"!

Since when is the Heise Newsticker "pretty conservative"? If they can draw=
=20
attention to their website they will do it.=20

You're free to contact them and ask for an update of that article... ;-)

	Konrad

--nextPart2937758.2gYUIBvpJC
Content-Type: application/pgp-signature

--nextPart2937758.2gYUIBvpJC--

From: Konrad Rosenbaum <[email-masked]>
To: [email-masked]
Subject: Re: SHA-1 broken
Date: Fri, 18 Feb 2005 07:59:19 +0100
Sender: [email-masked]

--nextPart2173628.TG4jFkyWuK
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Thursday 17 February 2005 15:00, David Shaw wrote:
> I don't think it's all that easy to just add options to the
> fingerprint.  Let's say you specified a fingerprint (which is
> currently just HASH) with ALGO:HASH.  So, my current (SHA-1)
> fingerprint would be:
>
>   2:7D92FD313AB6F3734CC59CA1DB698D7199242560
>
> Simple enough, but my fingerprint would also be (MD5):
>
>   1:B9E4614F2E6FACD8F5DD32010AC50AAC
>
> and even (SHA-512):
>
> =20
> 10:00C2C9BBF4AC3AD6D45275C041E1EE88AA6B0564F227AD4FBE0F7BBE845B8B47342A94
>1A88384A79CFC0858572DCDE326AC21625D7822B2102CA3857669C381B
>
> Allowing multiple representations of the fingerprint allows for all
> sorts of problems where an attacker can force a particular hash
> algorithm.  There is even a warning about this attack (in the context
> of signatures) in the draft.
[cut]
> Rather than trying to jury-rig something together to allow using other
> hashes, I think I would rather just declare a V5 key format (which can
> be essentially the same as V4), which uses a different hash.

Why not do both?

If the hash ID used for the fingerprint is part of the key format and=20
consequently hashed together with the key then there shouldn't be much of=20
an attack vector left. The only one who can enforce a certain hash to be=20
used is the key owner, if anybody else tries it ultimately changes the=20
fingerprint.

	Konrad

--nextPart2173628.TG4jFkyWuK
Content-Type: application/pgp-signature

--nextPart2173628.TG4jFkyWuK--

Cc: OpenPGP <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: draft-ietf-openpgp-rfc2440bis-12 5.2.3
Date: Thu, 17 Feb 2005 18:37:45 -0800
To: Ben Laurie <[email-masked]>
Sender: [email-masked]

On 16 Jan 2005, at 6:32 AM, Ben Laurie wrote:

> in 5.2.3, there was:
>
>      - Hashed subpacket data set.
>
>      - Unhashed subpacket data set.
>
> and in 5.2.3.1:
>
> A subpacket data set consists of zero or more signature subpackets, 
> preceded by a two-octet scalar count of the length in octets of all 
> the subpackets; a pointer incremented by this number will skip over 
> the subpacket data set.
>

Done.

	Jon

Cc: OpenPGP <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: Comments on draft-ietf-openpgp-rfc2440bis-12
Date: Thu, 17 Feb 2005 18:32:07 -0800
To: Ben Laurie <[email-masked]>
Sender: [email-masked]

On 15 Jan 2005, at 12:54 PM, Ben Laurie wrote:

>
> 3.2 (MPI) doesn't specify what the unused bits should be set to. This 
> may be deliberate but I think it should either say they MUST be zero 
> (which I prefer) or that their content is unspecified.
>
> 4.2 refers to Content Tags, but 4.3 calls them Packet Tags.
>

Both of these are fixed.

	Jon

Cc: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Hash Collision Shield (subpacket def)
Date: Thu, 17 Feb 2005 18:23:03 -0800
To: David Shaw <[email-masked]>
Sender: [email-masked]

On 17 Feb 2005, at 9:17 AM, David Shaw wrote:

> I think we should not do this for several reasons, but those reasons
> don't matter much: we already have signature notations.  If someone
> wants to add arbitrary stuff in the middle of their signatures, they
> can do that now.
>

I agree completely. Notations are the way to do this.

However, I also think this is a very bad idea. We already have pulled 
things out of OpenPGP because they could be used for subliminal 
channels, and there are a lot of people who think that DSA is the work 
of Satan because it has random data and thus subliminal channels.

However, if someone wishes to add in extra random data, then a notation 
is a fine way to do it.

	Jon

To: [email-masked], [email-masked]
Subject: Re: Hash Collision Shield (subpacket def)
Date: Thu, 17 Feb 2005 17:51:11 -0800 (PST)
From: [email-masked] ("Hal Finney")
Sender: [email-masked]

This hash collision shield is an interesting idea, but to work the random
data has to be hashed first, before the other data that is signed.
Otherwise if the data being signed is hashed first, and it has a
collision, the collision will still be valid when the random data is
hashed later.  That's because of how these hash functions work.

But we could specify it to work this way: we'd have a subpacket with
the random data, and its meaning is that this stuff gets hashed first
when we do the signature calculation.  We'd be changing the rules for
how signatures are calculated.  We could set the critical bit on the
subpacket to indicate that the sig won't be verifiable by software which
doesn't recognize that subpacket type.  We could even put the subpacket
into the unhashed region since there is no reason to hash it again.
OTOH it doesn't hurt to do so.

There are some down sides to putting random data into signatures.  See
http://www.educatedguesswork.org/movabletype/archives/2005/02/next_steps_for_1.html
for some discussion of the pros and cons.

Hal Finney

Cc: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: SHA-1 broken
Date: Thu, 17 Feb 2005 17:46:54 -0800
To: [email-masked]
Sender: [email-masked]

On 17 Feb 2005, at 12:18 PM, [email-masked] wrote:

> The recent announcement of Jon Callas et al. was - in my eyes - not
> helpful at all. It solved a non-existing problem (not one single
> existing OpenPGP implementation suffered from the "oracle" effect),
> and the result in the media (at least in Germany) was rather
> catastrophic: Even the (normally pretty conservative) Heise Verlag
> published panic articles that "all automatic encrypt/decrypt systems
> based on OpenPGP are broken"!
>

I'm sorry that the German press was so twitchy about it. I sent 
releases to both Reuters and UPI here, and got a polite response back 
from Reuters thanking me for being so humble about it. There's not been 
a further peep on it, and I've been waiting for it. Should this ever 
happen again, I'll try to make sure that the German press isn't silly. 
I know people who can do German translations -- not that I'm expecting 
to ever have to do that again, mind you.

I think it would have been less helpful, however, to do as a different 
organization did the previous week over a botched IV. They said that it 
wasn't worth fixing and no one needs that anyway and there was a storm 
of press over here.

	Jon

To: [email-masked]
Subject: Re: SHA-1 broken
Date: Thu, 17 Feb 2005 16:49:27 -0800 (PST)
From: [email-masked] ("Hal Finney")
Sender: [email-masked]

I have a little different perspective on the new attacks, which I will
throw into the mix.  Of course everything is still very mmuch uncertain
and up in the air and we are all digesting the information.

Many people are saying, this is nothing to worry about, 2^69 is still
plenty strong, and there is no reason to stop using SHA-1.  I am not
comfortable with this.  2^69 is in a gray area.  It's not small enough
to say we absolutely have to stop using it, but it's not big enough
to say that the hash is basically as strong as before.

A reduction in strength by a factor of 2048 is the difference between
1 day and 5 years.  It's the difference between 1 month and 170 years.
Depending on how much money you have to spend, this could definitely
make the difference between a practical and an impractical attack.
And remember that the birthday attack of 2^80 also requires 2^80 memory,
which would probably dominate the costs.  We don't know the details
of the new attack but I haven't seen any indication that it requires
enormous amounts of memory.

This makes me feel pretty uncomfortable sticking with SHA-1, especially
when we do have a replacement hash that NIST (which is backed by the
NSA in these issues) was already encouraging people to transition to,
the SHA-2 family: SHA-256, SHA-384 and SHA-512.  These hashes are newer,
and they were designed with an eye to experience with SHA-1 and its
related hashes, MD5 and MD4.  They are intended to provide much greater
strength: 128 to 256 bits, compared to 80 bits for SHA-1.

This leads to another claim I'm seeing a lot of, which is that SHA-256
is just about the same as SHA-1 and will probably be just as unsafe.
I don't agree that we are in a position to make this conclusion.  MD4, MD5
and SHA-1 are a very similar family of hash functions, each one adding
a few twists and extensions to the one before.  SHA-2 is not nearly
so similar.  I don't think anyone who has studied or implemented these
functions would disagree with the claim that SHA-1 is much closer to MD5
than it is to SHA-256.  This suggests to me that you can't generalize
from the older hash functions to SHA-2.

Now, it's true that in its broad structure, SHA-2 does share commonalities
with the others.  It is basically an unbalanced feistel network structure.
But it handles the nonlinearities differently, it updates two words
each round, one in the middle and one at the end, using two sources of
nonlinearities, it mixes the bits up much more with rotates, it avoids
the use of the 16 round block structure of MD4, MD5 and SHA-1, and there
are many more differences.

We can also look at the fact that in a way, the attack just barely works
against SHA-1.  As I said, it puts us in a gray area.  SHA-1 almost
retained its full designed strength against the attack.  The additional
complexity in SHA-2 should give us even more confidence.  And SHA-2, with
a minimum strength of 128 bits, has a much greater margin against attacks.
If we took 11 bits off SHA-2 it wouldn't matter a bit.  We could lose
30 bits and it wouldn't matter.

Some people are concerned that SHA-2 hasn't received enough attention.
But don't get the impression that this is some little-known hash function
which has suddenly found itself thrust into the limelight.  These hashes
have been around for four years.  The are being put forward by the most
powerful and prominent source of cryptographic standards in the world.
People haven't ignored SHA-2.  If there is a dearth of published
attacks, it's not because nobody paid attention.  Finding a flaw in the
new standard hash algorithm of the United States government would be a
major accomplishment for a cryptographer.

Now, I'm not arguing here that we should drop all support for SHA-1 and
switch over to SHA-2.  But in my opinion, given the information presently
available, SHA-2 is a better choice for a hash function than SHA-1.
I wanted to give my reasoning because I'm seeing people promoting the
alternative views that SHA-1 is just fine and/or that SHA-2 is no better.
I don't think SHA-1 is just fine and I do think that SHA-2 is better.
Where we go with that is still open for discussion.

Hal Finney

Subject: Re: SHA-1 broken
From: [email-masked]
To: [email-masked]
Date: Fri, 18 Feb 2005 00:39:16 +0100
Sender: [email-masked]

Ian G <[email-masked]> wrote on 17 Feb 2005:

 >>Please, let us stop making any "change announcements" to the public if
 >>there is not an actual security problem to be solved!
 >
 >Well, I'm not sure anyone has made any
 >"change announcements" unless you mean
 >that recent minor oracle attack.

That is exactly what I meant: the announcement of Jon et al.
regarding the "minor oracle attack".

 >It seems that we have to go through a
 >period of actually revealing these things
 >and encouraging people not to panic.
 >
 >Elsewise we go back to the bad old days
 >where we keep all quiet.

I was not suggesting to "keep quiet" any real weaknesses. But the
proper handling for the publication of the "oracle attack" would have
been to point out that no mail application based on OpenPGP was
susceptible to the circumstances of the attack, and that implementing
an "oracle" is considered a Really Stupid Thing (TM).

The short mention in the announcement that the OpenPGP group would be
changing the protocol due to the "oracle attack publication", was
interpreted by the media as a "proof" of the fact that a serious
problem had been found - which was not the case at all. The "attack"
may have been interesting from a mathematical viewpoint, but it was
never relevant to the reality of e-mail applications. If a recipient
is so stupid as to send me back thousands of "I can't read your mail"
answers, this same user will surely be stupid enough to send me his
private PGP key + passphrase if I devise a proper social engineering
or phishing attack. So the problem here is the fact of having an
"oracle" (implemented as a stupid user or a stupid programmer) in the
first place, and lies _not_ with the protocol.

Therefore, let us solve the problem where it is, and not at some other
place!

- Wolfgang Redtenbacher

---------------------------------------------------------------------
Redtenbacher Software                Tel.:   +49 7159 17046
Roemerstr. 11/1                      Fax:    +49 7159 17047
D-71272 Renningen                    e-mail: [email-masked]
---------------------------------------------------------------------

From: Jon Callas <[email-masked]>
Subject: Re: SHA-1 broken
Date: Thu, 17 Feb 2005 14:07:10 -0800
To: OpenPGP <[email-masked]>
Sender: [email-masked]

My feeling is that a key fingerprint is the *least* of the things that 
are in danger from a SHA-1 break.

A key fingerprint is little more than a hash of the key material, the 
creation time, and a few constants. There's very little place in there 
to manufacture a collision. Fingerprints need little more than 
one-way-ness.

Furthermore, it is imperative that a fingerprint be short. The whole 
reason for having them is that they are short. All the things you want 
a fingerprint for require it being short. Twenty bytes is plenty long 
enough for one. Otherwise just get rid of the fingerprint and just 
write down the key.

	Jon

Date: Thu, 17 Feb 2005 21:13:08 +0000
From: Ian G <[email-masked]>
Organization: http://financialcryptography.com/
To: [email-masked]
CC: [email-masked]
Subject: Re: SHA-1 broken
Sender: [email-masked]

[email-masked] wrote:

>What are the actual facts behind these "SHA-1 is broken" rumours?
>Someone found a way to reduce the SHA-1 strenght by 11 binary digits.
>This has the exact same effect as if someone boosted the current
>processor speeds by a factor of 2096.
>  
>

Right now, that's about it.  It looks like
the 'padding' issue is unimportant and
the only issue is the number of bits
of reduced strength.  So I don't think
we have to change SHA-1...

>The recent announcement of Jon Callas et al. was - in my eyes - not
>helpful at all. It solved a non-existing problem (not one single
>existing OpenPGP implementation suffered from the "oracle" effect),
>and the result in the media (at least in Germany) was rather
>catastrophic: Even the (normally pretty conservative) Heise Verlag
>published panic articles that "all automatic encrypt/decrypt systems
>based on OpenPGP are broken"!
>
>So the actual effect of the announcement was that, while not fixing
>any real security problem, it seriously caused a Public Relations
>damage for crypto gateways like our "KT Mail gateway"
>(www.redtenbacher.de/info/gateway.htm) or "PGP Universal" (from PGP
>Inc.).
>
>Please, let us stop making any "change announcements" to the public if
>there is not an actual security problem to be solved!
>  
>

Well, I'm not sure anyone has made any
"change announcements" unless you mean
that recent minor oracle attack.

(off topic for the draft group...)

I would disagree in the question of making
announcements.  Recent research and
thinking has led to the notion that we have
to be very aggressive about announcing
our weaknesses and going OTT (over the
top) in how we present these weaknesses.
It seems that we have to go through a
period of actually revealing these things
and encouraging people not to panic.

Elsewise we go back to the bad old days
where we keep all quiet.

iang

-- 
News and views on what matters in finance+crypto:
        http://financialcryptography.com/

Subject: Re: SHA-1 broken
From: [email-masked]
To: [email-masked]
Date: Thu, 17 Feb 2005 21:18:18 +0100
Sender: [email-masked]

Werner Koch <[email-masked]> wrote on 17 Feb 2005:

 >We should really start thinking on how to switch to a different hash
 >algorithm.  The question is whether sha-256 is really that much more
 >secure.  From my understanding it has not been developed as a
 >replacement for SHA-1 but to meet the requirements of AES and to
 >extend DSA.

While not being opposed to David's suggestion of a potential V5 key
with AES/SHA-256, I still can't see any real need for replacing SHA-1
in the near future.

What are the actual facts behind these "SHA-1 is broken" rumours?
Someone found a way to reduce the SHA-1 strenght by 11 binary digits.
This has the exact same effect as if someone boosted the current
processor speeds by a factor of 2096.

Does this mean that any 128 bit hash gets "broken" by building a
cluster of 2096 PCs?

Let us be realistic and avoid any panic mode. Quickly announcing
changes to the OpenPGP protocol is doing us a bad service as it
undermines public trust for no good reason at all.

The recent announcement of Jon Callas et al. was - in my eyes - not
helpful at all. It solved a non-existing problem (not one single
existing OpenPGP implementation suffered from the "oracle" effect),
and the result in the media (at least in Germany) was rather
catastrophic: Even the (normally pretty conservative) Heise Verlag
published panic articles that "all automatic encrypt/decrypt systems
based on OpenPGP are broken"!

So the actual effect of the announcement was that, while not fixing
any real security problem, it seriously caused a Public Relations
damage for crypto gateways like our "KT Mail gateway"
(www.redtenbacher.de/info/gateway.htm) or "PGP Universal" (from PGP
Inc.).

Please, let us stop making any "change announcements" to the public if
there is not an actual security problem to be solved!

- Wolfgang Redtenbacher

---------------------------------------------------------------------
Redtenbacher Software                Tel.:   +49 7159 17046
Roemerstr. 11/1                      Fax:    +49 7159 17047
D-71272 Renningen                    e-mail: [email-masked]
---------------------------------------------------------------------

Date: Thu, 17 Feb 2005 14:42:05 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: SHA-1 broken
Mail-Followup-To: [email-masked]
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

On Thu, Feb 17, 2005 at 07:32:00PM +0000, Ian G wrote:
> David Shaw wrote:
> 
> >My main argument for a V5 key is that doing patch work on V4 has the
> >potential to split the installed base into "old V4" and "new V4".
> >Rather than end up like that, just call "new V4" "V5" instead.  It is
> >also an opportunity to fix the handful of little details that bug
> >people about V4: the default cipher can be AES instead of 3DES.  The
> >key expiration dates can be hard or soft (not just soft as in V4).
> >And so on.
> > 
> >
> 
> OK, so you would propose an intermediate
> "fixes lots of little things" V5.  I don't know
> what the balance between these future
> paths would be ...

What I'm trying to get at is there is no "intermediate".  The word
intermediate implies that there is some ultimate goal and this would
be a step towards it.  My argument is that there is no ultimate goal,
and shooting for one is something we can spend a lot of time arguing
over to no avail.  Without a time machine, we don't know what
cryptography will become in the future.  We can just do the best we
can with the knowledge we have, ponder where we think things are going
over the next 10 years, build in as much future proofing as we can
think of - and even then expect that eventually there will need to be
a V6.

David

Date: Thu, 17 Feb 2005 19:32:00 +0000
From: Ian G <[email-masked]>
Organization: http://financialcryptography.com/
To: David Shaw <[email-masked]>
CC: [email-masked]
Subject: Re: SHA-1 broken
Sender: [email-masked]

David Shaw wrote:

>My main argument for a V5 key is that doing patch work on V4 has the
>potential to split the installed base into "old V4" and "new V4".
>Rather than end up like that, just call "new V4" "V5" instead.  It is
>also an opportunity to fix the handful of little details that bug
>people about V4: the default cipher can be AES instead of 3DES.  The
>key expiration dates can be hard or soft (not just soft as in V4).
>And so on.
>  
>

OK, so you would propose an intermediate
"fixes lots of little things" V5.  I don't know
what the balance between these future
paths would be ...

>I don't know that this should necessarily be in 2440bis, though, or
>2440bis may never be released.
>  
>

I think if we can make an assessment that
SHA-1 is still good for another couple of
years, then we should go for it.  Sure, shove
a note in there that it's a worry, but life is
full of worries...

(Which is to say that seeing as there are
some major difficulties in replacing SHA-1
in the current structures, then we should
just shrug and move on.  No removal unless
it is absolutely necessary.)

iang

-- 
News and views on what matters in finance+crypto:
        http://financialcryptography.com/

To: [email-masked]
Subject: Re: SHA-1 broken
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[email-masked]
Date: Thu, 17 Feb 2005 20:21:44 +0100
Sender: [email-masked]

On Thu, 17 Feb 2005 13:36:38 -0500, David Shaw said:

> Rather than end up like that, just call "new V4" "V5" instead.  It is
> also an opportunity to fix the handful of little details that bug
> people about V4: the default cipher can be AES instead of 3DES.  The
> key expiration dates can be hard or soft (not just soft as in V4).

I am all in favor of this. Some time ago we even discussed that a v5
signature format would be a good idea so solve some things.  We could
even addres the back signature thing better with a new format.

> I don't know that this should necessarily be in 2440bis, though, or
> 2440bis may never be released.

More than 6 years since the last RFC so it is indeed time to have a
new one, defining what the current standard is and showing a warning
that a v5 format is being worked own.  This will give enough time to
work out the problems and analyze what's up with the hash algorithms.

Salam-Shalom,

   Werner

Date: Thu, 17 Feb 2005 13:36:38 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: SHA-1 broken
Mail-Followup-To: [email-masked]
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

On Thu, Feb 17, 2005 at 03:01:29PM +0000, Ian G wrote:
> 
> David Shaw wrote:
> 
> >Rather than trying to jury-rig something together to allow using other
> >hashes, I think I would rather just declare a V5 key format (which can
> >be essentially the same as V4), which uses a different hash.  Users
> >can continue using V4 keys as long as they desire, and developers will
> >have time to add support for V5 so it's ready when it is needed.  This
> >ties in neatly with other things recently discussed here : for
> >example, a V5 key could be said to have AES as the default algorithm.
> > 
> >
> 
> Having now read the "note" that the Shandong
> team distributed, I'm less inclined to think this
> is the end of the world.  See my blog for some
> snippets.
> 
> Declaring a need for a V5 key makes a lot of
> sense, if we believe that we can survive that
> long.  However, the first thing would be that
> I'd say a redesign of the key structure would
> be better than just a minor change to one
> element.  I don't think it's worth carring the
> costs of an entire new key structure in code
> without making it worth carrying on for the
> next N decades.

We're much in agreement, though I don't forsee any key version making
it much beyond 10-15 years.  The technology changes, and there is no
easy way to get around that.  V4 keys have lasted for around 7-8 years
now, and will likely hang on for years to come; that's a pretty good
run.  I think designing a V5 key that will last much longer than that
is not possible without a crystal ball.  The best we can do is to
design it to last as long as possible, and know that someday we'll be
making a V6 key.

My main argument for a V5 key is that doing patch work on V4 has the
potential to split the installed base into "old V4" and "new V4".
Rather than end up like that, just call "new V4" "V5" instead.  It is
also an opportunity to fix the handful of little details that bug
people about V4: the default cipher can be AES instead of 3DES.  The
key expiration dates can be hard or soft (not just soft as in V4).
And so on.

I don't know that this should necessarily be in 2440bis, though, or
2440bis may never be released.

David

Date: Thu, 17 Feb 2005 12:17:26 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Hash Collision Shield (subpacket def)
Mail-Followup-To: [email-masked]
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

On Thu, Feb 17, 2005 at 05:46:29PM +0100, Rick van Rein wrote:
> 
> Hello,
> 
> It's a bit of a long stretch perhaps...  but it is probably the simplest
> thing we can do, and it is completely backward compatible.  Suggested
> text fragments follow.
> 
> The problem of the fingerprints and other hard-coded SHA1 apps are not
> solved by this, of course.
> 
> Should we add a remark about subliminal channels caused by incorporating
> random bytes?

I think we should not do this for several reasons, but those reasons
don't matter much: we already have signature notations.  If someone
wants to add arbitrary stuff in the middle of their signatures, they
can do that now.

David

Date: Thu, 17 Feb 2005 17:46:29 +0100
From: Rick van Rein <[email-masked]>
Subject: Hash Collision Shield (subpacket def)
To: [email-masked]
Sender: [email-masked]

Hello,

It's a bit of a long stretch perhaps...  but it is probably the simplest
thing we can do, and it is completely backward compatible.  Suggested
text fragments follow.

The problem of the fingerprints and other hard-coded SHA1 apps are not
solved by this, of course.

Should we add a remark about subliminal channels caused by incorporating
random bytes?

Cheers,
 -Rick

------------ 8< ------------ 8< ------------ 8< ------------ 8< ------------

   The value of the subpacket type octet may be:

       2 = signature creation time
...
       32 = embedded signature
       33 = hash collision shield

...

4.2.3.27. Hash Collision Shield

    (N random octets)

    Hash functions are important to digital signatures, and breaking them
    means breaking a signature schema.  The first collision against hashes
    is usually the collision attack, because these are computationally the
    least expensive form of attack.

    After a collision attack to a hash algorithm, the time to come up with
    an attack that can completely reverse a given hash value is incredibly
    long.  This means that shielding against collision attacks is a very
    practical method of prolonging the secure use of hash functions.  This
    is useful for applications such as timestamps and non-revocable
    signatures, because these may have to be valid for very long periods.

    An attacker could mount a collision attack by predicting the signature
    calculation and preparing two documents with colliding hash values.
    One document would be signed by someone other than the attacker, the
    other document would be exploited with that signature attached.

    Such attacks can be avoided if the signer makes the signing process
    unpredictable to the attacker.  The simples way to do that is to
    generate random octets per signature, under full control of the signer,
    and include them in the hashed subpackets of a signature packet.

    The number of random octets SHOULD match the length of the hash used in
    the signature.  This subpacket MUST NOT be flagged as critical and MAY
    remain without interpretation in the verification process.

Date: Thu, 17 Feb 2005 15:01:29 +0000
From: Ian G <[email-masked]>
Organization: http://financialcryptography.com/
To: David Shaw <[email-masked]>
CC: [email-masked]
Subject: Re: SHA-1 broken
Sender: [email-masked]

David Shaw wrote:

>Rather than trying to jury-rig something together to allow using other
>hashes, I think I would rather just declare a V5 key format (which can
>be essentially the same as V4), which uses a different hash.  Users
>can continue using V4 keys as long as they desire, and developers will
>have time to add support for V5 so it's ready when it is needed.  This
>ties in neatly with other things recently discussed here : for
>example, a V5 key could be said to have AES as the default algorithm.
>  
>

Having now read the "note" that the Shandong
team distributed, I'm less inclined to think this
is the end of the world.  See my blog for some
snippets.

Declaring a need for a V5 key makes a lot of
sense, if we believe that we can survive that
long.  However, the first thing would be that
I'd say a redesign of the key structure would
be better than just a minor change to one
element.  I don't think it's worth carring the
costs of an entire new key structure in code
without making it worth carrying on for the
next N decades.

But, yes, V4 keys are old too.  A good point.

iang

-- 
News and views on what matters in finance+crypto:
        http://financialcryptography.com/

Date: Thu, 17 Feb 2005 09:00:10 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: SHA-1 broken
Mail-Followup-To: [email-masked]
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

On Thu, Feb 17, 2005 at 12:58:24PM +0000, Ian G wrote:
> 
> Werner Koch wrote:
> 
> >On Thu, 17 Feb 2005 09:36:08 +0000 (UTC), Lutz Donnerhacke said:
> >
> > 
> >
> >>Don't panic. This problem is already solved by allowing different
> >>hash-algorithms in the packet format. As long as no detailed examination 
> >>of
> >>   
> >>
> >
> >The fingerprint and the MDC both use SHA-1 hardwired.
> > 
> >
> 
> It would seem an easy matter to add some options
> on fingerprint.  That's something that could be
> added to the standard as a MAY and people can
> switch across if the weaknesses in SHA1 move
> across to economically exploitable status.

I don't think it's all that easy to just add options to the
fingerprint.  Let's say you specified a fingerprint (which is
currently just HASH) with ALGO:HASH.  So, my current (SHA-1)
fingerprint would be:

  2:7D92FD313AB6F3734CC59CA1DB698D7199242560

Simple enough, but my fingerprint would also be (MD5):

  1:B9E4614F2E6FACD8F5DD32010AC50AAC

and even (SHA-512):

  10:00C2C9BBF4AC3AD6D45275C041E1EE88AA6B0564F227AD4FBE0F7BBE845B8B47342A941A88384A79CFC0858572DCDE326AC21625D7822B2102CA3857669C381B

Allowing multiple representations of the fingerprint allows for all
sorts of problems where an attacker can force a particular hash
algorithm.  There is even a warning about this attack (in the context
of signatures) in the draft.

If SHA-1 is showing its age, well, that's to be expected.  It's had a
good run, but even before this new attack came to light, it was
already being phased out by NIST.

Rather than trying to jury-rig something together to allow using other
hashes, I think I would rather just declare a V5 key format (which can
be essentially the same as V4), which uses a different hash.  Users
can continue using V4 keys as long as they desire, and developers will
have time to add support for V5 so it's ready when it is needed.  This
ties in neatly with other things recently discussed here : for
example, a V5 key could be said to have AES as the default algorithm.

Note that keyservers and other programs that use OpenPGP will need to
understand whatever we do.  Not messing about with the well-understood
and widely implemented definition of V4 keys will make this easier.

David

Date: Thu, 17 Feb 2005 12:58:24 +0000
From: Ian G <[email-masked]>
Organization: http://financialcryptography.com/
To: [email-masked]
Subject: Re: SHA-1 broken
Sender: [email-masked]

Werner Koch wrote:

>On Thu, 17 Feb 2005 09:36:08 +0000 (UTC), Lutz Donnerhacke said:
>
>  
>
>>Don't panic. This problem is already solved by allowing different
>>hash-algorithms in the packet format. As long as no detailed examination of
>>    
>>
>
>The fingerprint and the MDC both use SHA-1 hardwired.
>  
>

It would seem an easy matter to add some options
on fingerprint.  That's something that could be
added to the standard as a MAY and people can
switch across if the weaknesses in SHA1 move
across to economically exploitable status.

For the MDC, that sounds more of a challenge.  I
would suspect that the call is now on for a change to
the draft to allow alternate algorithms there!  Are
there any easy ways?  Or is this a deal breaker?

Given the rapid advance of the attack by the Shandong
team we should basically expect SHA-1 to be broken
within the year.  So, I would guess within the time
frame of completing the draft, we may have to set
it up so that it is prepared for that event.

Which would mean that all uses of SHA-1 would have
an alternate.  It doesn't necessarily mean that SHA-1
changes from MUST to SHOULD.

>We should really start thinking on how to switch to a different hash
>algorithm.  The question is whether sha-256 is really that much more
>secure.  From my understanding it has not been developed as a
>replacement for SHA-1 but to meet the requirements of AES and to
>extend DSA.
>  
>

I think if all attacks are still limited by the fundamental
birthday principle, SHA-256 is likely to be safe.  What is
worrying to the academic world is the fact that the
foundation of SHA-256 is as an extended SHA-1 (which
was an extended MD5, which was....) and this entire
approach is now being subjected to reduced rounds
attacks.  Note that SHA-1 in unpadded form has lost
11 of its 80 bits.  Even if SHA-256 lost 80 of 160 bits it
would still be good!

Academic elegance does not concern us here.

If SHA-256 is big-and-ugly enough to overcome all but
the most ridiculous of birthday attacks then it will serve
our purposes .... perhaps at least for the five year interim
required for the academics to come up with the next
generation.

(Quick question - how long was it from the start of the
AES competition to the announcement?  About 4 years?)

iang

-- 
News and views on what matters in finance+crypto:
        http://financialcryptography.com/

Date: Thu, 17 Feb 2005 17:19:01 +0600
From: "Vlad \"SATtva\" Miller" <[email-masked]>
Organization: PGP in Russia (www.pgpru.com)
To: Lutz Donnerhacke <[email-masked]>
CC: [email-masked]
Subject: Re: SHA-1 broken
Sender: [email-masked]

On 17.02.05 15:36, Lutz Donnerhacke wrote:
> * Konrad Rosenbaum wrote:
> 
>> While this attack reduces SHA-1 from strength 2^80 to 2^69 and
>> 2^69 operations is still unreachably much, likelihood seems high
>> that someone will improve this attack once the paper has been
>> released.
>> 
>> Should we phase out SHA-1? But in favour of what?
> 
> Don't panic. This problem is already solved by allowing different 
> hash-algorithms in the packet format. As long as no detailed
> examination of other algorithms is available, OpenPGP should not
> change MAYs and MUSTs.

Although I agree that we must not rush, but make weighted decisions,
there is a ground for some misgivings. For instance, v4 key format
relies solely on SHA-1 for fingerprints and MDC calculation, and when
(and if) the attack in question will become more useful in practical
sense, may lead to bad results.

-- 
Respectfully yours,

 __________________________________
 Vladislav "SATtva" Miller
 "PGP in Russia" project leader
 http://www.pgpru.com

 PGP public key ID: 0x4D8BB49E
 http://www.pgpru.com/contacts/

 Email encryption and digital signing
 is highly desired. Preferred method
 is OpenPGP, otherwise S/MIME.

To: Lutz Donnerhacke <[email-masked]>
Cc: [email-masked]
Subject: Re: SHA-1 broken
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[email-masked]
Date: Thu, 17 Feb 2005 11:39:41 +0100
Sender: [email-masked]

On Thu, 17 Feb 2005 09:36:08 +0000 (UTC), Lutz Donnerhacke said:

> Don't panic. This problem is already solved by allowing different
> hash-algorithms in the packet format. As long as no detailed examination of

The fingerprint and the MDC both use SHA-1 hardwired.

We should really start thinking on how to switch to a different hash
algorithm.  The question is whether sha-256 is really that much more
secure.  From my understanding it has not been developed as a
replacement for SHA-1 but to meet the requirements of AES and to
extend DSA.

Salam-Shalom,

   Werner

To: [email-masked]
Path: not-for-mail
From: Lutz Donnerhacke <[email-masked]>
Newsgroups:  iks.lists.ietf-open-pgp
Subject:  Re: SHA-1 broken
Date: Thu, 17 Feb 2005 09:36:08 +0000 (UTC)
Organization:  IKS GmbH Jena
Lines: 10
NNTP-Posting-Host: taranis.iks-jena.de
NNTP-Posting-Date: Thu, 17 Feb 2005 09:36:08 +0000 (UTC)
Sender: [email-masked]

* Konrad Rosenbaum wrote:
> While this attack reduces SHA-1 from strength 2^80 to 2^69 and 2^69
> operations is still unreachably much, likelihood seems high that someone
> will improve this attack once the paper has been released.
>
> Should we phase out SHA-1? But in favour of what?

Don't panic. This problem is already solved by allowing different
hash-algorithms in the packet format. As long as no detailed examination of
other algorithms is available, OpenPGP should not change MAYs and MUSTs.

To: Rick van Rein <[email-masked]>
Cc: [email-masked]
Subject: Re: Timestamp and 3rd party sig
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[email-masked]
Date: Thu, 17 Feb 2005 08:29:28 +0100
Sender: [email-masked]

On Thu, 17 Feb 2005 00:12:51 +0100, Rick van Rein said:

> A topic open for debate would be whether it may be assumed that "extra" or
> "sufficient" effort has been taken to guard and/or synchronise the time
> encapsulated.  In line with the intention of 0x10..0x13 I left this out

That would again put definitions of trust into the protocol.  OpenPGP
has always abstained from defining what trust is.

> The term 'notary seal' is a bit confusing because the strength and
> implications of such seals differ strongly between countries.

Ditto.

> The term Third Party is used a lot for key escrow parties.  Is it an idea
> to rename this to an "Independent Confirmation signature"?

Fine with me.

> In 5.2.3.25, the definition of "Signature Target" is not very accurate.
> Notably, it is not very strict about the contents being hashed.

I recall that we discussed this a long time ago but can't remember the
details anymore.

Shalom-Salam,

   Werner

From: Konrad Rosenbaum <[email-masked]>
To: [email-masked]
Subject: SHA-1 broken
Date: Thu, 17 Feb 2005 07:50:49 +0100
Sender: [email-masked]

--nextPart1162879.5N5eC6Krpi
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi,

http://www.schneier.com/blog/archives/2005/02/sha1_broken.html

While this attack reduces SHA-1 from strength 2^80 to 2^69 and 2^69=20
operations is still unreachably much, likelihood seems high that someone=20
will improve this attack once the paper has been released.

Should we phase out SHA-1? But in favour of what?

This also means that DSA/DSS is broken (a downgrade attack becomes=20
possible). Should we return to suggesting RSA as signature algorithm?

	Konrad

--nextPart1162879.5N5eC6Krpi
Content-Type: application/pgp-signature

--nextPart1162879.5N5eC6Krpi--

Date: Thu, 17 Feb 2005 00:12:51 +0100
From: Rick van Rein <[email-masked]>
Subject: Timestamp and 3rd party sig
To: [email-masked]
Sender: [email-masked]

Hello,

Dare I suggest a rephrasing of the 0x40 and 0x50 definitions?

   0x40: Timestamp signature.
       This signature is only meaningful for the timestamp contained in
       it.

This can be read as if the document signed and the signing key don't matter.
The point of a timestamp is a matter of emphasising what its intention is,
but not much more.

A topic open for debate would be whether it may be assumed that "extra" or
"sufficient" effort has been taken to guard and/or synchronise the time
encapsulated.  In line with the intention of 0x10..0x13 I left this out
in the text that follows, to avoid pinning down something that is open
to debate.

I therefore propose either this text...

   0x40: Timestamp signature.
	The intention of this signature is to accurately record the time
	at which the timestamped data was seen by the timestamp-signing
	party.

...then I tried to add a definition of what was being timestamped...

	If the timestamped data is an OpenPGP signature, it MUST
	be referenced with a Signature Target [or Signature Reference,
	see below] subpacket. In all other cases, the timestamped data MUST
	be constructed as a normal signature on data.

This is much clearer to an implementer, I think.
-> Is the distinction between sig-on-sig and sig-on-data desirable?
-> The MUSTs are intended to avoid multiple formats which mean the same.
-> Given this definition, should one use 0x40 or 0x50 to confirm revocations?

Another issue:

   0x50: Third-Party Confirmation signature.
       This signature is a signature over some other OpenPGP signature
       packet(s). It is analogous to a notary seal on the signed data.
       A third-party signature SHOULD include Signature Target
       subpacket(s) to give easy identification. Note that we really do
       mean SHOULD. There are plausible uses for this (such as a blind
       party that only sees the signature, not the key nor source
       document) that cannot include a target subpacket.

The term 'notary seal' is a bit confusing because the strength and
implications of such seals differ strongly between countries.

Since the Signature Target subpacket(s) are hashes, they convey the
signature subpacket that is being signed -- is that not sufficient for
blind signing purposes?  If the signature target is not provided, what
would then be the subpackets determining what is being confirmed?

The term Third Party is used a lot for key escrow parties.  Is it an idea
to rename this to an "Independent Confirmation signature"?

In 5.2.3.25, the definition of "Signature Target" is not very accurate.
Notably, it is not very strict about the contents being hashed.  Also,
I (as a non-native English speaker) am tempted to call it a "Signature
Reference".   Dare I rephrase?

CURRENT:

5.2.3.25. Signature Target

   (1 octet PK algorithm, 1 octet hash algorithm, N octets hash)

   This subpacket identifies a specific target signature that a
   signature refers to. For revocation signatures, this subpacket
   provides explicit designation of which signature is being revoked.
   For a third-party or timestamp signature, this designates what
   signature is signed. All arguments are an identifier of that target
   signature.

   The N octets of hash data MUST be the size of the hash of the
   signature. For example, a target signature with a SHA-1 hash MUST
   have 20 octets of hash data.

PROPOSED:

5.2.3.25. Signature Reference

   (1 octet PK algorithm, 1 octet hash algorithm, N octets hash)

   This subpacket refers to a Signature Packet without including the
   Signature Packet inside the Signature Reference subpacket.  Instead,
   the hash of the Signature Packet is included.  When used in a
   revocation signature, this subpacket refers to the signature being
   revoked.  For a Independent/Third-Party Confirmation signatures and
   Timestamp signatures, this subpacket refers to the signature that
   is being confirmed or timestamped.

   The signature that is referenced by this subpacket may or may not
   be present in the same OpenPGP message; a signing party may even
   be totally unaware of the referenced Signature Packet, in which
   case the signature with this subpacket would be a blind signature.

   The N octets of hash data MUST be the size of the hash of the
   signature. For example, a target signature with a SHA-1 hash MUST
   have 20 octets of hash data.

Thanks,

Rick van Rein,
OpenFortress.

From: Jon Callas <[email-masked]>
Subject: Re: Mandatory Algorithm Changes?
Date: Thu, 10 Feb 2005 17:11:30 -0800
To: OpenPGP <[email-masked]>
Sender: [email-masked]

Mandatory-to-implement does not mean mandatory-to-use.

If we change 3DES to AES, things don't instantly stop working. If we do 
that, 3DES would be a SHOULD, of course, and there will be a note that 
says that if you don't implement 3DES there could be interoperability 
issues.

I don't think that any reasonable implementor is going to run right out 
and code stupidly. It will obviously take a couple of years before 
someone can safely assume, for example, that the 
algorithm-of-last-resort would be AES.

However, if we ever want to roll 3DES over to AES, we have to start 
sometime. The couple of years of bake-in doesn't start until a change 
is made. Why not now?

I'm willing to concede the point on SHA-256, I wouldn't have brought it 
up at all if NIST hadn't said a couple days ago they're phasing out 
SHA-1 and rolling to SHA-256.

	Jon

To: OpenPGP <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: An article you should look at
Date: Thu, 10 Feb 2005 11:33:31 -0800
Sender: [email-masked]

<http://www.pgp.com/library/ctocorner/openpgp.html>

	Jon

Date: Wed, 09 Feb 2005 12:25:14 +0000
From: Ian G <[email-masked]>
Organization: http://financialcryptography.com/
To: [email-masked]
Subject: Re: Mandatory Algorithm Changes?
Sender: [email-masked]

Werner Koch wrote:

>On Tue, 08 Feb 2005 21:27:30 +0000, Ian G said:
>
>  
>
>>If both of the major OpenPGP implementations
>>already support it, is there any reason to doubt
>>the little guys will follow along eventually?
>>    
>>
>
>There are other implementations using OpenPGP as well.  For embedded
>systems adding another MUST cipher is a problem, in particular if 3DES
>is already done in (old) hardware.  There might also be the need to
>implement the preferences system unless both, 3DES and AES, are
>declared as fallback algorithms.
>  
>

Right, in that it's a given that there are always
problems for any change.  But let's explore this
a bit more.

What is being changed (suggested) is the OpenPGP
RFC - standard.  No implementation needs to change,
and the only implementations that would want to
change would be future ones that need to adhere
to the standard.

Embedded devices don't really need to adhere
(here, I am assuming that such embedded are
totally embedded and aren't communicating
with the open email community).

Also, as time goes on, those that do not support
AES are going to raise more and more eyebrows.
I think the time is going to come fairly shortly
where I'd say "implementing AES" was more
important than "slavishly following the standard
in every detail."

Are there any little guys here would like to add
anything?  Positive or negative?

FTR: Edwin informs me that the Cryptix OpenPGP
has no objection.

(Which should be taken to mean I vote for the
change - I'm just playing the devil's advocate here.)

iang

-- 
News and views on what matters in finance+crypto:
        http://financialcryptography.com/

Date: Wed, 09 Feb 2005 11:18:09 +0100
From: Rick van Rein <[email-masked]>
Subject: Re: Policy URL -> Policy URI
To: David Shaw <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

The standards speak!

The very recent STD 66 annex RFC 3986 states, in 1.1.3:

   An individual scheme does not have to be classified as being just one
   of "name" or "locator".  Instances of URIs from any given scheme may
   have the characteristics of names or locators or both, often
   depending on the persistence and care in the assignment of
   identifiers by the naming authority, rather than on any quality of
   the scheme.  Future specifications and related documentation should
   use the general term "URI" rather than the more restrictive terms
   "URL" and "URN" [RFC3305].

So...
 - my side-claim that a URI is either a URL or a URN is not true anymore
 - my suggestion to change Policy URL to Policy URI is a must-do
 - changing Keyserver URL to Keyserver URI comes highly recommended as well

Let's just do it as the standard states, change every URL to a URI.

Cheers,
 -Rick

To: Ian G <[email-masked]>
Cc: [email-masked]
Subject: Re: Mandatory Algorithm Changes?
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[email-masked]
Date: Wed, 09 Feb 2005 08:39:02 +0100
Sender: [email-masked]

On Tue, 08 Feb 2005 21:27:30 +0000, Ian G said:

> If both of the major OpenPGP implementations
> already support it, is there any reason to doubt
> the little guys will follow along eventually?

There are other implementations using OpenPGP as well.  For embedded
systems adding another MUST cipher is a problem, in particular if 3DES
is already done in (old) hardware.  There might also be the need to
implement the preferences system unless both, 3DES and AES, are
declared as fallback algorithms.

Shalom-Salam,

   Werner

Date: Tue, 8 Feb 2005 22:39:14 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Policy URL -> Policy URI
Mail-Followup-To: [email-masked]
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

On Wed, Feb 09, 2005 at 12:15:38AM +0100, Florian Weimer wrote:
> 
> * Rick van Rein:
> 
> > Florian,
> >
> >> > Back then, the URI *identified* a resource, but this doesn't make much
> >> > sense in the OpenPGP context (were fingerprints are used to identify
> >> > keys).  The keyserver location is just that, a location.
> >> > 
> >> > The URI terminology has changed since then.
> >> 
> >> If URI doesn't mean what it used to, does it then make sense to change
> >> both the keyserver and policy URLs to URIs?
> >
> > Yes, please specify.  We don't want this to end up in a sort of FUD against
> > URIs.  To the best of my knowledge, it's all really simple, as summarised
> > here:
> >
> > http://rick.vanrein.org/blog/notes/urn-uri-url.2005-02-07-13-53.article
> 
> Ahem, STD 66 presents a slightly different view. 8-)
> 
> The problem is that it's impossible to distinguish identifiers and
> locators at the syntax level.  It's not possible to uphold the URN/URL
> distinction.

After giving reading STD 66 a quick once over (and it is indeed new -
less than a month old), I see your point.  Especially since there is
no way to tell them apart anyway, I think that the proper thing for
2440bis is to call *both* keyserver and policy URLs, URIs instead.

There are a number of reasons, but the main one as I see it is that it
is not our business (as OpenPGP people) to tell people what is
acceptable for their keyserver or policy fields to point to.  If
someone wants to point to a book, great.  Go ahead.  If some
implementation wants to support URNs, also great.

Making this change has no impact on any implementations since URLs are
URIs.

David

From: Florian Weimer <[email-masked]>
To: Rick van Rein <[email-masked]>
Cc: [email-masked]
Subject: Re: Policy URL -> Policy URI
Date: Wed, 09 Feb 2005 00:15:38 +0100
Sender: [email-masked]

* Rick van Rein:

> Florian,
>
>> > Back then, the URI *identified* a resource, but this doesn't make much
>> > sense in the OpenPGP context (were fingerprints are used to identify
>> > keys).  The keyserver location is just that, a location.
>> > 
>> > The URI terminology has changed since then.
>> 
>> If URI doesn't mean what it used to, does it then make sense to change
>> both the keyserver and policy URLs to URIs?
>
> Yes, please specify.  We don't want this to end up in a sort of FUD against
> URIs.  To the best of my knowledge, it's all really simple, as summarised
> here:
>
> http://rick.vanrein.org/blog/notes/urn-uri-url.2005-02-07-13-53.article

Ahem, STD 66 presents a slightly different view. 8-)

The problem is that it's impossible to distinguish identifiers and
locators at the syntax level.  It's not possible to uphold the URN/URL
distinction.

Date: Tue, 08 Feb 2005 22:34:45 +0100
From: Rick van Rein <[email-masked]>
Subject: Re: Policy URL -> Policy URI
To: [email-masked]
Sender: [email-masked]

Florian,

> > Back then, the URI *identified* a resource, but this doesn't make much
> > sense in the OpenPGP context (were fingerprints are used to identify
> > keys).  The keyserver location is just that, a location.
> > 
> > The URI terminology has changed since then.
> 
> If URI doesn't mean what it used to, does it then make sense to change
> both the keyserver and policy URLs to URIs?

Yes, please specify.  We don't want this to end up in a sort of FUD against
URIs.  To the best of my knowledge, it's all really simple, as summarised
here:

http://rick.vanrein.org/blog/notes/urn-uri-url.2005-02-07-13-53.article

Best,
-Rick

Date: Tue, 08 Feb 2005 21:27:30 +0000
From: Ian G <[email-masked]>
Organization: http://financialcryptography.com/
To: [email-masked]
Subject: Re: Mandatory Algorithm Changes?
Sender: [email-masked]

I agree that switching from SHA1 to SHA256 seems
like a move without clear basis, given the results
from that last conference.  I think we just have to
sit it out and see what happens.

As far as AES is concerned, I'm less definately for
or against ;)

I can't see a problem directly with making it a must,
as we are now at the point where TDES is "ok if
you have to but we'd rather you didn't."  (The
comments by Steve Bellovin last week were new
for me at least.)

If both of the major OpenPGP implementations
already support it, is there any reason to doubt
the little guys will follow along eventually?

(I agree it should be AES128 that should be the
must, if it is going that way...)

iang

-- 
News and views on what matters in finance+crypto:
        http://financialcryptography.com/

Date: Tue, 08 Feb 2005 21:23:22 +0100
From: Edwin Woudt <[email-masked]>
To: Jon Callas <[email-masked]>, OpenPGP <[email-masked]>
Subject: Re: Mandatory Algorithm Changes?
Sender: [email-masked]

--On 8-2-2005 9:42 -0800 Jon Callas <[email-masked]> wrote:
>
> I almost cringe to suggest this, but I will.
>
> Triple-DES is pretty much obsolete. Yesterday, I saw that NIST announced
> they're moving to stronger hashes.
>
> Does anyone object to changing the MUST cipher to AES (I'd pick 128) and
> MUST hash to SHA-256?

Regarding SHA-256: would that mean switching to SHA-256 for key 
fingerprints as well? (shouldn't v5 keys be introduced then?) And use 
SHA-256 for MDC packets?

Or is it just adding a MUST implement, so applications can use SHA-256 for 
document signatures with RSA keys only? (as DSA forces one to use SHA-1 
anyway)

IMHO, the first is what should be done at some point, but that's a really 
big change: all implementations out there need to be upgraded. Wouldn't 
that conflict with getting the current draft on standards track?

I do not see the point of the second option: as long as keys are only 
protected by a 160 bit figerprint, there is not much point protecting 
document signatures with longer hashes. It may be harder to generate a 
collision resulting in a valid key, then it is to generate a collision 
resulting in just some other random document, but I do not think it is wise 
to count on such an assumption.

-- 
Edwin

To: [email-masked]
Subject: Re: Mandatory Algorithm Changes?
Date: Tue,  8 Feb 2005 11:44:42 -0800 (PST)
From: [email-masked] ("Hal Finney")
Sender: [email-masked]

I agree with Werner specifically that it seems premature to jump
onto SHA-256, at this time of flux in the cryptographic commmunity's
understanding of hash functions.  MD5 and several other comparable hashes
are broken but the techniques are still secret and unpublished AFAIK.
Reduced forms of SHA-1 have some attacks but the full version is still OK.
There were even comments suggesting that the SHA-256 family may not be
as secure as was previously believed.

I haven't heard much more about these since then.  Looking at the IACR
eprints archive, I find http://eprint.iacr.org/2005/010 from January 2005,
by Rijmen and Oswald:

"We report on the experiments we performed in order to assess the security
of SHA-1 against the attack by Chabaud and Joux. We present some ideas for
optimizations of the attack and some properties of the message expansion
routine. Finally, we show that for a reduced version of SHA-1, with 53
rounds instead of 80, it is possible to find collisions in less than
$2^{80}$ operations."

That's the known state of the art, and it's not terribly worrisome,
but these researchers are not employing the secret Chinese techniques.
SHA-1 is structurally similar to MD5 so there is reason to fear that the
MD5 break could be extended to SHA-1, either by the original researchers,
or by others once they publish their methods.  OTOH SHA-1 does have some
twists and complexity that MD5 does not, which could immunize it against
the attacks.

The information on SHA-256 is available at http://eprint.iacr.org/2004/207,
by Hawkes et al.  While this is not an attack, it shows flaws in an
earlier analysis that suggested that the SHA-256 family was strong in
certain ways.

All in all the field is in turmoil these days.  I would hesitate to take
any steps right now with the hash functions, beyond of course deprecating
MD5 as we have done.

Hal Finney

Date: Tue, 8 Feb 2005 13:58:32 -0500
From: David Shaw <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: Mandatory Algorithm Changes?
Mail-Followup-To: OpenPGP <[email-masked]>
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

On Tue, Feb 08, 2005 at 09:42:20AM -0800, Jon Callas wrote:
> 
> I almost cringe to suggest this, but I will.
> 
> Triple-DES is pretty much obsolete. Yesterday, I saw that NIST 
> announced they're moving to stronger hashes.
> 
> Does anyone object to changing the MUST cipher to AES (I'd pick 128) 
> and MUST hash to SHA-256?

This would be difficult to do without breaking backwards
compatibility.  There are a lot of deployed systems that expect 3DES
to be the MUST cipher.

I'm not against adding a second MUST cipher without removing the
current 3DES, but I don't see how the 3DES as the
cipher-of-last-resort could be changed except over a significant
amount of time.

David

To: Jon Callas <[email-masked]>
Cc: OpenPGP <[email-masked]>
Subject: Re: Mandatory Algorithm Changes?
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[email-masked]
Date: Tue, 08 Feb 2005 19:40:02 +0100
Sender: [email-masked]

On Tue, 8 Feb 2005 09:42:20 -0800, Jon Callas said:

> Does anyone object to changing the MUST cipher to AES (I'd pick 128)
> and MUST hash to SHA-256?

Breaks interoperability with existing OpenPGP applications.  I am not
aware of any new security problems with 3DES which would justify such
a step.  Adding AES-128 as another MUST algorithm would be fine with
me but this breaks interoperability too.

SHA-256 is even worser.  In addition to the interop problems,
applications using OpenPGP tools need to be changed to make use of the
longer digest.  Dropping MD5 is really a good idea, but I doubt that
SHA-256 has been analyzed as much as the older algorithms.  Given that
there are now doubts on the general design principle of all common
hash algorithms, I think it is a bit to early to make it a MUST.

I guess that there are other things in OpenPGP that are more
vulnerable to attacks than SHA-1.  Better do a new RFC now and then
start thinking about all the open issues.

Shalom-Salam,

   Werner

Date: Tue, 8 Feb 2005 13:32:33 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Policy URL -> Policy URI
Mail-Followup-To: [email-masked]
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

On Tue, Feb 08, 2005 at 11:14:06AM +0100, Florian Weimer wrote:
> 
> * Jon Callas:
> 
> > Okay, I see what you're saying, but is it necessary?
> >
> > A long time ago, the keyserver URL said URI and we changed it for 
> > reasons that I can't remember.
> 
> Back then, the URI *identified* a resource, but this doesn't make much
> sense in the OpenPGP context (were fingerprints are used to identify
> keys).  The keyserver location is just that, a location.
> 
> The URI terminology has changed since then.

If URI doesn't mean what it used to, does it then make sense to change
both the keyserver and policy URLs to URIs?

David

To: [email-masked]
Subject: Re: confusing terminology
Date: Tue,  8 Feb 2005 10:23:41 -0800 (PST)
From: [email-masked] ("Hal Finney")
Sender: [email-masked]

Rick van Rein writes:
> For this reason, I would never, ever encrypt without compressing first.
> This is the cryptographic advise I would like to see in the indicated place.

I'm afraid I don't agree with this as cryptographic advice.  If your
cipher is so weak that you are afraid to encrypt English text, you need
a new cipher!  Not a new compression algorithm.

It's fine if you want to say that compression increases the entropy
density which could in theory make the cryptanalyst's problem slightly
harder, but I would definitely not go so far as to advise or imply that
failing to compress is cryptographically insecure.

Hal Finney

To: OpenPGP <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Mandatory Algorithm Changes?
Date: Tue, 8 Feb 2005 09:42:20 -0800
Sender: [email-masked]

I almost cringe to suggest this, but I will.

Triple-DES is pretty much obsolete. Yesterday, I saw that NIST 
announced they're moving to stronger hashes.

Does anyone object to changing the MUST cipher to AES (I'd pick 128) 
and MUST hash to SHA-256?

	Jon

From: Florian Weimer <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: Rick van Rein <[email-masked]>, [email-masked]
Subject: Re: Policy URL -> Policy URI
Date: Tue, 08 Feb 2005 11:14:06 +0100
Sender: [email-masked]

* Jon Callas:

> Okay, I see what you're saying, but is it necessary?
>
> A long time ago, the keyserver URL said URI and we changed it for 
> reasons that I can't remember.

Back then, the URI *identified* a resource, but this doesn't make much
sense in the OpenPGP context (were fingerprints are used to identify
keys).  The keyserver location is just that, a location.

The URI terminology has changed since then.

Date: Tue, 08 Feb 2005 10:41:29 +0100
From: Rick van Rein <[email-masked]>
Subject: Re: Policy URL -> Policy URI
To: Jon Callas <[email-masked]>
Cc: Rick van Rein <[email-masked]>, [email-masked]
Sender: [email-masked]

Jon,

> If you happened to put in the policy URL an ISBN number, wouldn't it be 
> obvious what it meant? Wouldn't it work just fine?

You are suggesting to keep the standard as is and to let those who find it
constraining simply make their own standard, right?

I don't think that's a good idea :) especially because a suitable and
globally accepted mechanism exists -> the URN, part of the URI scheme.

Rick van Rein,
OpenFortress.

Date: Tue, 08 Feb 2005 10:24:10 +0100
From: Rick van Rein <[email-masked]>
Subject: Re: Policy URL -> Policy URI
To: Jon Callas <[email-masked]>
Cc: Rick van Rein <[email-masked]>, [email-masked]
Sender: [email-masked]

Hello Jon, others,

> Okay, I see what you're saying, but is it necessary?

I think it is.

1. I think PGP is providing too little certainty about the meaning of a
   signature with its current four-grade signing setup.  At least, it is
   not suitable for commercial use, which would be great to support.  A
   suitable policy mechanism can help in that case.

2. It is not smart to fall behind on other signing flexibility; PGP already
   lacks the appeal to decision-makers that PKIX and even XML Signing have;
   any URN-based policy initiative could therefore easily forget to
   incorporate PGP and render it useless for that kind of application.

3. There are always work-arounds.  For example, the kind of schemes
   suggested under 2. could declare a website to do the translation from
   URN to URL for the sake of PGP.  Aside from that being awkward, it would
   be a challenge to the longevity of the spec and may for that reason be
   left out.  We don't want that to happen.

> A long time ago, the keyserver URL said URI and we changed it for 
> reasons that I can't remember.  I think it's because we didn't think it 
> was necessary, that if it happened to be a URI, the worst that could 
> happen would be that someone wouldn't understand it, but that's always 
> a risk.

Indeed, the *keyserver* should not be referenced by name -- if you cannot
determine the location of a server what is it going to be good for?

For policies, I think we have a whole different matter at hand --
references to books, an ISSN-series of widely acknowledged signing policies
and ASN.1 OIDs are all good ways to point at a policy.  Moreover, they are
supportive of Internet-wide schemes, which is rarely the case if a URL is
used.

Imagine that I would start pushing PGP-signers to follow
	http://openfortress.nl/doc/some-policy.pdf
How would that make you feel?  It would mean some company set it up.  A
company with full control over the URL.  Other companies are going to be
too proud or too smart to use the same signing policy *location*.  Even if
they literally copy the content, the average signature validator would not
notice because the strings differ.  In short, URLs are bad for
interoperable policies.

A URN-scheme on the other hand, can serve quite well for Internet-wide,
non-proprietary published policies.  It can enforce the secure hash of a
document, which can only be weakly suggested in a URL.  That would take
care of the pride issue.  Furthermore, URNs can support rewriting to
equivalent forms, which would be helpful for supportive software to find
more matches than a simple string match can be.

> If you happened to put in the policy URL an ISBN number, wouldn't it be 
> obvious what it meant? Wouldn't it work just fine?

There are always work-arounds, but why invite them?  There are no
disadvantages to changing to a Policy URI.

> I don't mind changing it, but is this just a difference without 
> distinction?

The change is vital in my opinion.

Thanks,
 -Rick

Date: Tue, 08 Feb 2005 10:00:20 +0100
From: Rick van Rein <[email-masked]>
Subject: Re: confusing terminology
To: Ben Laurie <[email-masked]>
Sender: [email-masked]

Ben, others,

> >As for the "added side-effect" (which states the same thing doubly twice) I
> >see a cryptographic advantage in compression that should go here :- by
> >compressing a message, the entropy of the data that is encrypted is made
> >as high as possible.
> 
> Entropy is not altered by (lossless) compression.

Perhaps I wasn't clear enough.  The entropy in the total document is not
increased, but the entropy per encrypted block is.

Plain English text is good for about 1 bit of entropy per character/byte;
after compression, the total size is less, certainly for plain English
text.  This means that the same information is stored in less bytes, so
the entropy per byte (or per block of bytes) has risen.

It is advantageous to a cryptanalist to know that the input to an
encryption algorithm is plain English text, because it means that
possible variations of the input are greatly reduced.  Compression
makes that assumption go wrong.

For this reason, I would never, ever encrypt without compressing first.
This is the cryptographic advise I would like to see in the indicated place.

Cheers,
 -Rick

Date: Tue, 08 Feb 2005 06:21:49 +0000
From: Ben Laurie <[email-masked]>
To: Rick van Rein <[email-masked]>
Cc: [email-masked]
Subject: Re: confusing terminology
Sender: [email-masked]

Rick van Rein wrote:
>>>Message, data file, object, session
> 
> These terms are used in a rotary scheme, but the reader must assume they
> mean the same thing, and not something slightly different.  The original
> thought of OpenPGP seems to have been message formats as sent by email,
> but then PGP disk encryption came and the terms had to be altered.
> 
> Can be agree on one term for "the stuff that is PGP-ified" perhaps?
> I think "OpenPGP data" will be fine, in contrast to "readable data".

"ciphertext" and "plaintext" sound more usual to me.

> As for the "added side-effect" (which states the same thing doubly twice) I
> see a cryptographic advantage in compression that should go here :- by
> compressing a message, the entropy of the data that is encrypted is made
> as high as possible.

Entropy is not altered by (lossless) compression.

Cheers,

Ben.

Cc: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Policy URL -> Policy URI
Date: Mon, 7 Feb 2005 16:50:29 -0800
To: Rick van Rein <[email-masked]>
Sender: [email-masked]

Okay, I see what you're saying, but is it necessary?

A long time ago, the keyserver URL said URI and we changed it for 
reasons that I can't remember. I think it's because we didn't think it 
was necessary, that if it happened to be a URI, the worst that could 
happen would be that someone wouldn't understand it, but that's always 
a risk.

If you happened to put in the policy URL an ISBN number, wouldn't it be 
obvious what it meant? Wouldn't it work just fine?

I don't mind changing it, but is this just a difference without 
distinction?

	Jon

Date: Tue, 08 Feb 2005 00:24:27 +0100
From: Rick van Rein <[email-masked]>
Subject: confusing terminology
To: [email-masked]
Sender: [email-masked]

Hello,

I entered this list just recently, sorry about that.
I am wading through the spec bit by bit, hoping to add improvements.

After reading sections 1 and 2 I have seen a lot of confusing names,
often covering the same thing and sometimes used with different meaning.
This does not appeal to me as good specification habits I fear.

>> Message, data file, object, session

These terms are used in a rotary scheme, but the reader must assume they
mean the same thing, and not something slightly different.  The original
thought of OpenPGP seems to have been message formats as sent by email,
but then PGP disk encryption came and the terms had to be altered.

Can be agree on one term for "the stuff that is PGP-ified" perhaps?
I think "OpenPGP data" will be fine, in contrast to "readable data".

>> OpenPGP: spec or implementation?

Section 1.1 teaches us that "OpenPGP" is the name of a definition
(or specification?) but the list items in section 2.1 use it to indicate
a program.  I propose to change "OpenPGP" to "OpenPGP implemetation"
in these list items.

Section 2.0 introduces a self-contradicting loop, by stating that OpenPGP
(the document) does a few things that are beyond the scope of this
document.

A finer note on 1.1 -> I don't think definitions are formalized, instead I
think specifications are described or formulated.  Am I going too far?

The subset from 2.5 is sufficiently clear -- but it would not harm to give
it an explicit name, such as "non-encrypting OpenPGP".  That would help
clarify references to this document.

>> The goal, course and fine

The start of section 2 mentions a list of four bullets, specifying a few
techniques used.  I am not seeing CR-LF standardisation, but I do see
radix-64 which seems to be of similar weight.  Both are not nearly as
important as the first three points.  I would leave it to these three
bullets and not get down to the level of representation here.

To be frank, I don't see the point of section 2.4; it seems too early.
I may be off here.  Either way, isn't it true that implementations SHOULD
only *accept* radix-64 representations of OpenPGP data?

Somewhat funny: confidentiality is not mentioned here at all!

>> Procedures, data

Section 2.1 describes the same procedure twice.  Once in the
introductionary paragraph, once in the list.  What I would have expected
from the plaintext (not the list) in both 2.1 and 2.2 is a description of
the data structure -- that would remove procedurally irrelevant details
from the procedures.

Point 4 of 2.2, "attached" means "appended", so at the end, right?

Point 5 of 2.2, "keeps" means?  Should it be "receives"?

>> Compression

Section 2.3 stresses that compression SHOULD be done, but it is not
mentioned in the procedure under 2.1.

The second paragraph contradicts itself, doesn't it?  It speaks of
implementations that do not implement compression and says that they should
at least decompress.  This should be said about implementations that do not
compress outgoing messages prior to their encryption.

As for the "added side-effect" (which states the same thing doubly twice) I
see a cryptographic advantage in compression that should go here :- by
compressing a message, the entropy of the data that is encrypted is made
as high as possible.

Let me know if you want me to write actual text.  I'm not sure how this
process works -- but I'll be open to suggestions.

Cheers,

Rick van Rein,
OpenFortress.

Date: Mon, 07 Feb 2005 11:50:21 +0100
From: Rick van Rein <[email-masked]>
Subject: Policy URL -> Policy URI
To: [email-masked]
Sender: [email-masked]

Hello OpenPGP-drafters,

It seems important to me to consider replacing URL with URI in the OpenPGP
spec.  This would include URN-schemes, such as references to books that
everybody can pick up in their local bookstore or at Amazon.  A book URN       
would look like URN:ISBN:1-234-56789-0 (see RFC 3187).  There are several       
other useful URN schema's.

There are two places in the specification that speak of URL's; one is the       
keyserver (which really is a location, so it makes sense to keep it as
a URL) and the other is the policy.  I think it makes sense to support more
than just the available-on-my-website kind of local/incompatible policies.

Note that other signing standards do speak of URIs for policies.  In the
PKIX standard RFC 3280, there is a CPSuri definiton; in RFC 3275 (XML
Signing) there is no explicit support for policies (...) but the proper way
of getting it into the signature is with a <Reference/> element which
obtains its information from a URI rather than just a URL.

In OpenPGP, replacing a Policy URL with a Policy URI need not lead to    
conflicts with older software; inasfar as they interpret the subpacket,
they usually treat it either as a literal string that should be matched or
as something that can be presented in a browser.  The reason is that
policies cannot be interpreted by software -- they are usually written in
English.

Browsers are supposed to resolve URN-schemes; as far as they do not
recognise them they will consider the urn: start as a protocol, and of
course state that they do not support it.  Same goes for any other
downloading software.

In other words, the change of a Policy URL into a Policy URN seems
advantageous, and I cannot see how it could cause problems.  I therefore
warmly recommend changing it.

Thanks,

Rick van Rein,
OpenFortress Digital signatures