ietf-openpgp
[Top] [All Lists]

Re: V4 Sig. incomplete?

2000-07-12 23:26:57
Hal,

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

At 10:39 PM 12/07/2000 -0700, hal(_at_)finney(_dot_)org wrote:

<snip>

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

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

version field to end of hashable data   |

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

version field to end of hashable data   |

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.



> 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


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
ejc(_at_)comasp(_dot_)com












<Prev in Thread] Current Thread [Next in Thread>