Version hashed twice?

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.

--

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

How to Calculate Signatures?

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.

Re: Version hashed twice?

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

Re: How to Calculate Signatures?

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

Re: How to Calculate Signatures?

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) 

Re: How to Calculate Signatures?

Here are proposed diffs.

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

--- 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
 <at>  <at>  -1137,13 +1137,6  <at>  <at> 
      - 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.
 <at>  <at>  -1154,80 +1147,10  <at>  <at> 

Re: How to Calculate Signatures?

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.

--

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

Re: How to Calculate Signatures?

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.

	Konrad

Re: How to Calculate Signatures?

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

Re: How to Calculate Signatures?

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.

--

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