3 ms·

This is one of the many ways that shows how broken (in the "defective software" sense, not necessarily directly the cryptographic sense, yet) the entire PGP/GPG

This is one of the many ways that shows how broken (in the "defective software" sense, not necessarily directly the cryptographic sense, yet) the entire PGP/GPG ecosystem is.

pmoriarty 6y ago
Just like git, which has much wider impact, considering how many more people use software from git than use pgp or gpg.
- saghm 6y ago
  I don't think git isn't using SHA1 for security though (outside of potentially when signing commits, but that's generally done with gpg, which you drew a distinction with). Assuming you're talking about commit hashes, I'm not particularly worried about the threat of a someone crafting a commit with a malicious hash to my repo because I have much bigger issues than commit hash duplicates if someone malicious is able to commit to my repo. Given that, SHA1 is just as safe to use for my commit hashes as it's always been; the fact that crafting collisions purposely has gotten easier doesn't make accidental collisions any more likely to happen.
  - account42 6y ago
    > I have much bigger issues than commit hash duplicates if someone malicious is able to commit to my repo On github, all forks of a repo shared the commit objects.
gaius_baltar 6y ago
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
Au contraire, this is a good example of how well the PGP/GPG ecosystem deals with the realities of a long term cryptography standard. People with SHA1 hashes in their signatures have a reasonable way to transition away from those signatures while maintaining the reputation of those identities. There really isn't anything out there as good. I should also point out that that the attack this is addressing (Shambles) has close to no practical implications. So this is a good example of how the PGP/GPG ecosystem takes security breakage very seriously.

This is one of the many ways that shows how broken (in the "defective software" sense, not necessarily directly the cryptographic sense, yet) the entire PGP/GPG ecosystem is.

pmoriarty 6y ago

Just like git, which has much wider impact, considering how many more people use software from git than use pgp or gpg.

saghm 6y ago
I don't think git isn't using SHA1 for security though (outside of potentially when signing commits, but that's generally done with gpg, which you drew a distinction with). Assuming you're talking about commit hashes, I'm not particularly worried about the threat of a someone crafting a commit with a malicious hash to my repo because I have much bigger issues than commit hash duplicates if someone malicious is able to commit to my repo. Given that, SHA1 is just as safe to use for my commit hashes as it's always been; the fact that crafting collisions purposely has gotten easier doesn't make accidental collisions any more likely to happen.
- account42 6y ago
  > I have much bigger issues than commit hash duplicates if someone malicious is able to commit to my repo On github, all forks of a repo shared the commit objects.

gaius_baltar 6y ago

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

Au contraire, this is a good example of how well the PGP/GPG ecosystem deals with the realities of a long term cryptography standard. People with SHA1 hashes in their signatures have a reasonable way to transition away from those signatures while maintaining the reputation of those identities. There really isn't anything out there as good. I should also point out that that the attack this is addressing (Shambles) has close to no practical implications. So this is a good example of how the PGP/GPG ecosystem takes security breakage very seriously.