Subject: Tag 11 unclear

From: Ben Laurie <[email-masked]>
Date: Tue, 26 Apr 2005 18:37:50 +0100

In 5.9:

    " - File name as a string (one-octet length, followed by file name),
        if the encrypted data should be saved as a file."

but no mention of what if it shouldn't be saved as a file. 0 length,
perhaps?

Then:

    " - A four-octet number that indicates the modification date of the
        file, or the creation time of the packet, or a zero that
        indicates the present time."

I would _guess_ that it means modification date of the file if there's
a filename, the creation time if there isn't. I have no idea what zero
is supposed to mean. Nothing, would be the obvious interpretation -
"the present time" is nonsensical.

Once more, when I know what its supposed to mean, I'll suggest
wording.

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

---

From: [email-masked] ("Hal Finney")
Date: Tue, 26 Apr 2005 12:02:23 -0700 (PDT)

> but no mention of what if it shouldn't be saved as a file. 0 length,

Yes, I think 0 is the right length in that case.  The language about
"if it should be saved as a file" is from the perspective of the decryptor
and is perhaps too functionally oriented.  It might be better simply to
document this as a filename which can be optionally associated with the
encrypted data.  We can recommend that decryptors MAY use this as a
default file name if the data is being saved as a file.

We might also want to note here that literal packet headers are not
signed, unless the literal packet is first wrapped in another packet
such as a compressed packet.  Only the body of a literal packet is
signed in a message which consists of sig-packet, literal-packet.
(Or sig1-packet, literal-packet, sig-packet)

> "the present time" is nonsensical.

Yes, I agree, zero means simply an unspecified time.

Hal Finney

To: [email-masked], [email-masked]
Subject: Re: Tag 11 unclear
Date: Tue, 26 Apr 2005 12:02:23 -0700 (PDT)
From: [email-masked] ("Hal Finney")
Sender: [email-masked]

> but no mention of what if it shouldn't be saved as a file. 0 length,

Yes, I think 0 is the right length in that case.  The language about
"if it should be saved as a file" is from the perspective of the decryptor
and is perhaps too functionally oriented.  It might be better simply to
document this as a filename which can be optionally associated with the
encrypted data.  We can recommend that decryptors MAY use this as a
default file name if the data is being saved as a file.

We might also want to note here that literal packet headers are not
signed, unless the literal packet is first wrapped in another packet
such as a compressed packet.  Only the body of a literal packet is
signed in a message which consists of sig-packet, literal-packet.
(Or sig1-packet, literal-packet, sig-packet)

> "the present time" is nonsensical.

Yes, I agree, zero means simply an unspecified time.

Hal Finney

Date: Tue, 26 Apr 2005 18:37:50 +0100
From: Ben Laurie <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Tag 11 unclear
Sender: [email-masked]

In 5.9:

Then:

Cheers,

Ben.

Date: Tue, 26 Apr 2005 13:39:07 +0100
From: Ben Laurie <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Editorial Nit
Sender: [email-masked]

5.2.3.7. Preferred symmetric algorithms

    (sequence of one-octet values)

5.2.3.8. Preferred hash algorithms

    (array of one-octet values)

It seems these (and others) should all either say "sequence" or "array".

Date: Thu, 21 Apr 2005 23:55:48 -0400
From: David Shaw <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: AES/SHA1/Must/Should
Mail-Followup-To: OpenPGP <[email-masked]>
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

On Sat, Apr 16, 2005 at 10:38:53AM +0100, Ian G wrote:

> OK, so your view would be "in v4, TripleDES is a
> default and a MUST and that should not change."

Not exactly what I'm saying, but close.

What I'm saying is, "Don't change it overnight.  If we can do this as
part of a v5 key, great.  If we must do it in v4, then give warning
about the upcoming for the change for a year or three first."

My suggested change for 2440bis works with either of those two cases.

David

Date: Sat, 16 Apr 2005 10:38:53 +0100
From: Ian G <[email-masked]>
Organization: http://financialcryptography.com/
To: David Shaw <[email-masked]>
CC: OpenPGP <[email-masked]>
Subject: Re: AES/SHA1/Must/Should
Sender: [email-masked]

David Shaw wrote:
> On Fri, Apr 15, 2005 at 10:34:02PM +0100, Ian G wrote:
> 
>>How about:
>>
>>    At least one MUST-implement algorithm SHOULD be in the
>>    list.
>>
>>    Older implementations may deliver an empty list, and may
>>    imply TripleDES at the end of the list.  This behaviour
>>    is deprecated.
> 
> 
> I think this is overcomplicated.  There is no way to phrase this that
> is safe for old implementations - if a new implementation uses AES
> instead of 3DES, older implementations lose.

Exactly, this is the problem with having both a list
of algorithms and also implicit defaults.  One should
have one or the other, IMHO, not both, unless one is
seeking revenge on coders for unimaginable crimes long
past.

> Here is what I propose.  It doesn't really matter right now whether
> AES becomes the default in a v5 key format or by a future revision to
> v4.  Either way, this change is safe:
> 
> 1) In section 9.2, change AES from a SHOULD to a MUST.
> 
> 2) In section 12.1, change
> 
> this:
>    Since TripleDES is the MUST-implement algorithm, if it is not
>    explicitly in the list, it is tacitly at the end.
> 
> to this:
>    TripleDES is the current default OpenPGP algorithm, so if it is not
>    explicitly in the list, it is tacitly at the end.

Right, so TripleDES remains a default, but the
status of default is delinked from the MUST status.

AES becomes a MUST, but is not a default.

> and this:
>    Note that the MUST-implement algorithm, TripleDES, ensures
>    that the intersection is not null.
> 
> to this:
>    Note that the current default algorithm, TripleDES, ensures that the
>    intersection is not null.

Looks good.

The only question I would have is whether (in v4) we
would continue to assume the presence of a default
algorithm.  If we are agreed that defaults are a
bad thing, then some warning should be put in there
to suggest all new keys should include their full
list.  Alternatively, I suggest we bite the bullet
and state that TripleDES is the default and that
will never change (in v4).

> or other text amounting to the same thing.  The reason for this change
> is that the current text refers to TripleDES as the only
> MUST-implement algorithm.  If we add AES as another MUST, this text is
> no longer correct.
> 
> End result is to leave 3DES as the default, and make AES a MUST.  In n
> years, we'll either have v5 keys or can just redefine v4.  Either way,
> we've laid the groundwork.

OK, so your view would be "in v4, TripleDES is a
default and a MUST and that should not change."

Fair enough.

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

Date: Fri, 15 Apr 2005 22:50:42 -0400
From: David Shaw <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: AES/SHA1/Must/Should
Mail-Followup-To: OpenPGP <[email-masked]>
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

On Fri, Apr 15, 2005 at 10:34:02PM +0100, Ian G wrote:
> How about:
> 
>     At least one MUST-implement algorithm SHOULD be in the
>     list.
> 
>     Older implementations may deliver an empty list, and may
>     imply TripleDES at the end of the list.  This behaviour
>     is deprecated.

I think this is overcomplicated.  There is no way to phrase this that
is safe for old implementations - if a new implementation uses AES
instead of 3DES, older implementations lose.

Here is what I propose.  It doesn't really matter right now whether
AES becomes the default in a v5 key format or by a future revision to
v4.  Either way, this change is safe:

1) In section 9.2, change AES from a SHOULD to a MUST.

2) In section 12.1, change

this:
   Since TripleDES is the MUST-implement algorithm, if it is not
   explicitly in the list, it is tacitly at the end.

to this:
   TripleDES is the current default OpenPGP algorithm, so if it is not
   explicitly in the list, it is tacitly at the end.

and this:
   Note that the MUST-implement algorithm, TripleDES, ensures
   that the intersection is not null.

to this:
   Note that the current default algorithm, TripleDES, ensures that the
   intersection is not null.

or other text amounting to the same thing.  The reason for this change
is that the current text refers to TripleDES as the only
MUST-implement algorithm.  If we add AES as another MUST, this text is
no longer correct.

End result is to leave 3DES as the default, and make AES a MUST.  In n
years, we'll either have v5 keys or can just redefine v4.  Either way,
we've laid the groundwork.

David

Date: Fri, 15 Apr 2005 22:34:02 +0100
From: Ian G <[email-masked]>
Organization: http://financialcryptography.com/
To: OpenPGP <[email-masked]>
Subject: Re: AES/SHA1/Must/Should
Sender: [email-masked]

David Shaw wrote:
> On Fri, Apr 15, 2005 at 08:09:12PM +0100, Ian G wrote:

> Where comes this desire to remove 3DES?  Are there any new attacks
> that raise the desire to dispose of it?  The only complaint I can see
> with 3DES is that it's *slow*.  Not that it's insecure.

Well, it is not "remove 3DES" but rather move over to
AES.  The attacks that were mentioned are the ones based
on the birthday attack, I do not know the details, but
it is based on the block size being too small.  This
is not a validated threat but it is a signal to start
moving to a bigger block size, being 16 bytes.

>>Is the "algorithm of last resort" actually specified
>>in the draft RFC, is it?
> 
> 
> Section 12.1:
> 
>    Since TripleDES is the MUST-implement algorithm, if it is not
>    explicitly in the list, it is tacitly at the end. However, it is
>    good form to place it there explicitly. Note also that if an
>    implementation does not implement the preference, then it is
>    implicitly a TripleDES-only implementation.

OK, so if we add AES as a MUST algorithm, leaving TripleDES
in place as a MUST also, then that paragraph needs to be
clarified.

Possibly:

    Since TripleDES and AES are MUST-implement algorithms,
    if they are not explicitly in the list, they are implied
    to be at the end.  However, it is good form to place the
    algorithms there explicitly, and as algorithms may be
    reduced in status from MUST to SHOULD in the future,
    this is highly recommended.  Note also that if an
    implementation does not implement the preference, then
    it implicitly implements the MUST algorithms.

Hmmm... that's getting clumsy.  I'd say that such a default
should be deprecated, if possible:

Is there any good reason why implementations shouldn't
implement the preference?  Are there any implementations
that do not implement the preference?

Also, is there any good reason to imply the MUST algorithms
into the list?  Obviously there are implementations that
do this.  But why not just deprecate that implication and
say that implementations MUST include all their preferences,
with a footnote that older implementations may implicitly
assume TripleDES at the end of the list?

How about:

     At least one MUST-implement algorithm SHOULD be in the
     list.

     Older implementations may deliver an empty list, and may
     imply TripleDES at the end of the list.  This behaviour
     is deprecated.

>    An implementation MUST NOT use a symmetric algorithm that is not in
>    the recipient's preference list. When encrypting to more than one
>    recipient, the implementation finds a suitable algorithm by taking
>    the intersection of the preferences of the recipients. Note that
>    the MUST-implement algorithm, TripleDES, ensures that the intersection
>    is not null. The implementation may use any mechanism to pick an
>    algorithm in the intersection.
> 
> 
>>If an implementation
>>chooses 3DES as its algorithm of last resort, that doesn't
>>need to change.  It just seems likely that in a couple
>>of years or so, AES would make more sense for that decision.
> 
> 
> So add AES as a MUST implement to get it out there, and then in a few
> years we can revisit what the algorithm of last resort is.  Just leave
> poor 3DES alone.

OK, so at least we seem to have consensus on adding AES
as a MUST algorithm.  Anyone else demur?

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

