3 ms·
Did my research here. I was expecting GnuPG to never emit a message including SHA1, just use it to verify signatures from the existing ones. A pretty sensible t
by gaius_baltar 6y ago
Did my research here. I was expecting GnuPG to never emit a message including SHA1, just use it to verify signatures from the existing ones. A pretty sensible thing, AFAIK.
To my surprise, gpg2 added SHA1 as a valid MD algo in a new key because the specification says it MUST be supported and implementations should use it if no other is found in key preferences. However it is the one with the lowest priority and will not be used with any that was generated in the last decade or had its preferences chenged to use another MD.
A key created with the default options:
gaius@baseship:/tmp$ mkdir newhome
gaius@baseship:/tmp$ gpg --homedir newhome --gen-key
gpg: WARNING: unsafe permissions on homedir '/tmp/newhome'
gpg (GnuPG) 2.2.4; Copyright (C) 2017 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
gpg: keybox '/tmp/newhome/pubring.kbx' created
Note: Use "gpg --full-generate-key" for a full featured key generation dialog.
GnuPG needs to construct a user ID to identify your key.
Real name: Gaius Baltar
Email address: baltar@defense.caprica.kob
You selected this USER-ID:
"Gaius Baltar <baltar@defense.caprica.kob>"
Change (N)ame, (E)mail, or (O)kay/(Q)uit? o
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
gpg: /tmp/newhome/trustdb.gpg: trustdb created
gpg: key 0832341A4A0CE664 marked as ultimately trusted
gpg: directory '/tmp/newhome/openpgp-revocs.d' created
gpg: revocation certificate stored as '/tmp/newhome/openpgp-revocs.d/C64E6636890D8BAACA843AFC0832341A4A0CE664.rev'
public and secret key created and signed.
pub rsa3072 2020-10-24 [SC] [expires: 2022-10-24]
C64E6636890D8BAACA843AFC0832341A4A0CE664
uid Gaius Baltar <baltar@defense.caprica.kob>
sub rsa3072 2020-10-24 [E] [expires: 2022-10-24]
gaius@baseship:/tmp$ gpg --homedir newhome --edit-key baltar
gpg: WARNING: unsafe permissions on homedir '/tmp/newhome'
gpg (GnuPG) 2.2.4; Copyright (C) 2017 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Secret key is available.
gpg: checking the trustdb
gpg: marginals needed: 3 completes needed: 1 trust model: pgp
gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: next trustdb check due at 2022-10-24
sec rsa3072/0832341A4A0CE664
created: 2020-10-24 expires: 2022-10-24 usage: SC
trust: ultimate validity: ultimate
ssb rsa3072/89519D45B7AECE4D
created: 2020-10-24 expires: 2022-10-24 usage: E
[ultimate] (1). Gaius Baltar <baltar@defense.caprica.kob>
gpg> showpref
[ultimate] (1). Gaius Baltar <baltar@defense.caprica.kob>
Cipher: AES256, AES192, AES, 3DES
Digest: SHA512, SHA384, SHA256, SHA224, SHA1
Compression: ZLIB, BZIP2, ZIP, Uncompressed
Features: MDC, Keyserver no-modify
gpg>
- upofadown 6y agoI don't know that the hash preferences in the public key are relevant to the issue talked about in the linked email thread. Currently GPG (and Sequoia) will reject the signing of keys using SHA1 if they claim to be recent. The preferences would allow you to send me two messages that used the same SHA1 hash for the signature. I would never know that it had happened as I would never see the hash, only the valid signature. Both signatures would be logically valid as they came from your assertive action.