Subject: Re: V4 Sig. incomplete?

From: [email-masked]
Date: Wed, 12 Jul 2000 22:39:51 -0700

> With reference to 5.4; the second last paragraph states that a version 4 
> signature has a final trailer of 6 octets, being:
>
> 0x04 or 0xFF, a four octet big endian number
>
> This is only 5 octets...does anybody know what the 6th octet is? ...or is a 
> V4 signature final trailer only 5 octets?

Where did you get the "or" in "0x04 or 0xFF"?  The spec says,

   V4 signatures also hash in a final trailer of six octets: the version
   of the signature packet, i.e. 0x04; 0xFF; a four-octet, big-endian
   number that is the length of the hashed data from the signature
   packet (note that this number does not include these final six
   octets.

I don't see an "or".  It is 0x04, 0xFF, and the four octets of length.
That is six octets.

> 1) V4 Sig., type 0x10. Hash then concatenate the following for feeding into 
> the DSA (assuming DSA sig):

I'm not sure what you mean by "hash then concatenate".  It would make
more sense to say "concatenate then hash", or more simply, just "hash".

> public DSA keys (this line not hashed)
>
> 0x99					|
> 2 octet length				|

At this point you hash the entire public key packet.  As described
in section 5.5.2 of RFC 2440, in addition to the MPI data below, this
includes a version number, creation time, validity period if V3 key,
and public key algorithm type.  This is then followed by the MPI data:

> MPI of DSA prime p			|
> MPI of DSA grooup order q		|
> MPI of DSA group generator g		|
> MPI of DSA public key value y		|

Of course a DSA signature could be over an RSA key as well.

> +
>
> user id (this line not hashed)
>
> 0xb4					|
> 4 octet length				|
> username data			|
>
> version field to end of hashable data	|

Yes, of the signature packet.

> 0x04					|

then 0xFF then

> 4 octet length				|
> ? (see previous question re 5.4)	|

This looks correct, incorporating the changes above.

> 2) V4 Sig., type 0x18. Hash then concatenate the following for feeding into 
> the DSA (assuming DSA signature keys and ElGamal encryption keys):
>
> public DSA keys (this line not hashed)
>
> 0x99					|
> 2 octet length				|

As above, other key packet information is hashed here.

> MPI of DSA prime p			|
> MPI of DSA grooup order q		|
> MPI of DSA group generator g		|
> MPI of DSA public key value y		|
>
> +
>
> public ElGamal keys (this line not hashed)
>
> 0x99					|
> 2 octet length				|

Again, other subkey packet information is hashed here.

> MPI of ElGamal prime p		|
> MPI of ElGamal grooup order q		|

Actually this is the group generator g, not the group order q.

> MPI of ElGamal public key value y	|
>
> version field to end of hashable data	|
>
> 0x04					|

As above, 0xFF goes here.

> 4 octet length				|
> ? (see previous question re 5.4)	|

Hal Finney

---

From: Erron Criddle <[email-masked]>
Date: Tue, 13 Jun 2000 14:18:17 +0800

Hal,

Many thanks for your reply - it has certainly made things clearer :)

At 10:39 PM 12/07/2000 -0700, [email-masked] wrote:

<snip>

>Where did you get the "or" in "0x04 or 0xFF"?

Obviously from some cross-linked neurons - sorry for the wasted b/w.

I have also rewritten my original question and answers - hopefully they are 
correct this time :) :

1) V4 Sig., type 0x10. Concatenate the following data then hash it for 
input into the DSA (the data to be hashed is terminated with the | char)

header data

0x99                                    |
2 octet length                          |

public DSA keys (version 4)

0x04 (version)                          |
4 octet time                            |
0x11 (for DSA signing algorithm)        |
MPI of DSA prime p                      |
MPI of DSA grooup order q               |
MPI of DSA group generator g            |
MPI of DSA public key value y           |

user id data

0xb4                                    |
4 octet length                          |
username data                   |

signature trailer

V4 signature trailer

0x04                                    |
0xFF                                    |
4 octet length                          |

All the above data is concatenated then hashed. The left 16 bits are 
inserted into the hash check field of the signature and then the hash is 
fed into the DSA for production of the signature.

2) V4 Sig., type 0x18. Concatenate the following data then hash it for 
input into the DSA (the data to be hashed is terminated with the | char)

header data

0x99                                    |
2 octet length                          |

public DSA keys (version 4)

0x04 (version)                          |
4 octet time                            |
0x11 (for DSA signing algorithm)        |
MPI of DSA prime p                      |
MPI of DSA grooup order q               |
MPI of DSA group generator g            |
MPI of DSA public key value y           |

header data

0x99                                    |
2 octet length                          |

public ElGamal keys

0x04 (version)                          |
4 octet time                            |
0x10 (for ElGamal enc. algorithm)       |
MPI of ElGamal prime p          |
MPI of ElGamal group generator g        |
MPI of ElGamal public key value y       |

signature trailer

V4 signature trailer

0x04                                    |
0xFF                                    |
4 octet length                          |

Once again, all the above data is concatenated then hashed. The left 16 
bits are inserted into the hash check field of the signature and then the 
hash is fed into the DSA for production of the signature.

> > ? (see previous question re 5.4)      |

Regards

Erron Criddle
Comasp Ltd.
Level 2, 45 Stirling Hwy
NEDLANDS  WA  6009

Fax: 08 9386 9473
Tel: 08 9386 9534

http://www.comasp.com
[email-masked]