Date: Fri, 15 Apr 2005 17:02:08 -0400
From: David Shaw <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: AES/SHA1/Must/Should
Mail-Followup-To: OpenPGP <[email-masked]>
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

On Fri, Apr 15, 2005 at 10:41:12AM -0700, Jon Callas wrote:
> 
> On 13 Apr 2005, at 2:51 PM, David Shaw wrote:
> 
> >There are too many years and too many implementations where 3DES is
> >the algorithm of last resort, and changing 3DES to a SHOULD
> >necessitates a different algorithm of last resort.  We cannot change
> >that overnight.
> >
> >By all means, add some new MUSTs to start the algorithm changing
> >process, but 3DES needs to stay as MUST as well for a good long time.
> >
> 
> I understand how you feel. I feel the same way. However, I have a 
> question to ask:
> 
> When? How long is "a good long time"? Forever?

I'd say "a good long time" is more than 2, but less than 5 years.  I
base this on the surprising number of requests I still get to help get
GnuPG working with PGP 5 and PGP 6.  There are people using these old
programs every day, (naturally installed years earlier, by someone who
no longer works there), and making this change would wreak all sorts
of havoc for these poor folks.  A AES-is-default program can pretty
easily send them a message they cannot decrypt.

Changing the algorithm of last resort from 3DES sets up some cases of
incompatibility with PGP 6 and earlier, and GnuPG 1.0.3 and earlier on
one side, and modern versions on the other.  It's easy to say that
people shouldn't be using these versions any longer (and I say that
often), but they are.

> The counter-argument is that there is no better time than now. The 
> reasons to keep 3DES there only get stronger as time goes on. This 
> problem becomes worse with time, not better.

I agree.  That's why I'd like to sidestep the problem and change the
algorithm of last resort as part of a v5 key.  There are no
compatibility problems then, as we're changing new keys, and not
retroactively changing the meaning of old keys.

Basically, I'm thinking this: given that it'll take a few years to
change from 3DES, and given that we must change the default hash away
from SHA-1 within the next few years, and given the Mister/Zuccherato
attack, and given the desire to publish 2440bis already, why not kill
a whole bunch of birds with one stone?  Finish up 2440bis, publish it,
then sit down and design v5.

I'd probably feel differently about all this if 3DES was broken in
some way, but it's not broken.  It's just slow.

David

Date: Fri, 15 Apr 2005 16:32:32 -0400
From: David Shaw <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: AES/SHA1/Must/Should
Mail-Followup-To: OpenPGP <[email-masked]>
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

On Fri, Apr 15, 2005 at 08:09:12PM +0100, Ian G wrote:
> 
> 
> >On 13 Apr 2005, at 2:51 PM, David Shaw wrote:
> >
> >>There are too many years and too many implementations where 3DES is
> >>the algorithm of last resort, and changing 3DES to a SHOULD
> >>necessitates a different algorithm of last resort.  We cannot change
> >>that overnight.
> 
> 
> I think there is a big difference between what the
> implementations do, and what the standard says.  If
> there is an issue in the short term, then implementations
> are free to ignore the standard.  It's not as if anyone
> ever lost a contract because they couldn't prove absolute
> compliance with the standard.
> 
> In this happy state of affairs, I am not sure why we
> cannot (as a standards body) wiggle our fingers with
> fierceness about 3DES and have the implementations
> broadly ignore us for many months or even years...

If we mean it, put it in the standard.  If we don't, then don't put it
in the standard.  No need for wink-wink with implementations.  This is
a pretty straightforward issue.  Even before 2440, in 2440, and until
today, 3DES has been the algorithm of last resort.  There are a
significant number of deployed systems that base their behavior on
that design.  You can't declare a flag day after which the algorithm
of last resort is different without causing incompatibility.

Where comes this desire to remove 3DES?  Are there any new attacks
that raise the desire to dispose of it?  The only complaint I can see
with 3DES is that it's *slow*.  Not that it's insecure.

> Is the "algorithm of last resort" actually specified
> in the draft RFC, is it?

Section 12.1:

   Since TripleDES is the MUST-implement algorithm, if it is not
   explicitly in the list, it is tacitly at the end. However, it is
   good form to place it there explicitly. Note also that if an
   implementation does not implement the preference, then it is
   implicitly a TripleDES-only implementation.

   An implementation MUST NOT use a symmetric algorithm that is not in
   the recipient's preference list. When encrypting to more than one
   recipient, the implementation finds a suitable algorithm by taking
   the intersection of the preferences of the recipients. Note that
   the MUST-implement algorithm, TripleDES, ensures that the intersection
   is not null. The implementation may use any mechanism to pick an
   algorithm in the intersection.

> If an implementation
> chooses 3DES as its algorithm of last resort, that doesn't
> need to change.  It just seems likely that in a couple
> of years or so, AES would make more sense for that decision.

So add AES as a MUST implement to get it out there, and then in a few
years we can revisit what the algorithm of last resort is.  Just leave
poor 3DES alone.

David

Date: Fri, 15 Apr 2005 20:09:12 +0100
From: Ian G <[email-masked]>
Organization: http://financialcryptography.com/
To: OpenPGP <[email-masked]>
Subject: Re: AES/SHA1/Must/Should
Sender: [email-masked]

> On 13 Apr 2005, at 2:51 PM, David Shaw wrote:
> 
>> There are too many years and too many implementations where 3DES is
>> the algorithm of last resort, and changing 3DES to a SHOULD
>> necessitates a different algorithm of last resort.  We cannot change
>> that overnight.

I think there is a big difference between what the
implementations do, and what the standard says.  If
there is an issue in the short term, then implementations
are free to ignore the standard.  It's not as if anyone
ever lost a contract because they couldn't prove absolute
compliance with the standard.

In this happy state of affairs, I am not sure why we
cannot (as a standards body) wiggle our fingers with
fierceness about 3DES and have the implementations
broadly ignore us for many months or even years...

Is the "algorithm of last resort" actually specified
in the draft RFC, is it?

If an implementation
chooses 3DES as its algorithm of last resort, that doesn't
need to change.  It just seems likely that in a couple
of years or so, AES would make more sense for that decision.

 > I recommend not making any change in default algorithms for 2440bis.
 > If and when we take up v5 keys, we can easily set the cipher of last
 > resort for v5 keys to something other than 3DES.

The issue I see with that is that this group has been
working for ... 8 years?  and hasn't got a standard
out.  I'd love to see some action on a v5 key layout,
but I don't have much hope.

iang

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

From: Jon Callas <[email-masked]>
Subject: Re: AES/SHA1/Must/Should
Date: Fri, 15 Apr 2005 10:41:12 -0700
To: OpenPGP <[email-masked]>
Sender: [email-masked]

On 13 Apr 2005, at 2:51 PM, David Shaw wrote:

> There are too many years and too many implementations where 3DES is
> the algorithm of last resort, and changing 3DES to a SHOULD
> necessitates a different algorithm of last resort.  We cannot change
> that overnight.
>
> By all means, add some new MUSTs to start the algorithm changing
> process, but 3DES needs to stay as MUST as well for a good long time.
>

I understand how you feel. I feel the same way. However, I have a 
question to ask:

When? How long is "a good long time"? Forever?

The counter-argument is that there is no better time than now. The 
reasons to keep 3DES there only get stronger as time goes on. This 
problem becomes worse with time, not better.

	Jon

Date: Wed, 13 Apr 2005 17:51:45 -0400
From: David Shaw <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: AES/SHA1/Must/Should
Mail-Followup-To: OpenPGP <[email-masked]>
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

