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

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
neurohenry updated the task description. (Show Details)

SHA256 key

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: rnp 0.8.0~

xsDiBFpi/LURBACYn0aRaBowzSWyFECgWi3xF1A/u1PbrkvFoKi7zq2hFOWyNZMv0Cdfm6AgG2+w
wCTCl0j+35MrA9qw86Bsw7TYKhHTN6L9ysdBu2axAneJcfLNU8FMm0Le0oKLKsxoarpkOwhxAT4J
szyIFz5ifjJ3EjZge/KboB1eEUbASfqkAwCg596SM9mPVq9mGjlETuN/AgYMEIMD/A79zzV12QUO
MX7Yg1ADHE4JrakgXJSaXUMqPXLGqKHIPSX8SyoOHdufGUMCTi0vkFDqRF4Ckwig5eMEqq51uKwx
ptUj2B2JZqtejfcbpW/833IJffHSj6fRnJ16zUUjhqLrpOvmUCBJqwxaNLyxBlNYWyAhk8/moNZK
qm6x+igDA/9frVf1Wzk45YY1DwQMZ5gYGsRg9i5iX+nTb8BinYgSdLQrM1UXcz+PqrWfUJUz3pHc
xRcb3QqyK2skjHArSbnaN+0BqX7CV9sv3iR+eYYnH/ad4SJ87MlV5F4seR6s8b9pSaKGuIQb9Rwn
gEwbmqe4CYzj9lJ4lOB7w0iHK6KTdc0Wc2luZ2luZ3Rlc3RAc2VjdXJlLmdvdsJcBBMRCAAmBQJa
Yvy2AhsDBQsJCAcCBhUICQoLAgUWAgMBAAkQ9xPfKs3U+mwAABBWAKC4Yyxf7yfehE6csbbTn9e+
StBFuQCgnNkGluMadgK2gpMVV8uHHaKPw0A=
=nmYy
-----END PGP PUBLIC KEY BLOCK-----

Key signed with SHA1

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: rnp 0.8.0~

xsDiBFpi/r0RBACk9qIisuPPNI7PxNKiIwmd9gXa8/hAfRLLkBjx1yaNtgPXtp5+tSww6o1kEziG
BUtQ9f1dtMyjhwd2l7rAVxaja0RX93E2HF3CvDRds6vbw8gyDqJlILVu3MYV/z6ch61jnQ4nV7B7
EkrPNBRc95g5S0LGAofWj7RsACNTrdc79wCg9etWSpe4IfpLxh+mkgJInCI1fVMD/02F1+lctkE8
Mks80bNjft6rTgq+pM3dhd/UViWXFffuddGReS1bXdnINwWxTaUvwkyjH/QBO7WZ+VKExrfCf7By
OQdBA5Vf0BurJABW/W5ky8ZNmx/kKGxaawhZB6nG1cPrhlz/9XJ8VpJjqpoWyhNIRJjQNXEvXO79
XETcLPirBACMTw6T9EOPaPXhGBBDeskGQAu9hUy0t8KBlAxq+znWzQ80zDh+b9Y3SbIIPP5yGrXz
Br1nNlI8wDOAIEipfzA0J+8dOAEmBwsxj/fWmHsbXJX0YR0tZCpEZ1mViVWklrhC+fC7aSpbVO9P
qXPNb9pTdpP+evnc0EHGinD8Xkmuc80Wc2luZ2luZ3Rlc3RAc2VjdXJlLmdvdsJcBBMRAgAmBQJa
Yv69AhsDBQsJCAcCBhUICQoLAgUWAgMBAAkQ+e2+SsYNS9YAAH7KAJ4gUNr+8IlfUYSQR3/J7eXZ
M/1QuQCePq1SDmut9RGw0b37O8CLaRxMJGM=
=W25p
-----END PGP PUBLIC KEY BLOCK-----
neurohenry updated the task description. (Show Details)Jan 23 2018, 7:43 PM
neurohenry updated the task description. (Show Details)
werner added a subscriber: werner.Jan 24 2018, 8:45 AM

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?

gniibe added a subscriber: gniibe.Jan 24 2018, 9:13 AM

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.

neurohenry added a comment.EditedJan 24 2018, 12:46 PM

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/

neurohenry added a comment.EditedJan 24 2018, 3:44 PM

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

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: rnp 0.8.0~

xsDiBFponZMRBACIL5WAMGw+sZhPvX14dWX/GmrGMduYtDFFHJRvXv7tCG25XZFovz9Db3dWhnmf
oRMa2J7eVr9FjC1rzhf+ghACf4B0ITSg09+aZ/EbAbJLxnzB28k+0oOBWkkrltmsytUw4b4qDBuD
zaEKBynp/NbXPJZfPoQUVtYChcVFajnzcwCg/35nvnY8SnBpisMA9LX5dCtr1GUD/0or7CxmhOfv
W+/yo8F1E14NoJL5pFoMy9mRrXsWGixEYNt3UEl5g+n+Odp6phCr4nzNAPQhffR/gtf7xSDYM8kz
+9+cfV+yG86yXLTWJIn0GyRVkilNfrzsH+9vvOd2TPYcoK0Cqatl+f7YrIyGBPJhloezH5Grvr5l
5ANIAdKBA/9KYEyDwnV2aEhF8DIYeAC2DwQFfuubphvp9ws0kiRs49Xe9IiOpJkoJi6KMJ+JGkns
UX/yN/U5og0PablUKwAr3b8TubGirwTnsDqsiuQD4kXGrq+bBwgXHQLqXOVrDgoc10oyR9k15j2M
qs6cb2m/SEIimR7tvvEkMz6u7mjsj80kRFNBIDEwMjQtYml0IGtleSA8Zmxvd2hlckBsb2NhbGhv
c3Q+wlwEExEIACYFAlponZQCGwMFCwkIBwIGFQgJCgsCBRYCAwEACRBHzEk2/EqZfwAAnxgAn0hF
5ewu1M7YnpKDLT1BrL8raovaAKDVr/zzf4t0rm8iq5M6uOgIDLeZAQ==
=lVNz
-----END PGP PUBLIC KEY BLOCK-----

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.

stm added a subscriber: stm.Jan 24 2018, 7:07 PM

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.

neurohenry added a comment.EditedJan 24 2018, 7:41 PM

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