1666634 - OpenPGP should avoid weak crypto algorithms where possible (SHA-1, TRIPLEDES)

Status: NEW

(MailNews Core :: Security: OpenPGP, defect, P1)

Description

[neal]

Attachment: ntest.asc

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

I created the attached certificate using Thunderbird:

$ sq packet dump /tmp/ntest.asc 
Public-Key Packet, new CTB, 397 bytes
    Version: 4
    Creation time: 2020-09-18 10:02:55 UTC
    Pk algo: RSA (Encrypt or Sign)
    Pk size: 3072 bits
    Fingerprint: 5133 2611 E8F9 1FC1 1E35  AA0C EB36 B780 F581 1E9C
    KeyID: EB36 B780 F581 1E9C
  
User ID Packet, new CTB, 26 bytes
    Value: ntest <[e-mail]>
  
Signature Packet, new CTB, 463 bytes
    Version: 4
    Type: PositiveCertification
    Pk algo: RSA (Encrypt or Sign)
    Hash algo: SHA256
    Hashed area:
      Issuer Fingerprint: 5133 2611 E8F9 1FC1 1E35  AA0C EB36 B780 F581 1E9C
      Signature creation time: 2020-09-18 10:02:56 UTC
      Key expiration time: P30D
      Key flags: CS
      Symmetric algo preferences: AES256, AES192, AES128, TripleDES
      Hash preferences: SHA256, SHA384, SHA512, SHA224, SHA1     <---------------------
      Compression preferences: Zlib, BZip2, Zip, Uncompressed
    Unhashed area:
      Issuer: EB36 B780 F581 1E9C
    Digest prefix: A75C
    Level: 0 (signature over data)
  
Public-Subkey Packet, new CTB, 397 bytes
    Version: 4
    Creation time: 2020-09-18 10:02:56 UTC
    Pk algo: RSA (Encrypt or Sign)
    Pk size: 3072 bits
    Fingerprint: 9AB4 AB6D 078D 93D2 5E03  75F4 D1A9 740E EF34 2A1A
    KeyID: D1A9 740E EF34 2A1A
  
Signature Packet, new CTB, 444 bytes
    Version: 4
    Type: SubkeyBinding
    Pk algo: RSA (Encrypt or Sign)
    Hash algo: SHA256
    Hashed area:
      Issuer Fingerprint: 5133 2611 E8F9 1FC1 1E35  AA0C EB36 B780 F581 1E9C
      Signature creation time: 2020-09-18 10:02:57 UTC
      Key expiration time: P30D
      Key flags: EtEr
    Unhashed area:
      Issuer: EB36 B780 F581 1E9C
    Digest prefix: 5C31
    Level: 0 (signature over data)

The certificate advertises support for SHA-1. SHA-1 is known to have significant weaknesses, and should be avoided where possible. Also NIST deprecated 3DES in 2017.

Comment 1

[Magnus Melin [:mkmelin]]

I guess https://github.com/rnpgp/rnp/issues/1281 is relevant but not a fix on it's own.

The fix for bug 1641720 could be extended to SHA-1 too if deemed appropriate.

Comment 2

[Magnus Melin [:mkmelin]]

Now might be a good time to stop using those?

Comment 3

[Christian Riechers]

(In reply to neal from comment #0)

I created the attached certificate using Thunderbird:

$ sq packet dump /tmp/ntest.asc
...
Signature Packet, new CTB, 463 bytes
Version: 4
Type: PositiveCertification
Pk algo: RSA (Encrypt or Sign)
Hash algo: SHA256
Hashed area:
Issuer Fingerprint: 5133 2611 E8F9 1FC1 1E35 AA0C EB36 B780 F581 1E9C
Signature creation time: 2020-09-18 10:02:56 UTC
Key expiration time: P30D
Key flags: CS
Symmetric algo preferences: AES256, AES192, AES128, TripleDES
Hash preferences: SHA256, SHA384, SHA512, SHA224, SHA1 <---------------------
Compression preferences: Zlib, BZip2, Zip, Uncompressed
...
The certificate advertises support for SHA-1. SHA-1 is known to have significant weaknesses, and should be avoided where possible.
Also NIST deprecated 3DES in 2017.

It is my understanding that the presence of SHA1 (and 3DES) isn't a problem per se. It would also be present in a key generated by gpg. However, 3DES must occur last in the cipher preference list and SHA1 must occur last in the hash preference list.
This prevents algorithm shadowing, where algorithms become unusable due to being placed after 3DES/SHA1.

AES256 must be listed in one of the top three positions in the cipher preferences. This helps guarantee messages will be encrypted with AES256, a modern and strong algorithm.
SHA256 must be listed in one of the top three positions in the hash preferences. This helps guarantee messages will be signed with SHA256, a modern and strong algorithm.

The sequence of the hash algorithms could be improved though:
Hash preferences: SHA512, SHA384, SHA256, SHA224, SHA1

This would e.g. prevent SHA384 being shadowed by SHA256.

Comment 4

[neal]

(In reply to Christian Riechers from comment #3)

It is my understanding that the presence of SHA1 (and 3DES) isn't a problem per se.

SHA1 is broken and 3DES is deprecated by NIST. Their presence is a problem.