Problem importing DSA/1024 key signed with SHA256
Closed, InvalidPublic
Actions

Assigned To

None

Authored By

	neurohenry
	Jan 23 2018, 7:40 PM

Description

Another OpenPGP implementation has generated 2 DSA/1024 keys. One is signed with SHA256 another one is signed with SHA1.
I can't import a key signed with SHA256, but importing the one with SHA1 is OK.

I can't find any reason why such key would be wrong (by looking at RFC 4880 bis 03), but maybe I'm missing something

I get following output:

gpg: WARNING: unsafe permissions on homedir '/tmp/t1'
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: key F713DF2ACDD4FA6C: no valid user IDs
gpg: this may be caused by a missing self-signature
gpg: Total number processed: 1
gpg:           w/o user IDs: 1

Event Timeline

neurohenry created this task.Jan 23 2018, 7:40 PM

neurohenry updated the task description. (Show Details)

SHA256 key

Key signed with SHA1

neurohenry updated the task description. (Show Details)Jan 23 2018, 7:43 PM

neurohenry updated the task description. (Show Details)

If you look at the specs of DSA you will see that using SHA-256 truncated to 160 bits is not defined. DSA 1024 uses a 160 bit subgroup and thus SHA-256 would need to be truncated to 160 bits. If you want to look closer at that key the command

gpg --import -v --debug crypto

might come handy. BTW,can you tell what rnp is?

You can compare your key with a key generated by GnuPG.

You can generate DSA key by:

gpg --cert-digest-algo SHA256 --full-gen-key

and

gpg -o <KEY-FILE> -a --export KEY-ID

to export key.

To debug data,

gpg --list-packet -v

is useful.

Thank you, that's useful.

Just to clarify - I understand that's because key signature is in Version 4 Signature Packet Format. In more detail the RFC 4880 bis 03, says in 5.2.3. what's follows:

The concatenation of the data being signed and the signature data
from the version number through the hashed subpacket data (inclusive)
is hashed. The resulting hash value is what is signed.

So indeed, standard says nothing about truncation and that's actually not specific to DSA only (for example signature made with ECDSA/P-256 signing SHA-512 hash would be wrong as well) .

Situation is a bit different for V3 signatures, because same RFC says in 5.2.2

If the output size of the chosen hash is larger than the
number of bits of q, the hash result is truncated

Is my understanding correct?

Regarding 'rnp' please see here:
https://github.com/riboseinc/rnp/

Actually, I was using rightmost 160 bits of hash instead of leftmost. Key below also uses DSA/1024 with SHA256, but I'm using 160 bits from the left and it can be imported correctly

Thank you for yours help and tools

This would then be a 1024 bit DSA key according to the DSA-2 specification. Back when DSA was introduced to PGP the specs did not specify a truncation. Maybe because there were no hash algorithms larger than 160 bits at that time.

Please note that Section 13.6 of RFC 4880 says:

1024-bit key, 160-bit q, SHA-1, SHA-224, SHA-256, SHA-384, or SHA-512 hash

[...]

Note that earlier versions of this standard only allowed a 160-bit q
with no truncation allowed, so earlier implementations may not be
able to handle signatures with a different q size or a truncated
hash.

In my opinion, using DSA with truncated hash to q-size is allowed.

Regarding truncation, it seems draft of the RFC has some contradicting statements. In "5.2.2. {5.2.2} Version 3 Signature Packet Format" it says:

'''

DSA signatures MUST use hashes that are equal in size to the number
of bits of q, the group generated by the DSA key's generator value.

'''

and then

'''

If the output size of the chosen hash is larger than the number of
bits of q, the hash result is truncated to fit by taking the number
of leftmost bits equal to the number of bits of q.  This (possibly
truncated) hash function result is treated as a number and used
directly in the DSA signature algorithm.

'''

MUST is absolute requirement as per RFC2119, so it seems that second part of the statement is never the case. IMHO first part of the statement should be deleted from the final version of RFC and V4 signature should mention that hashes can be truncated.

neurohenry closed this task as Invalid.Jan 29 2018, 10:23 PM

Problem importing DSA/1024 key signed with SHA256Closed, InvalidPublicActions

Description

Event Timeline

Problem importing DSA/1024 key signed with SHA256
Closed, InvalidPublic
Actions