On Wed, Apr 13, 2005 at 10:06:47PM +0100, Ian G wrote:
> 
> Is the draft 12 the current working text?  I noticed it
> expires in another month.
> 
> Did we resolve the question of whether to make changes
> to the MUST / SHOULD algorithms?
> 
> I'm all in favour of saying AES-128 is now the MUST and
> triple DES becomes the SHOULD.  In practice, most
> implementations would be there already as they will have
> done both (Cryptix Java is, and so is Perl's Crypt::OpenPGP).

I don't have a very strong feeling one way or another on making
AES-128 a MUST.  However, I have a very strong feeling against
changing the status of 3DES.

There are too many years and too many implementations where 3DES is
the algorithm of last resort, and changing 3DES to a SHOULD
necessitates a different algorithm of last resort.  We cannot change
that overnight.

By all means, add some new MUSTs to start the algorithm changing
process, but 3DES needs to stay as MUST as well for a good long time.

I recommend not making any change in default algorithms for 2440bis.
If and when we take up v5 keys, we can easily set the cipher of last
resort for v5 keys to something other than 3DES.

David

Date: Wed, 13 Apr 2005 22:06:47 +0100
From: Ian G <[email-masked]>
Organization: http://financialcryptography.com/
To: OpenPGP <[email-masked]>
Subject: AES/SHA1/Must/Should
Sender: [email-masked]

Is the draft 12 the current working text?  I noticed it
expires in another month.

Did we resolve the question of whether to make changes
to the MUST / SHOULD algorithms?

I'm all in favour of saying AES-128 is now the MUST and
triple DES becomes the SHOULD.  In practice, most
implementations would be there already as they will have
done both (Cryptix Java is, and so is Perl's Crypt::OpenPGP).

SHA is harder as we've discussed.  If we agree to leave
matters lie, then here's one potential addition to 13
(I cribbed the wording from the other points, but any
wording could be considered....):

13. Security Considerations  - suggested addition

* In October 2004, the Shandong university team of Wang, Yin, Yu
announced attacks on reduced rounds of SHA1.  Collisions are
predicted in 2^69 steps rather than the full 2^80 steps.  For this
reason SHA1 is widely expected to be deprecated in coming years.
Implementors may prefer to move to wider length SHA algorithms
as appropriate.

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

To: [email-masked]
Subject: OpenPGP Signatures Incorporating X.509 Certificates
Date: Tue, 12 Apr 2005 14:58:27 -0700 (PDT)
From: [email-masked] ("Hal Finney")
Sender: [email-masked]

          OpenPGP Signatures Incorporating X.509 Certificates

        Copyright 2005 by PGP Corporation. All Rights Reserved.

Abstract

   This document is published to document the procedure used by
   commercial PGP [PGP] products up through version 9 for incorporating
   X.509 [X.509-00] certificates into OpenPGP [RFC2440] format
   signatures, and for cryptographically validating such signatures.  It
   describes only the format and methods needed to import X.509
   certificates, and to validate key signature packets containing such
   certificates.  It does not deal with storage and implementation
   questions.

1. Introduction

   The OpenPGP [RFC2440] specification describes data formats for
   representing public keys, userids, and key signatures that
   cryptographically bind keys, userids, and fields from signature
   packets.  It further describes the cryptographic procedures used to
   sign and verify the signature packets which comply with that
   specification.

   An alternative set of standards and formats is widely used in network
   applications for communicating cryptographic bindings of public keys
   and associated name data, based on the X.509 [X.509-00] certificate
   format.  X.509 certificates communicate similar information to
   OpenPGP key, userid and signature packets.  However, the details of
   the data formats are incompatible and it is not possible to transform
   X.509 certificates into sequences of OpenPGP packets that can be
   cryptographically validated by the mechanisms described in RFC2440.

   This document presents an alternative mechanism to allow X.509
   certificates to be imported into OpenPGP data formats and
   cryptographically validated.  It describes both the detailed data
   formats used to import and represent X.509 data in OpenPGP packets,
   and the procedures necessary to cryptographically validate such X.509
   based OpenPGP signatures.  These mechanisms allow the cryptographic
   infrastructure based on X.509 certificates to be imported and used in
   the context of OpenPGP messages and data.

1.1. Overview of Importing Certificates

   X.509 certificates are imported into OpenPGP signature packets in
   three steps, which will be described in more detail in section 2.

                                                                [Page 1]

                                   -2-

   First, the numeric key material (the RSA modulus and exponent, and
   corresponding values for other key types) is used to construct an
   OpenPGP key packet.  Second, the name field(s) of the X.509
   certificate are used to construct an OpenPGP userid packet.  And
   third, an OpenPGP signature packet is constructed from the
   certificate.  Some fields of the OpenPGP signature packet are set
   from corresponding fields in the certificate.  In addition, the
   certificate itself is inserted as a whole into the OpenPGP signature
   packet, in a signature subpacket.

   During the import process, the keyring is searched for a pre-existing
   OpenPGP key which matches the numeric key material being imported.
   If so, the userid and signature are added to the existing key.  This
   also requires checking to see whether there is already a userid on
   the key matching the userid constructed by the import process; if so,
   the new signature packet is added to the pre-existing userid.  This
   allows OpenPGP keys to hold a combination of X.509 based signatures
   and regular OpenPGP signatures.

   Once the X.509 certificate has been imported, the resulting OpenPGP
   keys and userids can be used interchangeably with regular OpenPGP
   keys.  The only difference is in the format of the X.509 signatures.

1.2. Validating Certificates

   Cryptographically validating an X.509 signature packet requires a
   special process.  It is not possible to use the normal OpenPGP
   signature validation process because no cryptographically valid
   signature exists over the OpenPGP data.  Instead, a two step process
   is used.

   First, the X.509 certificate is tested for consistency with the
   OpenPGP packets.  This requires extracting the X.509 certificate from
   the OpenPGP signature packet.  It is then put through a process
   similar to when it was first imported into the OpenPGP format per
   this specification, to create temporary OpenPGP key, userid and
   signature packets from the certificate data.  These temporary packets
   are compared with the OpenPGP key, userid and signature packets from
   the OpenPGP key holding the X.509 certificate signature.  There must
   be an exact, byte-for-byte match between the two sets of packets for
   this step of the validation to be considered successful.  This
   guarantees that the material in the OpenPGP packets is consistent
   with the contents of the X.509 certificate.

   Second, the X.509 certificate is itself cryptographically validated.
   This is a straightforward matter of computing the hash over the "to
   be signed" portion of the certificate and running the cryptographic
   signature verification algorithm using that hash and using the

                                                                [Page 2]

                                   -3-

   signature field of the certificate.  This step requires that the
   cryptographic key material of the issuing certificate must be
   present; for example, it may be available on the keyring as an
   OpenPGP key if it was previously imported into the OpenPGP format.

   Together, these two steps assure that the issuing key issued the
   certificate, and that the resulting OpenPGP key, userid and signature
   packets faithfully reflect the information put into the certificate
   by the issuer.  On this basis the X.509 certificate signature is
   considered to be valid.

1.3. Identifying Signing Keys

   The OpenPGP specification uses keyids to link signatures to the keys
   which issued them.  X.509 uses a different method, based on the
   issuer name.  As a result, X.509 signature packets do not have keyid
   subpackets.  Instead, to find the key which issued an X.509 signature
   packet it is necessary to extract the X.509 certificate, parse it to
   extract the issuer field, and then to search the other X.509
   signature packets on the keyring for an X.509 certificate whose
   subject name matches.  The key to which that certificate signature is
   attached is the one which issued the X.509 signature being validated.

2. Importing X.509 Certificates

   Note that the rules and procedures below for importing an X.509
   certificate must be followed precisely by any compatible
   implementation.  This is because checking the cryptographic validity
   of an X.509 signature requires extracting the certificate from the
   X.509 signature and repeating the import process, comparing the
   results byte for byte with the OpenPGP key, userid and signature
   packets.  Any variation between implementations, even seemingly
   inconsequential ones like changing the order of various subpackets or
   userid fields, will cause this bytewise comparison to fail and cause
   the signature to be treated as invalid.

2.1. Creating the Key Packet

   The first step in importing an X.509 certificate into OpenPGP is to
   create an OpenPGP key packet which includes the numeric key material
   from the certificate.  X.509 certificates holding RSA, DSS or ElGamal
   keys may be imported.  The data is extracted from the
   SubjectPublicKeyInfo field of the certificate and converted into
   OpenPGP public key format.

   OpenPGP public key packets contain four additional pieces of
   information.  First, they have a version number.  Version 3 and 4
   packets are presently in use.  Second, they have a creation date

                                                                [Page 3]

                                   -4-

   field.  Third, version 3 packets have a field encoding the duration
   until key expiration.  And fourth, they hold an algorithm identifier
   for the public key algorithm the key represents.

   In importing the key, the keyring should be searched for an existing
   key whose numeric key material matches that of the certificate being
   imported.  If a match is found, that key packet is used as the basis
   for filling in these other fields.  This uses the version number,
   creation date and expiration period fields from the pre-existing key.

   If no matching key exists, the new OpenPGP packet is created with
   version 4, and the public key algorithm field is set from the type of
   public key in the X.509 certificate.  V4 keys do not have expiration
   periods, so that leaves only the creation date.

   X.509 certificates normally do not specify a key creation date, only
   a certificate creation date.  A somewhat complicated mechanism is
   available to facilitate setting a reliable key creation date field in
   the OpenPGP public key packet.

   This mechanism is intended to facilitate allowing pre-existing
   OpenPGP keys to acquire X.509 certificates on their key material.
   These X.509 certificates could then be distributed and imported into
   other users' OpenPGP compatible software.  In order to keep the
   resulting OpenPGP keys compatible with the ones which were certified,
   OpenPGP encodes the key creation date into the X.509 certificate
   request which is sent to be certified.  With a cooperative
   certificate issuing authority (CA), the key creation date is then
   embedded in the certificate in a special format.  This ensures that
   when other users import the X.509 certificate, they will create the
   OpenPGP key with the same creation date that the original key had.

   This is especially important in case the importing user did not
   previously have a copy of the original OpenPGP key, but acquired it
   by importing the X.509 certificate; and then he later imports the
   original OpenPGP key as a conventional-format OpenPGP key, rather
   than as a certificate.  Without the special mechanism for handling
   creation dates, the creation dates wouldn't match, and the keyids of
   the two keys would be different, making them appear to be two
   different keys.  Putting the key creation date into the X.509
   certificate helps to insure that importing the certificate will
   correctly reconstruct the OpenPGP key.

   Two alternative mechanisms are available for encoding this
   information into the X.509 certificate.  The preferred mechanism is a
   custom extension created for this purpose.  The OID for this
   extension is (1 3 6 1 4 1 3401 8 1 1), encoded as the octet string
   {0x06, 0x0a, 0x2b, 0x06, 0x01, 0x04, 0x01, 0x9a, 0x49, 0x08, 0x01,

                                                                [Page 4]

                                   -5-

   0x01}.  The data for the extension is defined as:

   PGPExtension ::= SEQUENCE {
        version             Version DEFAULT v1,
        keyCreation         Time
   }

   The OpenPGP key creation data is stored in X.509 Time format, the
   same format used for the notBefore and notAfter subfields of the
   certificate validity field.  This is converted to the four byte
   OpenPGP time format specified in RFC2440 and used as the key creation
   field in the new OpenPGP key packet.

   The second method for encoding the OpenPGP creation date into an
   X.509 certificate is used if the custom extension is not supported by
   the CA.  It stores the OpenPGP creation date in a field in the
   subject Distinguished Name.  It uses either an Organizational Unit or
   Description field in the subject name.  The creation date is stored
   in one of these field types, with associated data in the format
   "PGPKeyCreation=0x........" where the dots are replaced by 8 hex
   digits that encode the creation date in OpenPGP time format.  If such
   a field is found, the hex value after "0x" is converted to binary
   data and used as the creation date in the OpenPGP key packet.

   On import, the certificate is searched sequentially for these two
   possible encodings of creation date.  The first match is used,
   although typically there would not be more than one such encoding
   present in a certificate.  Because subject name comes before
   extensions, the subject name fields are checked first, then the
   extensions.

   If none of these methods work to find an OpenPGP creation date, as
   will typically be the case on a certificate which was created via
   X.509 mechanisms and not by certifying an OpenPGP key, the
   certificate notBefore field is converted to OpenPGP time format and
   used as the key creation date.

2.2. Creating the UserID Packet

   Two alternative methods are available to create an OpenPGP UserID
   packet from an X.509 certificate, the short name format and the long
   name format.  The short name format is used if the conditions
   described below are met, otherwise the long name format is used.

   The short name format for the userid is of the form "common_name
   <email_address>", a widely used format for OpenPGP userids.  For this
   format to be used it must be possible to extract a common name and
   email address from the certificate.  The common name must come from

                                                                [Page 5]

                                   -6-

   the subject name field.  The email address may come from either the
   subject name, where its OID is (1 2 840 113549 1 9 1), or from a
   SubjectAlternativeName field in an extension, where the choice type
   is rfc822Name.

   As a special case, the short name format is also used if the subject
   name has only a single field, which is an email address, but there is
   no common name.  In that case the userid is created as
   "<email_address>".

   If it is not possible to satisfy these conditions for creating the
   userid in the short format, a long format is used.  This is a slight
   modification of "Lightweight Directory Access Protocol (v3): UTF-8
   String Representation of Distinguished Names" [RFC2253], applied to
   the subject name field of the certificate.

   RFC2253 puts the DN fields into reverse order, but this specification
   modifies that rule somewhat.  The common name field (if present) is
   always output first, before the other fields, to improve readability.
   Also, any name field corresponding to the special OpenPGP key
   creation date field described in the section 2.1, if present, is
   skipped and is not output.

   The only DN field names which get converted into printable form for
   the userid are CN, C, L, ST, STREET, O, OU and EMAIL.  Other fields
   in the DN are ignored when converting to an OpenPGP userid.  Note
   that any SubjectAlternativeName extensions are not used when
   outputting a long format name.  Only the fields from the subject name
   of the certificate are put into the OpenPGP userid packet.

   If no fields from the list above are found in the DN, the userid
   packet is created with the text "(Unknown X509 name)".

2.3. Creating the Signature Packet

   Creating the OpenPGP signature packet from an X.509 certificate
   involves two steps.  The first is to include the certificate itself,
   in total, into a new subpacket of the OpenPGP signature packet.  The
   second is to set up the various signature packet fields and
   subpackets which encode the supported semantics of the X.509
   certificate.

2.3.1. X.509 Signature Subpacket Format

   This specification defines a new OpenPGP subpacket type.  It uses
   subpacket type 100, defined in RFC2440 as within the private range of
   subpackets.  The first byte of the subpacket is 1, indicating that
   the type of the private-range subpacket is an X.509 certificate.  The

                                                                [Page 6]

                                   -7-

   next two bytes are major and minor version numbers.  The major
   version is 1 for all compatible implementations of this
   specification.  The minor version reflects changes in the detailed
   rules for how X.509 certificates are converted to OpenPGP keys.  The
   current minor version is 4, and this value should be used in newly
   created certificate subpackets.

   When verifying an X.509 certificate signature, the minor version
   number must be parsed and used to guide the conversion process.
   Since part of the verification involves checking for consistency
   between the X.509 certificate and the OpenPGP packets, any
   differences would cause the signature to be treated as invalid.  When
   changes are made for how this conversion is done, the minor version
   must be upgraded.

   The only operational difference at this point is between minor
   version 4 vs. earlier minor version numbers of 3 or less.  There is a
   change to the public key algorithm field used in the signature
   packet, as described below.  No other changes presently exist based
   on minor version number, for importing signature, userid or key
   packets.

   The remaining data in the certificate subpacket is the X.509
   certificate itself.  Its length is determined implicitly by the
   subpacket length minus the fields already described.  X.509
   certificates are self-delimiting, and the certificate must end at the
   end of the data range in the subpacket allocated to hold it.

2.3.2. Other Signature Fields

   In addition to inserting the certificate bodily into a new subpacket,
   other fields of the OpenPGP signature packet are created to be
   consistent with the data from the certificate.  Note that it is
   necessary to follow the description in this section precisely in
   order to create X.509 signature packets which will interoperate with
   other software implementing this specification.  No flexibility is
   possible in the set of signature packets created, the contents of the
   packet, or the ordering of the packets.  This consistency is
   necessary in order for the byte-for-byte packet comparison to succeed
   when signatures are verified.

   OpenPGP signature packets created from X.509 certificates are version
   4 packets.  The signature type field is 0x10, "generic certification
   of a user id and public key packet".  The next field is the public
   key algorithm, which guides the signature verification process.  As
   described in the introduction, X.509 signature packets cannot be
   cryptographically verified by the normal OpenPGP verification rules.
   To flag this fact and make sure an OpenPGP implementation of this

                                                                [Page 7]

                                   -8-

   specification does not try to verify the packet, a reserved value is
   used for the public key algorithm field.

   This is the one place the minor version number from the certificate
   subpacket is used.  For minor versions 0-3, the reserved value is 0.
   For minor version 4, the reserved value is 100, which is in the
   reserved range for RFC2440.  In either case, it is meant to indicate
   that the regular OpenPGP certificate verification process will not
   work, and to prevent noncompliant OpenPGP implementations from
   attempting to verify signatures created by this specification.

   The next field in the V4 signature packet is the hash algorithm ID,
   which is set to the hash algorithm from the X.509 certificate.  If a
   certificate uses a public key or hash algorithm not recognized by
   RFC2440, it is not allowed to be imported per this specification.

   The next part of the signature packet contains the so-called hashed
   subpackets.  Note that these subpackets are not actually hashed, in
   an X.509 signature packet; rather, their validity is verified based
   on comparison with the X.509 certificate, which does get
   cryptographically hashed and verified.  Several such subpackets are
   created, based on X.509 certificate data.  The order of these
   subpackets is significant in that the certificate verification
   process described in section 1.2 will attempt to re-convert the X.509
   certificate into an OpenPGP signature packet and do a byte-for-byte
   match between the re-converted data and the original signature data.
   The packets must be identical for the X.509 signature to be
   considered valid.

   The first subpacket is signature creation time, subpacket ID 2.  This
   is taken from the notBefore subfield of the validity field in the
   certificate, and converted to OpenPGP time format.

   The second subpacket is signature expiration time, subpacket ID 3.
   This is taken from the notAfter subfield of the validity field in the
   certificate, and converted to OpenPGP time format.  The signature
   creation time is then subtracted, because OpenPGP actually stores the
   signature validity duration in seconds in the expiration time
   subpacket.

   Next is an optional trust signature subpacket, ID 5.  It is used if
   the imported certificate has a BasicConstraints extension with the
   boolean cA field being true, representing a CA certificate.  The
   trust signature subpacket holds two bytes. The first is the trust
   "level", which means the depth to which trust is delegated.  This is
   set based on any PathLenConstraint field of the BasicConstraints
   extension.  If there is no PathLenConstraint, the level value stored
   in the trust packet is the maximum value of 255.  If there is a

                                                                [Page 8]

                                   -9-

   PathLenConstraint value in the certificate, the trust level stored is
   equal to that integer value, plus one (then truncated to one byte).
   The trust packet also has a second byte representing the validity of
   the trust being extended, which is set to 120, meaning complete
   validity.

   Next there is an optional a key flags subpacket, ID 27.  It is used
   if there is a KeyUsage extension in the imported certificate, to
   encode any key usage restrictions.  Not all bits in the KeyUsage
   extension are recognized and converted by this specification, but the
   key flags subpacket is created even if none of the bits are
   recognized, in which case the key flags subpacket will be output with
   a flag value of zero.  The bits which are recognized, and the
   corresponding OpenPGP key flags values, are as follows:

   keyCertSign      ---> flag 0x01, key can certify other keys
   cRLSign          ---> flag 0x01, key can certify other keys
   digitalSignature ---> flag 0x02, key can sign data
   nonRepudiation   ---> flag 0x02, key can sign data
   keyEncipherment  ---> flags 0x14, key can encrypt communications
                         and key can encrypt storage
   dataEncipherment ---> flags 0x14, key can encrypt communications
                         and key can encrypt storage
   keyAgreement     ---> flags 0x14, key can encrypt communications
                         and key can encrypt storage

   All other key flag bits in the four byte field are output as zero.

   The last subpacket output is the X.509 certificate subpacket, ID 100,
   as described in section 2.3.1. above.

   Following the hashed data subpackets in the signature packet are the
   unhashed packets.  No such packets are used when importing an X.509
   signature, so the length of the unhashed region must be zero.  Note
   in particular that X.509 signature packets do not have an issuing
   keyid field.  This is because X.509 certificates refer to their
   issuer by name, rather than by keyid, as discussed in section 1.3.

   Next comes a two byte checksum, which is set to two bytes of zero.
   Finally there is the MPI data for the OpenPGP signature.  No MPI data
   is used for signatures in this specification, so a dummy MPI value of
   1 is stored, represented as the three byte sequence 0, 1, 1.  That
   ends the OpenPGP signature packet.

                                                                [Page 9]

                                  -10-

3. References

   [PGP]       PGP Corporation, http://www.pgp.com.

   [RFC2253]   M. Wahl, S. Kille, T. Howes, "Lightweight Directory
   Access Protocol (v3): UTF-8 String Representation of Distinguished
   Names", RFC 2253, December, 1997.

   [RFC2440]   J. Callas, L. Donnerhacke, H. Finney, R. Thayer, "OpenPGP
   Message Format", RFC 2440, November, 1998.

   [X.509-00]  ITU-T.  Recommendation X.509: The Directory -
   Authentication Framework.  2000.

                                                               [Page 10]


From: Konrad Rosenbaum <[email-masked]>
To: Ben Laurie <[email-masked]>
Subject: Re: How to Calculate Signatures?
Date: Sun, 3 Apr 2005 21:33:50 +0200
Cc: [email-masked]
Sender: [email-masked]

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

On Sunday 03 April 2005 20:50, Ben Laurie wrote:
> Konrad Rosenbaum wrote:
> > Simple: you don't. DSA was designed to be used with SHA-1, which is 160
> > bit. Since SHA-1 is theoretically broken (practically will probably
> > follow in a few months) one should see what the NIST makes of it.
> > Supplanting a broken hash with another hash doesn't make much sense
> > with DSA, since it does not contain the ID of the hash (as PKCS#1 does
> > for RSA) - so any attacker could find a collission with the broken hash
> > and then simply change the hash ID in the signature packet.
>
> The hash does include the ID of the hash, and hence the signature does.

That does not prevent a downgrade attack.

Presume the following scenario:

The signature S is under Text A with hash algorithm H. The hash is deemed=20
secure.

So s contains the number of H and the content of A. The structure looks lik=
e=20
this:

Text packet A
Signature packet S
 Hash number H
 signed(Hash_H(H_number || A)) # or something very similiar

Now we want the signature to refer to Text B and we know that hash algorith=
m=20
X is insecure (and we know how to use that). What we need to do now is we=20
need to find a text C that consists of the the number of X, and B plus some=
=20
"random" that is chosen in a way that does not distort the meaning (eg. a=20
"geek code block" below the actual eMail text). The structure will look=20
like:

Text packet C ( =3D B || "random")
Signature packet S'
 Hash number X
 signed(Hash_H(H_number || A)) =3D=3D signed(Hash_X(X_number || C))

=2E..and that all because a weak Hash X will enable us to find a text that=
=20
creates the same hash sum in X that we want to supplant for a hash sum of H=
=20
=2D regardless of whether we hash the hash number, a "magic" code or my gra=
nd=20
mothers birthday into it.

MD5 is already beaten down to 33 bit, it is only a question of time till=20
SHA-1 is there as well (granted, we'll probably have some months left).=20
Currently we are only save because there is no 160-bit Hash in OpenPGP that=
=20
is vulnerable enough to make the attack worthwhile.

The days of DSA with a 160-bit p are counted. Period.

	Konrad

PS.: please view my DSA signature on this mail as my last action of respect=
=20
to DSA. It was a good fellow... ;-)

--nextPart1781299.3IFMXeiy2q
Content-Type: application/pgp-signature

--nextPart1781299.3IFMXeiy2q--

Date: Tue, 05 Apr 2005 13:04:55 +0100
From: Ben Laurie <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: OpenPGP <[email-masked]>
Subject: Re: New Encrypted Data Packet?
Sender: [email-masked]

Jon Callas wrote:
> 
> When the Mister-Zuccherato attack came out at the beginning of the year, 
> one of the suggestions that we had was to re-do the encrypted data 
> packet and MDC. It seems that there's not really a lot of consensus to 
> fix it, that merely working around the problem seems to be adequate? Am 
> I right in that perception? Do we want to upgrade it?

I missed this discussion, I think, and can't seem to find it in the 
archives. Do you have a refrence?

> I still think it's a good idea, myself, particularly since if you want 
> wide deployment of such a thing for the future getting on it now is a 
> good idea. But I would also like to really close out 2440bis, too. 
> (However, the two are not mutually exclusive. We could close out 2440bis 
> and put the upgrades into a followon RFC.)

That sounds like a plan.

Date: Mon, 4 Apr 2005 16:50:07 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: How to Calculate Signatures?
Mail-Followup-To: [email-masked]
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

On Mon, Apr 04, 2005 at 05:34:07PM +0100, Ben Laurie wrote:

> >Yup. And the same thing applies to V3 keys as well. I've had vocal 
> >complaints from people about their V3 key and how they're upset about 
> >losing whatever trust issues there are from it being a decade or more old.
> 
> So what's wrong with signing your V4 key with your V3 key and moving on?

Because that would make the V4 key One More Hop Away, of course. ;)

David

Cc: OpenPGP <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: How to Calculate Signatures?
Date: Mon, 4 Apr 2005 13:32:39 -0700
To: Ben Laurie <[email-masked]>
Sender: [email-masked]

On 4 Apr 2005, at 9:34 AM, Ben Laurie wrote:

>
> So what's wrong with signing your V4 key with your V3 key and moving 
> on?
>
>

Beats me. People get attached to things. Attachments to things cause 
all sorts of irrational behavior.

I suspect in a lot of cases, people get attached to an old key because 
of the number or quality of certs. It's similar to the, "I'll never 
wash that hand again!" response to shaking hands with a celeb.

	Jon

Cc: OpenPGP <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: New Encrypted Data Packet?
Date: Mon, 4 Apr 2005 13:27:37 -0700
To: Ian G <[email-masked]>
Sender: [email-masked]

> (Which would not be to say that Ben's observations over the
> weekend didn't look extremely useful.)
>

I'm going to look through Ben's suggestions and fold them into a new 
draft.

> (As to future revisions, I recall in prior times it has been
> discussed that we wouldn't talk about future changes until
> 2440bis was closed out.)
>

Yeah, but security-related cryptographic changes are always the obvious 
exception.

	Jon

Date: Mon, 4 Apr 2005 15:24:45 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: How to Calculate Signatures?
Mail-Followup-To: [email-masked]
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

On Mon, Apr 04, 2005 at 11:08:05AM -0700, "Hal Finney" wrote:

> I agree that if it takes that long for the change to propagate, we
> are probably better off waiting for NIST to come up with FIPS 186-3
> which will specify how to use SHA-2 with DSS.

I think it would take a good long while for the change to propagate.

I don't know about other implementations, but there is no support for
this in GnuPG.  Adding support is trivial, to be sure, but getting
however many GnuPG installations to upgrade (with no compatibility
with many DSA signatures in the meantime) would be a pretty
substantial problem.

David

To: [email-masked]
Subject: Re: How to Calculate Signatures?
Date: Mon,  4 Apr 2005 11:08:05 -0700 (PDT)
From: [email-masked] ("Hal Finney")
Sender: [email-masked]

Ian G wrote:
> >>I'm curious on this point.  Other than the fact that
> >>"it's broken" why is it that you see it important to
> >>repair the DSA in OpenPGP?
> > 
> Hal Finney wrote:
> > I'm not sure if you are asking why we worry about using SHA-1 at all given
> > that the attack is theoretical, or why we don't just abandon DSA keys.

Ian replied:
> I'd say it is an open question, so either or both.
>
> Hal Finney wrote:
> > For the first question, my main concern is that the SHA-1 attack
> > may get worse so that it becomes computationally feasible to find
> > collisions.  If that happens we could be vulnerable to attacks like
> > http://eprint.iacr.org/2005/067 which showed two X.509 certificates
> > with the same hash.  The attacks could become even stronger to where
> > different userids could collide.
>
> I think now I understand this as more an issue for
> WoT than documents - is that right?  (I think I'm
> deriving that from the last sentance above...)  In
> that people who have DSA keys and have lots of sigs
> are faced with losing their 'investment'.

The WoT issue related to the 2nd question about maintaining usability of
DSA keys.  The paragraph above related to the 1st question which was,
why are we worrying about the SHA-1 attack at all, given that it is
purely theoretical and no one has even exhibited a SHA-1 collision.

In the context of that question, it would apply to other situations than
just key signatures.  Ordinary document signatures could be vulnerable.
Alice could prepare a document for Bob to sign, arranging it that there
are two versions.

It could also apply to RSA users who are continuing to use SHA-1.
If the attack worsened, they could be invited to sign someone's key,
and then the data being signed could change.

Again, keep in mind that these paragraphs answer the question, why are
we worried about the attack at all.  Focus on that question in reading
the paragraphs above.

> > For the second, DSA key users do not presently have the options RSA
> > key users do to move to other hashes.  As I argued, the additional risk
> > of giving DSA users more options is not that large.  Letting them use
> > other hashes would allow them to continue to use their existing keys
> > and benefit from the signatures they have acquired on those keys.
>
>
> OK.  In risk terms it might not be that high.  But
> in cost terms, it is significant.  Any changes to
> the way signatures have to be dealt with would have
> to be promulgated through the community, as, if the
> signature verification wasn't standard and acceptable
> to all code bases, it loses its value rapidly.

I agree that if it takes that long for the change to propagate, we are
probably better off waiting for NIST to come up with FIPS 186-3 which
will specify how to use SHA-2 with DSS.

I have a faint hope that they may do something about including a hash
algorithm specifier that would make the standard more robust against
hash breaks.  Even a one octet hash ID similar to what we use in PGP
would greatly improve the flexibility.

The only reason I hold out this hope is that otherwise I don't see what
is taking them so long in releasing this spec.  It's been something like
two years since they announced that it was imminent.  If all they are
going to do is to come up with a few (p, q) size recommendations then
it shouldn't take that long.

If they don't do it, maybe we should think about doing this ourselves,
for next gen DSA keys.  We could include a one byte hash octet ID at
the front of the hash, and make the q size 8 bits bigger.  It would
mean that we are not fully DSS compliant but as Jon points out we are
not quite that way now.

Hal

Date: Mon, 04 Apr 2005 17:34:07 +0100
From: Ben Laurie <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: Ian G <[email-masked]>, [email-masked], Hal Finney <[email-masked]>
Subject: Re: How to Calculate Signatures?
Sender: [email-masked]

Jon Callas wrote:
> 
>>
>> So the analysis needs to question not only the risks
>> but also the costs and benefits.
>>
>> The number of people who need to have DSA and keep
>> using their existing keys for signatures seems to be
>> quite small.  In order for these people to benefit,
>> they must be able to create the sigs, and everyone
>> else must be able to at least read the sigs.  So
>> any change will take a year or two to filter through
>> until there is wide enough distribution of verification,
>> and during that time, I suspect the slow uptake will
>> be over taken by events.
>>
>>
> 
> Yup. And the same thing applies to V3 keys as well. I've had vocal 
> complaints from people about their V3 key and how they're upset about 
> losing whatever trust issues there are from it being a decade or more old.

So what's wrong with signing your V4 key with your V3 key and moving on?

Cheers,

Ben.

Date: Mon, 04 Apr 2005 17:37:11 +0100
From: Ian G <[email-masked]>
Organization: http://financialcryptography.com/
To: Jon Callas <[email-masked]>
CC: OpenPGP <[email-masked]>
Subject: Re: New Encrypted Data Packet?
Sender: [email-masked]

Jon Callas wrote:
> 
> When the Mister-Zuccherato attack came out at the beginning of the year, 
> one of the suggestions that we had was to re-do the encrypted data 
> packet and MDC. It seems that there's not really a lot of consensus to 
> fix it, that merely working around the problem seems to be adequate? Am 
> I right in that perception? Do we want to upgrade it?
> 
> I still think it's a good idea, myself, particularly since if you want 
> wide deployment of such a thing for the future getting on it now is a 
> good idea. But I would also like to really close out 2440bis, too. 
> (However, the two are not mutually exclusive. We could close out 2440bis 
> and put the upgrades into a followon RFC.)

Close out 2440bis, with no more changes.  I think we are well
past the point where fiddling around improving things is worth
anything.  Unless we have a major major break, nothing should
change in the protocol, would be my call.

(Which would not be to say that Ben's observations over the
weekend didn't look extremely useful.)

(As to future revisions, I recall in prior times it has been
discussed that we wouldn't talk about future changes until
2440bis was closed out.)

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

Date: Mon, 04 Apr 2005 18:09:02 +0200
From: Edwin Woudt <[email-masked]>
To: Jon Callas <[email-masked]>, OpenPGP <[email-masked]>
Subject: Re: New Encrypted Data Packet?
Sender: [email-masked]

--On 4-4-2005 8:27 -0700 Jon Callas <[email-masked]> wrote:
>
> When the Mister-Zuccherato attack came out at the beginning of the year,
> one of the suggestions that we had was to re-do the encrypted data packet
> and MDC. It seems that there's not really a lot of consensus to fix it,
> that merely working around the problem seems to be adequate? Am I right
> in that perception? Do we want to upgrade it?
>
> I still think it's a good idea, myself, particularly since if you want
> wide deployment of such a thing for the future getting on it now is a
> good idea. But I would also like to really close out 2440bis, too.
> (However, the two are not mutually exclusive. We could close out 2440bis
> and put the upgrades into a followon RFC.)

I agree it is a good idea, but not for 2440bis. As there is a workaround, I 
would say: add a note about the attack and the workaround to 2440bis and 
get it finished.

Redoing the encrypted data packet can then be implemented together with v5 
keys and any other hash related changes. This also solves the problem of 
deciding which implementations support such a new encrypted data packet: 
just use the new packet for v5 keys, and the old ones for v4 and below.

-- 
Edwin

Cc: [email-masked], Hal Finney <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: How to Calculate Signatures?
Date: Mon, 4 Apr 2005 08:48:35 -0700
To: Ian G <[email-masked]>
Sender: [email-masked]

>
> So the analysis needs to question not only the risks
> but also the costs and benefits.
>
> The number of people who need to have DSA and keep
> using their existing keys for signatures seems to be
> quite small.  In order for these people to benefit,
> they must be able to create the sigs, and everyone
> else must be able to at least read the sigs.  So
> any change will take a year or two to filter through
> until there is wide enough distribution of verification,
> and during that time, I suspect the slow uptake will
> be over taken by events.
>
>

Yup. And the same thing applies to V3 keys as well. I've had vocal 
complaints from people about their V3 key and how they're upset about 
losing whatever trust issues there are from it being a decade or more 
old.

I'm not so worried about DSS that I'm going to dump my older key. But I 
might recommend to someone creating a new key that today, RSA is a 
better choice because of SHA-1 issues and lack of wide-DSS. But that 
could change tomorrow or next week.

	Jon

To: OpenPGP <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: New Encrypted Data Packet?
Date: Mon, 4 Apr 2005 08:27:32 -0700
Sender: [email-masked]

When the Mister-Zuccherato attack came out at the beginning of the 
year, one of the suggestions that we had was to re-do the encrypted 
data packet and MDC. It seems that there's not really a lot of 
consensus to fix it, that merely working around the problem seems to be 
adequate? Am I right in that perception? Do we want to upgrade it?

I still think it's a good idea, myself, particularly since if you want 
wide deployment of such a thing for the future getting on it now is a 
good idea. But I would also like to really close out 2440bis, too. 
(However, the two are not mutually exclusive. We could close out 
2440bis and put the upgrades into a followon RFC.)

	Jon

Date: Mon, 04 Apr 2005 16:16:00 +0100
From: Ian G <[email-masked]>
Organization: http://financialcryptography.com/
To: [email-masked]
CC: Hal Finney <[email-masked]>
Subject: Re: How to Calculate Signatures?
Sender: [email-masked]

Hal Finney wrote:
> Ian G writes:
> 
>>I'm curious on this point.  Other than the fact that
>>"it's broken" why is it that you see it important to
>>repair the DSA in OpenPGP?
> 
> 
> I'm not sure if you are asking why we worry about using SHA-1 at all given
> that the attack is theoretical, or why we don't just abandon DSA keys.

I'd say it is an open question, so either or both.

> For the first question, my main concern is that the SHA-1 attack
> may get worse so that it becomes computationally feasible to find
> collisions.  If that happens we could be vulnerable to attacks like
> http://eprint.iacr.org/2005/067 which showed two X.509 certificates
> with the same hash.  The attacks could become even stronger to where
> different userids could collide.

I think now I understand this as more an issue for
WoT than documents - is that right?  (I think I'm
deriving that from the last sentance above...)  In
that people who have DSA keys and have lots of sigs
are faced with losing their 'investment'.

OK, I agree that is potentially a larger concern than
document sigs as key signing represents something of
an institution.

> For the second, DSA key users do not presently have the options RSA
> key users do to move to other hashes.  As I argued, the additional risk
> of giving DSA users more options is not that large.  Letting them use
> other hashes would allow them to continue to use their existing keys
> and benefit from the signatures they have acquired on those keys.

OK.  In risk terms it might not be that high.  But
in cost terms, it is significant.  Any changes to
the way signatures have to be dealt with would have
to be promulgated through the community, as, if the
signature verification wasn't standard and acceptable
to all code bases, it loses its value rapidly.

So the analysis needs to question not only the risks
but also the costs and benefits.

The number of people who need to have DSA and keep
using their existing keys for signatures seems to be
quite small.  In order for these people to benefit,
they must be able to create the sigs, and everyone
else must be able to at least read the sigs.  So
any change will take a year or two to filter through
until there is wide enough distribution of verification,
and during that time, I suspect the slow uptake will
be over taken by events.

To me, I don't see the cost-benefit analysis coming
out as favourable;  far better to suggest that people
use RSA keys if they are really very keen to have the
best security in signatures, until the DSS-2 situation
settles out.

(in the 90s, this would have been a very different
situation, as RSA faced patent and cryptoexport
problems, so there would have been a group that
might have been limited to using DSA.)

All IMHO of course!

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

Cc: [email-masked], Ben Laurie <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: How to Calculate Signatures?
Date: Mon, 4 Apr 2005 06:40:21 -0700
To: Ian G <[email-masked]>
Sender: [email-masked]

On 3 Apr 2005, at 2:28 PM, Ian G wrote:

> PS: As a point of notation for the RFC, isn't it DSS?
> Or are we saying that DSA is implemented because it
> is not quite DSS?
>

DSA is the Digital Signature Algorithm. DSS is the Digital Signature 
Standard. DSS specifies DSA+SHA1 plus operational whatsits. If you use 
DSA with RIPE/MD-160, for example, it's not DSS. 2440 does cover all of 
this.

	Jon

Cc: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: How to Calculate Signatures?
Date: Mon, 4 Apr 2005 06:44:21 -0700
To: [email-masked] ("Hal Finney")
Sender: [email-masked]

On 3 Apr 2005, at 12:39 PM, Hal Finney wrote:

> For all of these reasons, I am tempted to allow the SHA-2 family with
> current DSA keys, as an interim measure pending the move to DSS-2.
>
> FIPS 180, which defines the SHA family, had a change notice to add  
> SHA-224,
> a truncated form of SHA-256.  This document,
> <http://csrc.nist.gov/publications/fips/fips180-2/fips180 
> -2withchangenotice.pdf>,
> describes truncation of hash algorithms on page 73:
>
> "Some applications may require a hash function with an output size  
> (i.e.,
> message digest size) different than those provided by the hash  
> functions
> in this Standard. In such cases, a truncated hash output may be used,
> whereby a hash function with a larger output size is applied to the
> data to be hashed, and the resulting output (i.e., message digest) is
> truncated by selecting an appropriate number of the leftmost bits. For
> example, if an output of 96 bits is desired, the SHA256 hash function
> could be used (e.g., because it is available to the application), and
> the leftmost 96 bits of the output are selected as the message digest,
> discarding the rightmost 160 bits of the SHA-256 output."
>

This is the reason that Beta 1 of PGP 9.0 allowed SHA-256, and did  
precisely that. However, we decided that that was pushing things, and  
it's not going to be in Beta 2.

	Jon

To: [email-masked]
Subject: Re: How to Calculate Signatures?
Date: Sun,  3 Apr 2005 21:36:38 -0700 (PDT)
From: [email-masked] ("Hal Finney")
Sender: [email-masked]

Ian G writes:
> I'm curious on this point.  Other than the fact that
> "it's broken" why is it that you see it important to
> repair the DSA in OpenPGP?

I'm not sure if you are asking why we worry about using SHA-1 at all given
that the attack is theoretical, or why we don't just abandon DSA keys.

For the first question, my main concern is that the SHA-1 attack
may get worse so that it becomes computationally feasible to find
collisions.  If that happens we could be vulnerable to attacks like
http://eprint.iacr.org/2005/067 which showed two X.509 certificates
with the same hash.  The attacks could become even stronger to where
different userids could collide.

For the second, DSA key users do not presently have the options RSA
key users do to move to other hashes.  As I argued, the additional risk
of giving DSA users more options is not that large.  Letting them use
other hashes would allow them to continue to use their existing keys
and benefit from the signatures they have acquired on those keys.

Hal

Date: Sun, 03 Apr 2005 22:28:19 +0100
From: Ian G <[email-masked]>
Organization: http://financialcryptography.com/
To: Ben Laurie <[email-masked]>
CC: [email-masked]
Subject: Re: How to Calculate Signatures?
Sender: [email-masked]

Ben Laurie wrote:
> 
> Hal Finney wrote:
> 
>> On this basis, if we did want to support the larger SHA hashes, we should
>> truncate them and keep the left 160 bits for use with existing DSA keys.
> 
> 
> Yes, please.

I'm curious on this point.  Other than the fact that
"it's broken" why is it that you see it important to
repair the DSA in OpenPGP?

iang

PS: As a point of notation for the RFC, isn't it DSS?
Or are we saying that DSA is implemented because it
is not quite DSS?
-- 
News and views on what matters in finance+crypto:
         http://financialcryptography.com/

Date: Sun, 03 Apr 2005 22:26:10 +0100
From: Ian G <[email-masked]>
Organization: http://financialcryptography.com/
To: [email-masked]
Subject: Re: How to Calculate Signatures?
Sender: [email-masked]

Hal Finney wrote:

> Unfortunately, that doesn't protect against the attack.  The ID of SHA-1
> is 2 and the ID of RIPEMD-160 is 3.  If SHA-1 were broken badly enough
> it's entirely possible that we could find m1 and m2 such that:
> 
> SHA1 (2 || m1) == RIPEMD160 (3 || m2).
> 
> The mere fact that you feed the hash algorithm ID into the hash algorithm
> doesn't stop you from finding collisions with a different, broken hash
> algorithm.

Which would seem to be mildly supportive of locking
DSA with SHA1?

> The situation is different with RSA, where you do:
> 
> RSA_Sign (Alg ID || Hash).
> 
> Now, it is impossible to get collisions using two different algorithm ID's
> because the algorithm ID is outside the hash.

And this would seem to suggest that rather than
tinkering with DSA, we should prefer a completely
new signature algorithm?

iang

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

Date: Sun, 03 Apr 2005 21:26:12 +0100
From: Ben Laurie <[email-masked]>
To: Hal Finney <[email-masked]>
Cc: [email-masked]
Subject: Re: How to Calculate Signatures?
Sender: [email-masked]

Hal Finney wrote:
> On this basis, if we did want to support the larger SHA hashes, we should
> truncate them and keep the left 160 bits for use with existing DSA keys.

Yes, please.

And "doh!" on the downgrade attack. Must think before posting.

Date: Sun, 03 Apr 2005 21:02:54 +0100
From: Ian G <[email-masked]>
Organization: http://financialcryptography.com/
To: [email-masked]
Subject: Re: How to Calculate Signatures?
Sender: [email-masked]

Ben Laurie wrote:

>> Would it be a good idea to put in a statement
>> explicitly limiting OpenPGP's view of DSS to be
>> SHA1 only?  And add a comment perhaps that in the
>> light of weaknesses in SHA1, that RSA with a fatter
>> digest be used instead as a workaround?
> 
> 
> The cost of that is that anyone with a DSA key is screwed. Seems like a 
> last resort to me.

Anyone who has a DSA key now is screwed if:

    * the SHA1 hash is shown to be breached for:
       - pre-images, or
       - they have a collision-sensitive signature system,
    and,

    * the attacks are within reach by their attackers, and
    * they cannot change their document format, and
    * they cannot change to RSA, and
    * they cannot simply repudiate any false dox, and
    * they actually use DSA sigs for something important.

Seems like a tough list to me.  My systems use OpenPGP
sigs for real stuff (as opposed to just signing mail
because it exists there) and none of the above are
even remotely a threat that I can see.  Maybe I am
screwed, but seeing as I don't see how, I'm willing to
run that risk and maybe I'll find out :)

I personally don't see much merit in changing the situation
until something decent comes along.

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

To: [email-masked]
Subject: Re: How to Calculate Signatures?
Date: Sun,  3 Apr 2005 12:45:40 -0700 (PDT)
From: [email-masked] ("Hal Finney")
Sender: [email-masked]

Ben Laurie writes:
> The hash does include the ID of the hash, and hence the signature does.

Unfortunately, that doesn't protect against the attack.  The ID of SHA-1
is 2 and the ID of RIPEMD-160 is 3.  If SHA-1 were broken badly enough
it's entirely possible that we could find m1 and m2 such that:

SHA1 (2 || m1) == RIPEMD160 (3 || m2).

The mere fact that you feed the hash algorithm ID into the hash algorithm
doesn't stop you from finding collisions with a different, broken hash
algorithm.

The situation is different with RSA, where you do:

RSA_Sign (Alg ID || Hash).

Now, it is impossible to get collisions using two different algorithm ID's
because the algorithm ID is outside the hash.

Hal

To: [email-masked]
Subject: Re: How to Calculate Signatures?
Date: Sun,  3 Apr 2005 12:39:29 -0700 (PDT)
From: [email-masked] ("Hal Finney")
Sender: [email-masked]

Konrad Rosenbaum writes:
> On Sunday 03 April 2005 18:41, Ben Laurie wrote:
> > Oh, yes. This left me with an unresolved issue: how does one use
> > SHA{256,384,512} with DSA (which requires a 160 bit hash).
>
> Simple: you don't. DSA was designed to be used with SHA-1, which is 160 bit. 
> Since SHA-1 is theoretically broken (practically will probably follow in a 
> few months) one should see what the NIST makes of it. Supplanting a broken 
> hash with another hash doesn't make much sense with DSA, since it does not 
> contain the ID of the hash (as PKCS#1 does for RSA) - so any attacker could 
> find a collission with the broken hash and then simply change the hash ID 
> in the signature packet.

I have mixed feelings on this issue.  The situation is complex:

 - RFC 2440 has always allowed hashes other than SHA-1 if they matched the
   size of q.  The only one that fit was RIPEMD-160.  This already opens
   the attack Konrad describes.  If RIPEMD-160 were badly broken, you
   could substitute it into a DSA signature using SHA-1.

 - If a hash were broken, recipients can defend against this attack by
   not trusting signatures made with that hash.  That's not all that
   bad.  We are already in a similar situation with regard to other
   cryptographic components.  If a signature algorithm were broken, people
   would have to distrust signatures made with that algorithm.  Same with
   an encryption algorithm, people would have to know not to use it.
   Even with RSA, you'd have to know not to trust signatures made with a
   broken hash.  The specific risk raised by the hash substitution attack
   is that a signer can't protect his signature against substitution
   with a broken hash, he has to rely on the verifier to know that the
   hash is broken and not to trust it.

 - The current hash breaks only allow for collisions and not preimage
   attacks.  It is still not possible, even with MD5, to create a hash
   that matches a target value.  Hashes would have to be broken much
   more severely than they are now before this would become a threat.

 - NIST is dragging their feet on incorporating SHA-2 into a new DSS.
   They have been talking about this for years.  Hopefully the new results
   will motivate them to speed things up, but "fast" in a bureaucracy
   could still mean a year or more.

 - How can we update the replacement for RFC-2440 to incorporate a new
   DSS-2 or whatever it will be called?  Do we need to update the base
   document, or can we create a separate RFC that just documents the
   new format?  Will it be a new algorithm ID, or will we overload the
   DSA algorithm ID?  These issues may slow down the incorporation of
   DSS-2 into OpenPGP even once it is announced.

For all of these reasons, I am tempted to allow the SHA-2 family with
current DSA keys, as an interim measure pending the move to DSS-2.

FIPS 180, which defines the SHA family, had a change notice to add SHA-224,
a truncated form of SHA-256.  This document,
<http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf>,
describes truncation of hash algorithms on page 73:

"Some applications may require a hash function with an output size (i.e.,
message digest size) different than those provided by the hash functions
in this Standard. In such cases, a truncated hash output may be used,
whereby a hash function with a larger output size is applied to the
data to be hashed, and the resulting output (i.e., message digest) is
truncated by selecting an appropriate number of the leftmost bits. For
example, if an output of 96 bits is desired, the SHA256 hash function
could be used (e.g., because it is available to the application), and
the leftmost 96 bits of the output are selected as the message digest,
discarding the rightmost 160 bits of the SHA-256 output."

On this basis, if we did want to support the larger SHA hashes, we should
truncate them and keep the left 160 bits for use with existing DSA keys.

Hal Finney

Date: Sun, 03 Apr 2005 19:52:55 +0100
From: Ben Laurie <[email-masked]>
To: Ian G <[email-masked]>
Cc: [email-masked]
Subject: Re: How to Calculate Signatures?
Sender: [email-masked]

Ian G wrote:
> 
> Konrad Rosenbaum wrote:
> 
>> On Sunday 03 April 2005 18:41, Ben Laurie wrote:
>>
>>> Oh, yes. This left me with an unresolved issue: how does one use
>>> SHA{256,384,512} with DSA (which requires a 160 bit hash).
>>
>>
>>
>> Simple: you don't. DSA was designed to be used with SHA-1, which is 
>> 160 bit. Since SHA-1 is theoretically broken (practically will 
>> probably follow in a few months) one should see what the NIST makes of 
>> it. Supplanting a broken hash with another hash doesn't make much 
>> sense with DSA, since it does not contain the ID of the hash (as 
>> PKCS#1 does for RSA) - so any attacker could find a collission with 
>> the broken hash and then simply change the hash ID in the signature 
>> packet.
> 
> 
> 
> I would agree with that.  There was some discussion
> on the user's list about an attempt at producing a
> code path to use SHA256... which seemed to confuse
> the issue.
> 
> Would it be a good idea to put in a statement
> explicitly limiting OpenPGP's view of DSS to be
> SHA1 only?  And add a comment perhaps that in the
> light of weaknesses in SHA1, that RSA with a fatter
> digest be used instead as a workaround?

The cost of that is that anyone with a DSA key is screwed. Seems like a 
last resort to me.

Date: Sun, 03 Apr 2005 19:50:49 +0100
From: Ben Laurie <[email-masked]>
To: Konrad Rosenbaum <[email-masked]>
Cc: [email-masked]
Subject: Re: How to Calculate Signatures?
Sender: [email-masked]

Konrad Rosenbaum wrote:
> On Sunday 03 April 2005 18:41, Ben Laurie wrote:
> 
>>Oh, yes. This left me with an unresolved issue: how does one use
>>SHA{256,384,512} with DSA (which requires a 160 bit hash).
> 
> 
> Simple: you don't. DSA was designed to be used with SHA-1, which is 160 bit. 
> Since SHA-1 is theoretically broken (practically will probably follow in a 
> few months) one should see what the NIST makes of it. Supplanting a broken 
> hash with another hash doesn't make much sense with DSA, since it does not 
> contain the ID of the hash (as PKCS#1 does for RSA) - so any attacker could 
> find a collission with the broken hash and then simply change the hash ID 
> in the signature packet.

The hash does include the ID of the hash, and hence the signature does.

Date: Sun, 03 Apr 2005 19:40:31 +0100
From: Ian G <[email-masked]>
Organization: http://financialcryptography.com/
To: [email-masked]
Subject: Re: How to Calculate Signatures?
Sender: [email-masked]

Konrad Rosenbaum wrote:
> On Sunday 03 April 2005 18:41, Ben Laurie wrote:
> 
>>Oh, yes. This left me with an unresolved issue: how does one use
>>SHA{256,384,512} with DSA (which requires a 160 bit hash).
> 
> 
> Simple: you don't. DSA was designed to be used with SHA-1, which is 160 bit. 
> Since SHA-1 is theoretically broken (practically will probably follow in a 
> few months) one should see what the NIST makes of it. Supplanting a broken 
> hash with another hash doesn't make much sense with DSA, since it does not 
> contain the ID of the hash (as PKCS#1 does for RSA) - so any attacker could 
> find a collission with the broken hash and then simply change the hash ID 
> in the signature packet.

I would agree with that.  There was some discussion
on the user's list about an attempt at producing a
code path to use SHA256... which seemed to confuse
the issue.

Would it be a good idea to put in a statement
explicitly limiting OpenPGP's view of DSS to be
SHA1 only?  And add a comment perhaps that in the
light of weaknesses in SHA1, that RSA with a fatter
digest be used instead as a workaround?

(SHA1 will remain a current issue until "something
is done".  When it was debated a month back, did we
reach a consensus to do something about it?  I got
the feeling that we didn't, but I might be just
remembering one side.)

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

From: Konrad Rosenbaum <[email-masked]>
To: [email-masked]
Subject: Re: How to Calculate Signatures?
Date: Sun, 3 Apr 2005 19:48:18 +0200
Sender: [email-masked]

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

On Sunday 03 April 2005 18:41, Ben Laurie wrote:
> Oh, yes. This left me with an unresolved issue: how does one use
> SHA{256,384,512} with DSA (which requires a 160 bit hash).

Simple: you don't. DSA was designed to be used with SHA-1, which is 160 bit=
=2E=20
Since SHA-1 is theoretically broken (practically will probably follow in a=
=20
few months) one should see what the NIST makes of it. Supplanting a broken=
=20
hash with another hash doesn't make much sense with DSA, since it does not=
=20
contain the ID of the hash (as PKCS#1 does for RSA) - so any attacker could=
=20
find a collission with the broken hash and then simply change the hash ID=20
in the signature packet.

	Konrad

--nextPart1268253.Hopp9c9hf8
Content-Type: application/pgp-signature

--nextPart1268253.Hopp9c9hf8--

Date: Sun, 03 Apr 2005 17:41:59 +0100
From: Ben Laurie <[email-masked]>
To: Ben Laurie <[email-masked]>
Cc: [email-masked]
Subject: Re: How to Calculate Signatures?
Sender: [email-masked]

Ben Laurie wrote:
> Here are proposed diffs.

Oh, yes. This left me with an unresolved issue: how does one use 
SHA{256,384,512} with DSA (which requires a 160 bit hash).

Cheers,

Ben.

Date: Sun, 03 Apr 2005 16:03:10 +0100
From: Ben Laurie <[email-masked]>
To: [email-masked]
Subject: Re: How to Calculate Signatures?
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------050504080006000107060205
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Here are proposed diffs.

Cheers,

Ben.

--------------050504080006000107060205
Content-Type: text/plain;
 name="id.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="id.diff"

--- draft-ietf-openpgp-rfc2440bis-12.txt	Tue Nov 23 18:36:41 2004
+++ draft-ietf-openpgp-rfc2440bis-12-ben.txt	Sun Apr  3 15:29:31 2005
@@ -1137,13 +1137,6 @@
      - One or more multiprecision integers comprising the signature.
        This portion is algorithm specific, as described below.
 
-   The data being signed is hashed, and then the signature type and
-   creation time from the signature packet are hashed (5 additional
-   octets).  The resulting hash value is used in the signature
-   algorithm. The high 16 bits (first two octets) of the hash are
-   included in the signature packet to provide a quick test to reject
-   some invalid signatures.
-
    Algorithm Specific Fields for RSA signatures:
 
      - multiprecision integer (MPI) of RSA signature value m**d mod n.
@@ -1154,80 +1147,10 @@
 
      - MPI of DSA value s.
 
-   The signature calculation is based on a hash of the signed data, as
-   described above.  The details of the calculation are different for
-   DSA signature than for RSA signatures.
-
-   The hash h is PKCS-1 padded exactly the same way as for the above
-   described RSA signatures.
-
-   With RSA signatures, the hash value is encoded as described in
-   PKCS-1 section 9.2.1 encoded using PKCS-1 encoding type
-   EMSA-PKCS1-v1_5 [RFC2437].  This requires inserting the hash value
-   as an octet string into an ASN.1 structure. The object identifier
-   for the type of hash being used is included in the structure.  The
-   hexadecimal representations for the currently defined hash
-   algorithms are:
-
-     - MD5:        0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05
-
-
-
-Callas, et al.          Expires May 23, 2005                  [Page 21]
-INTERNET-DRAFT          OpenPGP Message Format             Nov 23, 2004
-
-     - RIPEMD-160: 0x2B, 0x24, 0x03, 0x02, 0x01
-
-     - SHA-1:      0x2B, 0x0E, 0x03, 0x02, 0x1A
-
-     - SHA256:     0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01
-
-     - SHA384:     0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x02
-
-     - SHA512:     0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x03
-
-   The ASN.1 OIDs are:
-
-     - MD5:        1.2.840.113549.2.5
-
-     - RIPEMD-160: 1.3.36.3.2.1
-
-     - SHA-1:      1.3.14.3.2.26
-
-     - SHA256:     2.16.840.1.101.3.4.2.1
-
-     - SHA384:     2.16.840.1.101.3.4.2.2
-
-     - SHA512:     2.16.840.1.101.3.4.2.3
-
-   The full hash prefixes for these are:
-
-       MD5:        0x30, 0x20, 0x30, 0x0C, 0x06, 0x08, 0x2A, 0x86,
-                   0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05, 0x05, 0x00,
-                   0x04, 0x10
-
-       RIPEMD-160: 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2B, 0x24,
-                   0x03, 0x02, 0x01, 0x05, 0x00, 0x04, 0x14
-
-       SHA-1:      0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2b, 0x0E,
-                   0x03, 0x02, 0x1A, 0x05, 0x00, 0x04, 0x14
-
-       SHA256:     0x30, 0x31, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86,
-                   0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01, 0x05,
-                   0x00, 0x04, 0x20
-
-       SHA384:     0x30, 0x41, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86,
-                   0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x02, 0x05,
-                   0x00, 0x04, 0x30
-
-       SHA512:     0x30, 0x51, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86,
-                   0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x03, 0x05,
-                   0x00, 0x04, 0x40
-
-   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.
+   The signature calculation is based on a hash of the signed
+   data. This is described in detail in section 5.2.4. The high 16
+   bits (first two octets) of the hash are included in the signature
+   packet to provide a quick test to reject some invalid signatures.
 
 Callas, et al.          Expires May 23, 2005                  [Page 22]
 INTERNET-DRAFT          OpenPGP Message Format             Nov 23, 2004
@@ -1263,20 +1186,16 @@
      - One or more multiprecision integers comprising the signature.
        This portion is algorithm specific, as described above.
 
-   The data being signed is hashed, and then the signature data from
-   the version number through the hashed subpacket data (inclusive) is
-   hashed. The resulting hash value is what is signed.  The left 16
-   bits of the hash are included in the signature packet to provide a
-   quick test to reject some invalid signatures.
-
    There are two fields consisting of signature subpackets.  The first
    field is hashed with the rest of the signature data, while the
    second is unhashed.  The second set of subpackets is not
    cryptographically protected by the signature and should include only
    advisory information.
 
-   The algorithms for converting the hash function result to a
-   signature are described in a section below.
+   The algorithms for calculating the hash and converting the result
+   to a signature are described in section 5.2.4. The left 16 bits of
+   the hash are included in the signature packet to provide a quick
+   test to reject some invalid signatures.
 
 5.2.3.1. Signature Subpacket Specification
 
@@ -1936,7 +1855,72 @@
    resulting hash field is used in the signature algorithm, and placed
    at the end of the signature packet.
 
-5.2.4.1. Subpacket Hints
+5.2.4.1. Signature Algorithms
+
+5.2.4.1.1. DSA Signatures
+
+   A DSA signature is performed as specified in [FIPS-186-2] on the
+   value of the hash, calculated as above.
+
+   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.
+
+5.2.4.1.2. RSA Signatures
+
+   With RSA signatures, the hash value is encoded as described in
+   PKCS #1 section 9.2.1 encoded using PKCS #1 encoding type
+   EMSA-PKCS1-v1_5 [RFC2437].  This requires inserting the hash value
+   as an octet string into an ASN.1 structure. The object identifier
+   for the type of hash being used is included in the structure.
+
+   The ASN.1 OIDs are:
+
+     - MD5:        1.2.840.113549.2.5
+
+     - RIPEMD-160: 1.3.36.3.2.1
+
+     - SHA-1:      1.3.14.3.2.26
+
+     - SHA256:     2.16.840.1.101.3.4.2.1
+
+     - SHA384:     2.16.840.1.101.3.4.2.2
+
+     - SHA512:     2.16.840.1.101.3.4.2.3
+
+   In practice this amounts to prefixing the hash with one of the
+   following, then padding as described in PKCS #1:
+
+       MD5:        0x30, 0x20, 0x30, 0x0C, 0x06, 0x08, 0x2A, 0x86,
+                   0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05, 0x05, 0x00,
+                   0x04, 0x10
+
+       RIPEMD-160: 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2B, 0x24,
+                   0x03, 0x02, 0x01, 0x05, 0x00, 0x04, 0x14
+
+       SHA-1:      0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2b, 0x0E,
+                   0x03, 0x02, 0x1A, 0x05, 0x00, 0x04, 0x14
+
+       SHA256:     0x30, 0x31, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86,
+                   0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01, 0x05,
+                   0x00, 0x04, 0x20
+
+       SHA384:     0x30, 0x41, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86,
+                   0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x02, 0x05,
+                   0x00, 0x04, 0x30
+
+       SHA512:     0x30, 0x51, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86,
+                   0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x03, 0x05,
+                   0x00, 0x04, 0x40
+
+   The value emLen needed for the padding is equal to the length in
+   bytes of the RSA public modulus, n.
+
+   Once the hash has been encoded and padded, the resulting string is
+   encrypted with the RSA private key as described in [RSA].
+
+5.2.4.2. Subpacket Hints
 
    It is certainly possible for a signature to contain conflicting
    information in subpackets. For example, a signature may contain
@@ -3084,7 +3068,7 @@
        2          - RSA Encrypt-Only
        3          - RSA Sign-Only
        16         - Elgamal (Encrypt-Only), see [ELGAMAL]
-       17         - DSA (Digital Signature Algorithm) [SCHNEIER]
+       17         - DSA (Digital Signature Algorithm) [DSA]
        18         - Reserved for Elliptic Curve
        19         - Reserved for ECDSA
        20         - Reserved (formerly Elgamal Encrypt or Sign)
@@ -3946,6 +3930,10 @@
                     1983, August 1996.
    [RFC2119]        Bradner, S., "Key words for use in RFCs to Indicate
                     Requirement Level", BCP 14, RFC 2119, March 1997.
+   [FIPS186-2]      "Digital Signature Standard", FIPS 186-2, January
+                    2000.
+   [RSA]            Menezes, A., et al. "Handbook of Applied
+                    Cryptography", Section 8.2., October 1996.

--------------050504080006000107060205--

Date: Sun, 03 Apr 2005 03:53:26 +0100
From: Ben Laurie <[email-masked]>
To: Hal Finney <[email-masked]>
Cc: [email-masked]
Subject: Re: How to Calculate Signatures?
Sender: [email-masked]

Hal Finney wrote:
> Ben Laurie writes:
> 
> 
>>The sections on calculating signatures are really confusing. I can't 
>>currently suggest alternate text for most of it because its far from 
>>clear to me what the actual algorithms are. If someone explains, I'll do 
>>my best to write clarifying text.
> 
> 
> You're right, this is really messed up.
> 
> The authoritative section on what to hash is 5.2.4.  We should refer
> forward to that section and not include detailed information about
> what is hashed in the sections on V3 and V4 signature packets.
> 
> We should make it clear that the DSA signature algorithm works directly
> on the hash value that results from 5.2.4.
> 
> We should say that RSA signatures use that hash and prepend the sequence
> of bytes identified as the "full hash prefixes".  We could probably remove
> the hexadecimal equivalents to the ASN.1 OIDs; if someone understands
> ASN.1 well then the OIDs are enough, and if not then they can just
> follow the rule to prepend the proper byte sequences and that will work.
> This then gets padded as in PKCS#1 v1.5 signatures.  We should have a
> sentence clarifying that this is what gives us the value "m" used in
> the signature calculation.

We also need to specify emLen, which I presume (by logic and experiment) 
is equal to the RSA key size.

I will send diffs soon. Thanks for the clarification.

Cheers,

Ben.

To: [email-masked]
Subject: Re: How to Calculate Signatures?
Date: Sat,  2 Apr 2005 12:16:14 -0800 (PST)
From: [email-masked] ("Hal Finney")
Sender: [email-masked]

Ben Laurie writes:

> The sections on calculating signatures are really confusing. I can't 
> currently suggest alternate text for most of it because its far from 
> clear to me what the actual algorithms are. If someone explains, I'll do 
> my best to write clarifying text.

You're right, this is really messed up.

The authoritative section on what to hash is 5.2.4.  We should refer
forward to that section and not include detailed information about
what is hashed in the sections on V3 and V4 signature packets.

We should make it clear that the DSA signature algorithm works directly
on the hash value that results from 5.2.4.

We should say that RSA signatures use that hash and prepend the sequence
of bytes identified as the "full hash prefixes".  We could probably remove
the hexadecimal equivalents to the ASN.1 OIDs; if someone understands
ASN.1 well then the OIDs are enough, and if not then they can just
follow the rule to prepend the proper byte sequences and that will work.
This then gets padded as in PKCS#1 v1.5 signatures.  We should have a
sentence clarifying that this is what gives us the value "m" used in
the signature calculation.

Hal

To: [email-masked]
Subject: Re: Version hashed twice?
Date: Sat,  2 Apr 2005 12:00:46 -0800 (PST)
From: [email-masked] ("Hal Finney")
Sender: [email-masked]

The reason for the trailer in V4 sigs is to address a security weakness
in V3 sigs and their relation with V4.  The problem is that V3 key sigs
do not hash the length of the userid field, and neither version hashes
the length of the data when signing a document.  This would mean that,
if we did not have a V4 trailer, it might be possible to get someone to
V3 sign a properly constructed userid or document, and then turn that
into a V4 signature on something else.

To prevent that, we want the sequence of bytes hashed in a V4 signature to
be (a) uniquely parseable; and (b) unable to match the same sequence of
bytes hashed in any other signature version.  Uniquely parseable means
that given the sequence of bytes that were hashed, and with no other
information, you can determine with 100% reliability what the parsing
is of the data into signature packets and other packets.

V3 document signatures hash n random bytes, where n is not hashed,
and then 1 byte of signature type and 4 bytes of signature creation time.

V3 key signatures hash bytes starting with the key packet, which is
uniquely parseable because it includes the length; then the user id,
which does not include the length; then 1 byte of signature type and 4
bytes of signature creation time.

We want to make sure that no V4 signature could hash a sequence of bytes
that matches the same sequence of bytes in a V3 signature.

This is why we force the 4th byte from the end in the V4 sequence of
hashed bytes to be 0xff.  The 4th byte from the end in a V3 sequence
of hashed bytes will always be signature type, and 0xff is not a legal
signature type.  So that will ensure that V3 signatures cannot be
re-packaged as V4 signatures.

The reason we include the version number and length of hashed packets
is to ensure unique parseability.  Without the length of hashed packets
at the end, you could create a document whose V4 signature could be
applied to a different document with different subpackets in a modified
V4 signature.  By including the length of hashed packets we make it
unambiguous where the document ends and the V4 signature packet begins.

And the reason we include the version there is in case we change this
for future versions, we will have an unambiguous place where the version
number can be found, 6 bytes from the end.  The other location of version
number might not be uniquely parseable once we create new versions.
This will give us more flexibility in the future and we won't have to
worry about repackaging attacks as we did with the V3 to V4 transition.

Hal Finney

Date: Sat, 02 Apr 2005 17:49:51 +0100
From: Ben Laurie <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: How to Calculate Signatures?
Sender: [email-masked]

Once more referring to 2440bis-12...

The sections on calculating signatures are really confusing. I can't 
currently suggest alternate text for most of it because its far from 
clear to me what the actual algorithms are. If someone explains, I'll do 
my best to write clarifying text.

Firstly:

5.2.2 says:

    The signature calculation is based on a hash of the signed data, as
    described above.

Until I wrote this email, I though this sentence meant the signature 
calculation was described above. I've just realised it means that the 
hash is described above. I suggest instead:

    The signature calculation is based on the hash of the signed data
    described above.

Though since the hash is described much more usefully in 5.2.4, perhaps 
it should simply refer to that instead?

It then goes on to say:

    The details of the calculation are different for
    DSA signature than for RSA signatures.

    The hash h is PKCS-1 padded exactly the same way as for the above
    described RSA signatures.

For the life of me, I can't see an "above described RSA signature" - 
where is that? PKCS-1 is mentioned before, but for encryption, not signing.

It then goes on to describe truly revolting nastiness about PKCS-1 
(shouldn't that be written PKCS#1, incidentally?) for doing RSA 
signatures, but never, as far as I can see, says how to do a DSA 
signature. From experiment, it seems to me that a DSA signature is done 
directly on the hash, without any manipulation at all. Correct?

Then in 5.2.3:

    The algorithms for converting the hash function result to a
    signature are described in a section below.

Firstly, it would be much more friendly to say _which_ section below, 
rather than leaving the reader to guess. I'd fill that in if I could 
find the section, but I can't. The nearest I can get is 5.2.4, which says:

    After all this has been hashed in a single hash context the
    resulting hash field is used in the signature algorithm, and placed
    at the end of the signature packet.

And that appears to be it, as far as signature algorithms are concerned. 
Reading between the lines, I'm assuming that what this really means is 
that the algorithms used are exactly what I'd expect, i.e. DSA directly 
on the hash, and RSA with PKCS#1 padding and the, err, other stuff. But 
references to further descriptions that I can't find leave me in doubt!

Cheers,

Ben.

Date: Sat, 02 Apr 2005 15:06:11 +0100
From: Ben Laurie <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Version hashed twice?
Sender: [email-masked]

In a v4 signature packet, the packet version number is hashed twice, 
once in the hash of the packet data, and again in the trailer.

Why?

Cheers,

Ben.