DSA2

[Alphax]

Robert J. Hansen wrote:
> Lionel Elie Mamane wrote:
>>>  - DSA does not support "firewalled hashes"
>> Not exactly. Version 3 DSA signatures lack a hash firewall. But
>> version 4 DSA signatures do have a hash firewall. The version refers
>> not to a version of DSA itself, but the version of the OpenPGP packet
>> format being used.
> 
> This is one of those times when the language in the RFC appears designed
> to obscure meaning, as opposed to illuminate it.  E.g., if memory serves
> we can talk about one set of versions for keys, and another set of
> versions for signatures, etc., etc.
> 
> It is my understanding--and I would welcome being pointed to language in
> the RFC showing that I am wrong--that v4 DSA keys lack a satisfactory
> hash function firewall.  If I'm correct and the problem is associated
> with keys and not certificates, then that to me would be sufficient
> reason to recommend RSA.
> 

Back to RFC 2440 we go.

Section 5.2.2. "Version 3 Signature Packet Format" says:

> The body of a version 3 Signature Packet contains:
>  - One-octet version number (3).
>  - One-octet length of following hashed material.  MUST be 5.
>      - One-octet signature type.
>      - Four-octet creation time.
>  - Eight-octet key ID of signer.
>  - One-octet public key algorithm.
>  - One-octet hash algorithm.
>  - Two-octet field holding left 16 bits of signed hash value.
>  - One or more multi-precision integers comprising the signature.
>    This portion is algorithm specific, as described below.

It then talks about how DSA differs from RSA:

> With RSA signatures, the hash value is encoded as described in PKCS-1
> section 10.1.2, "Data encoding", producing an ASN.1 value of type
> DigestInfo, and then padded using PKCS-1 block type 01 [RFC2313].
> 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.
<snip>
> DSA signatures MUST use hashes with a size of 160 bits, to match q,
> the size of the group generated by the DSA key's generator value.
> The hash function result is treated as a 160 bit number and used
> directly in the DSA signature algorithm.

Section 5.2.3. "Version 4 Signature Packet Format" says:

> The body of a version 4 Signature Packet contains:
>  - One-octet version number (4).
>  - One-octet signature type.
>  - One-octet public key algorithm.
>  - One-octet hash algorithm.
>  - Two-octet scalar octet count for following hashed subpacket
>    data. Note that this is the length in octets of all of the hashed
>    subpackets; a pointer incremented by this number will skip over
>    the hashed subpackets.
>  - Hashed subpacket data. (zero or more subpackets)
>  - Two-octet scalar octet count for following unhashed subpacket
>    data. Note that this is the length in octets of all of the
>    unhashed subpackets; a pointer incremented by this number will
>    skip over the unhashed subpackets.
>  - Unhashed subpacket data. (zero or more subpackets)
>  - Two-octet field holding left 16 bits of signed hash value.
>  - One or more multi-precision integers comprising the signature.
>    This portion is algorithm specific, as described above.
<snip>

The question is: does the "one-octect hash algorithm" field provide a
sufficient hash function firewall? My thought is that it doesn't,
because it doesn't appear to be signed.

-- 
                Alphax
        Death to all fanatics!
  Down with categorical imperative!
OpenPGP key: http://tinyurl.com/lvq4g

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 569 bytes
Desc: OpenPGP digital signature
Url : /pipermail/attachments/20060929/38c4749e/signature.pgp