5 ms·

Does modern gpg still use SHA1 for something? Or is it just kept there for backwards compatibility (e.g. checking old signatures) ?

hannob 6y ago
Some may argue that having an undefined timeframe of backwards compatibility spanning more than a decade is a sign of a broken ecosystem.
- wongarsu 6y ago
  others would argue that it's a sign of stability and maturity.
  - tptacek 6y ago
    This kind of "stability and maturity" is exactly what you don't want in a cryptosystem.
    - 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 ago
        I 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.

hannob 6y ago

Some may argue that having an undefined timeframe of backwards compatibility spanning more than a decade is a sign of a broken ecosystem.

wongarsu 6y ago
others would argue that it's a sign of stability and maturity.
- tptacek 6y ago
  This kind of "stability and maturity" is exactly what you don't want in a cryptosystem.
  - 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 ago
      I 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.