[openpgp] Default preferences for the future

[Ryru]

Hi list,

For RFC4880bis[0] in section 14.2. {13.2.} it's planned to stick with
TripleDES as least common denominator preference for a symmetric
algorithm. I suggest to switch to AES128, AES192 or even AES256 as least
common denominator preference.

These are my thoughts:
* AES is a good and more modern alternative to TripleDES
* AES has wide HW support (better performance)
* This RFC shall last for a couple of years, a reasonable algorithm
and key length should be defined

I'm aware of Werner Kochs suggestion for deprecate legacy hash
algorithms[1]. In the current RFC4880bis[0] section 14.3.2 {13.3.2}
still mentions SHA1 as a MUST-implementation as well as an default
hashing preference. I suggest to deprecate SHA1 and remove it as a
default preference and switch to SHA256 or even SHA512.

These are my thoughts:
* SHA1 is broken
* This RFC shall last for a couple of years, a reasonable algorithm
should be defined

I also broached this topic at the GnuPG mailing list[2].

Best regards,
Pascal

[0] https://tools.ietf.org/html/draft-ietf-openpgp-rfc4880bis-01
[1] https://www.ietf.org/mail-archive/web/openpgp/current/msg08807.html
[2] https://lists.gnupg.org/pipermail/gnupg-users/2017-March/057882.html

[Mark D. Baushke]

As an editorial remark, it would be nice if rfc4880bis were to use
a consistent representation for the secure hash algorithm families.
SHA1 is sometimes written as SHA1 and sometimes written as SHA-1.

I will also note that "SHA224" "SHA256" "SHA384" "SHA512" "SHA-224"
"SHA-256" "SHA-384" and "SHA-512" might want to be more completely
specified as members of the SHA-2 family [FISP180] by using the tag
"SHA2-224" "SHA2-256" "SHA2-384" and "SHA2-512" as the algorithm name in
section 9.5 as compared with members of the SHA-3 [FIPS202] family of
algorithms: SHA3-224, SHA3-256, SHA3-384, SHA3-512 (noting that the
SHA-3 family are NOT YET a part of rfc4880bis).

https://tools.ietf.org/html/draft-ietf-openpgp-rfc4880bis-01

Suggested update to section 9.3:
----------%<----------%<----------%<----------%<----------%<----------
9.3. {9.2} Symmetric-Key Algorithms

+-----------+-----------------------------------------------+
| ID | Algorithm |
+-----------+-----------------------------------------------+
| 0 | Plaintext or unencrypted data |
| 1 | IDEA [IDEA] |
| 2 | TripleDES (DES-EDE, [SCHNEIER] [HAC] |
| | - 168 bit key derived from 192) |
| 3 | CAST5 (128 bit key, as per [RFC2144]) |
| 4 | Blowfish (128 bit key, 16 rounds) [BLOWFISH] |
| 5 | Reserved |
| 6 | Reserved |
| 7 | AES with 128-bit key [AES] |
| 8 | AES with 192-bit key |
| 9 | AES with 256-bit key |
| 10 | Twofish with 256-bit key [TWOFISH] |
| 11 | Camellia with 128-bit key [RFC3713] |
| 12 | Camellia with 192-bit key |
| 13 | Camellia with 256-bit key |
| 100--110 | Private/Experimental algorithm |
+-----------+-----------------------------------------------+

Implementations SHOULD implement TripleDES. Implementations MUST
implement AES-128. Implementations MAY implement CAST5.
Implementations that interoperate with PGP 2.6 or earlier need to
support IDEA, as that is the only symmetric cipher those versions
use. Implementations MAY implement any other algorithm.

----------%<----------%<----------%<----------%<----------%<----------

and suggested update to section 9.5:

----------%<----------%<----------%<----------%<----------%<----------
9.5. {9.4} Hash Algorithms

+-----------+---------------------------------+--------------+
| ID | Algorithm | Text Name |
+-----------+---------------------------------+--------------+
| 1 | MD5 [HAC] | "MD5" |
| 2 | SHA-1 [FIPS180] | "SHA1" |
| 3 | RIPE-MD/160 [HAC] | "RIPEMD160" |
| 4 | Reserved | |
| 5 | Reserved | |
| 6 | Reserved | |
| 7 | Reserved | |
| 8 | SHA2-256 [FIPS180] | "SHA256" |
| 9 | SHA2-384 [FIPS180] | "SHA384" |
| 10 | SHA2-512 [FIPS180] | "SHA512" |
| 11 | SHA2-224 [FIPS180] | "SHA224" |
| 100--110 | Private/Experimental algorithm | |
+-----------+---------------------------------+--------------+

Implementations SHOULD implement SHA-1. Implementations MUST
implement SHA256. Implementations MAY implement other algorithms.
MD5 and RIPE-MD/160 are deprecated.

----------%<----------%<----------%<----------%<----------%<----------


Plus changes to 14.3.2:
----------%<----------%<----------%<----------%<----------%<----------
14.3.2. {13.3.2} Hash Algorithm Preferences

Typically, the choice of a hash algorithm is something the signer
does, rather than the verifier, because a signer rarely knows who is
going to be verifying the signature. This preference, though, allows
a protocol based upon digital signatures ease in negotiation.

Thus, if Alice is authenticating herself to Bob with a signature, it
makes sense for her to use a hash algorithm that Bob's software uses.
This preference allows Bob to state in his key which algorithms Alice
may use.

Since SHA256 is the MUST-implement hash algorithm, if it is not
explicitly in the list, it is tacitly at the end. However, it is
good form to place it there explicitly.

----------%<----------%<----------%<----------%<----------%<----------

-- Mark

[Werner Koch]

Post by Mark D. Baushke
As an editorial remark, it would be nice if rfc4880bis were to use
a consistent representation for the secure hash algorithm families.
SHA1 is sometimes written as SHA1 and sometimes written as SHA-1.

Thanks for this suggestion which I pushed right now.

I have not yet looked at your other change requests, though.

Post by Mark D. Baushke
14.3.2. {13.3.2} Hash Algorithm Preferences
Since SHA256 is the MUST-implement hash algorithm, if it is not

I changed this from "SHA-1" to "SHA2-256".


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

[Mark D. Baushke]

Post by Werner Koch

Post by Mark D. Baushke
As an editorial remark, it would be nice if rfc4880bis were to use
a consistent representation for the secure hash algorithm families.
SHA1 is sometimes written as SHA1 and sometimes written as SHA-1.

Thanks for this suggestion which I pushed right now.

Thank you.

Post by Werner Koch
I have not yet looked at your other change requests, though.

Mostly I was trying to hit the SHA-1 to transition to SHA2-256.

I think TripleDES needs to go from a MUST to a SHOULD algorithm.

I think AES128 needs to be a MUST algoirthm.

I think that RIPEMD160 needs to be a SHOULD NOT algorithm.

I think that AES256 needs to be a SHOULD algorithm.

Post by Werner Koch

Post by Mark D. Baushke
14.3.2. {13.3.2} Hash Algorithm Preferences
Since SHA256 is the MUST-implement hash algorithm, if it is not

I changed this from "SHA-1" to "SHA2-256".

Good.

Being consistent and clear is important.

-- Mark

[Robert J. Hansen]

Post by Mark D. Baushke
I think TripleDES needs to go from a MUST to a SHOULD algorithm.

I don't see much point in dragging 3DES along with us into the future. It's
done excellent service for 40 years, but the time has come to put it out to
pasture.

Post by Mark D. Baushke
I think AES128 needs to be a MUST algorithm ... AES256 needs to
be a SHOULD algorithm.

What's the rationale here? Why should the shorter keylength be required and
the longer optional?

[Mark D. Baushke]

Post by Robert J. Hansen

Post by Mark D. Baushke
I think TripleDES needs to go from a MUST to a SHOULD algorithm.

I don't see much point in dragging 3DES along with us into the future.
It's done excellent service for 40 years, but the time has come to put
it out to pasture.

I suppose it depends on how many messages you have encrypted that used
TripleDES as the algorithm. If you don't have an archive of encrypted
messages, then dropping TripleDES is not a big deal for you.

Post by Robert J. Hansen

Post by Mark D. Baushke
I think AES128 needs to be a MUST algorithm ... AES256 needs to
be a SHOULD algorithm.

What's the rationale here? Why should the shorter keylength be
required and the longer optional?

RFC4880 had AES128 as a SHOULD algorithm. Making it a MUST algorithm now
should not be a problem for most implmentations.

I do not object to making AES256 a MUST algorithm.

That said, if someone is using a symmetric key encryption from a pass
phrase, they are not really getting a very strong key. Certainly not one
that has 128 bits of randomness in it.

To get the most out of AES256, one needs enough entropy to properly seed
a PRNG to get 256 bits out of it. If one is using something like an
HMAC_DRBG with hmac-sha256, then really the entropy coming out of your
random number generator is only going to have 128 bits of security. So,
is there a real need to use AES256 for encryption if that is not how
many bits. I will grant you that a number of platforms are able to
provide 256 bits of strength, but not all of them.

A standard GNU/Linux system today which does not use a hardware source
of entropy and is only collecting mouse clicks and process interrupts is
not generally getting a lot of entropy for keys.

If I know that I have an OS that is using a hardware source of entropy,
then I have no problems using the stronger AES256 random key.

However, why use that much work if you know that the key is not really
that random?

-- Mark

[Robert J. Hansen]

Post by Mark D. Baushke
I suppose it depends on how many messages you have encrypted that used
TripleDES as the algorithm. If you don't have an archive of encrypted
messages, then dropping TripleDES is not a big deal for you.

I view this like the RFC1991->RFC2440 transition, where although we couldn't
drop IDEA completely we certainly made it clear an implementation probably
shouldn't use it. I suggest we take the same approach for 3DES. I agree
with you that being able to decrypt existing traffic is a good thing, but
I'd like to see strong language advising it not be used for generating new
traffic.

Post by Mark D. Baushke
RFC4880 had AES128 as a SHOULD algorithm. Making it a MUST algorithm now
should not be a problem for most implmentations.

Agreed.

Post by Mark D. Baushke
I do not object to making AES256 a MUST algorithm.

Thank you. :)

Post by Mark D. Baushke
To get the most out of AES256, one needs enough entropy to properly seed
a PRNG to get 256 bits out of it... [good explanation snipped]

Built-in hardware random number generators are increasingly commonplace
nowadays. See, e.g., Ivy Bridge and later architectures.

[Mark D. Baushke]

Post by Robert J. Hansen

Post by Mark D. Baushke
To get the most out of AES256, one needs enough entropy to properly seed
a PRNG to get 256 bits out of it... [good explanation snipped]

Built-in hardware random number generators are increasingly commonplace
nowadays. See, e.g., Ivy Bridge and later architectures.

Tell the Linux kernel folks to trust RDSEED or RDRAND instructions...
:-) Right a GNU/Linux user should use rng-tools to inject entropy into
the kernel by grabbing bits out of the RDRAND or RDSEED instructions.

-- Mark

[Robert J. Hansen]

Post by Mark D. Baushke
Tell the Linux kernel folks to trust RDSEED or RDRAND instructions...

Oh, good grief. Here's "a Linux kernel folk" on RDRAND:
https://www.change.org/p/linus-torvalds-remove-rdrand-from-dev-random-4/resp
onses/9066

Don't like RDRAND? Fine, don't use it. But please, don't tell me hardware
RNGs are rare or exotic nowadays. They're not. On consumer and
server-grade hardware they're as common as dirt, and I'd like it if the
OpenPGP spec reflected that reality.

[HANSEN, TONY L]

FIPS 180-4 also defines SHA2-512/224 and SHA2-512/256. Should they be added to the table?

Tony Hansen

On 3/20/17, 7:14 PM, "openpgp on behalf of Mark D. Baushke" <openpgp-***@ietf.org on behalf of ***@juniper.net> wrote:

As an editorial remark, it would be nice if rfc4880bis were to use
a consistent representation for the secure hash algorithm families.
SHA1 is sometimes written as SHA1 and sometimes written as SHA-1.

I will also note that "SHA224" "SHA256" "SHA384" "SHA512" "SHA-224"
"SHA-256" "SHA-384" and "SHA-512" might want to be more completely
specified as members of the SHA-2 family [FISP180] by using the tag
"SHA2-224" "SHA2-256" "SHA2-384" and "SHA2-512" as the algorithm name in
section 9.5 as compared with members of the SHA-3 [FIPS202] family of
algorithms: SHA3-224, SHA3-256, SHA3-384, SHA3-512 (noting that the
SHA-3 family are NOT YET a part of rfc4880bis).

https://tools.ietf.org/html/draft-ietf-openpgp-rfc4880bis-01
----------%<----------%<----------%<----------%<----------%<----------
…
and suggested update to section 9.5:

----------%<----------%<----------%<----------%<----------%<----------
9.5. {9.4} Hash Algorithms

+-----------+---------------------------------+--------------+
| ID | Algorithm | Text Name |
+-----------+---------------------------------+--------------+
| 1 | MD5 [HAC] | "MD5" |
| 2 | SHA-1 [FIPS180] | "SHA1" |
| 3 | RIPE-MD/160 [HAC] | "RIPEMD160" |
| 4 | Reserved | |
| 5 | Reserved | |
| 6 | Reserved | |
| 7 | Reserved | |
| 8 | SHA2-256 [FIPS180] | "SHA256" |
| 9 | SHA2-384 [FIPS180] | "SHA384" |
| 10 | SHA2-512 [FIPS180] | "SHA512" |
| 11 | SHA2-224 [FIPS180] | "SHA224" |
| 100--110 | Private/Experimental algorithm | |
+-----------+---------------------------------+--------------+

Implementations SHOULD implement SHA-1. Implementations MUST
implement SHA256. Implementations MAY implement other algorithms.
MD5 and RIPE-MD/160 are deprecated.

----------%<----------%<----------%<----------%<----------%<----------

[Mark D. Baushke]

Post by HANSEN, TONY L
FIPS 180-4 also defines SHA2-512/224 and SHA2-512/256. Should they be added to the table?

SHA2-512/224 protects roughly 112 bits of security, so it would be fine
for TripleDES, but not much else. I would say it is not needed.

SHA2-512/256 works great on a 64-bit machine, but is a lot slower than
SHA2-256 on a 32-bit machine and protects 128 bits of security. I don't
really care if it gets used or not. I am guessing that 8-bit and 16-bit
implementations will care a lot more.

FIPS 202 also defines four cryptographic hash functions (SHA-3) and two
extensible-output functions (XOFs) called SHAKE128 and SHAKE256. All of
the SHA-3 family of hashes are very slow in software, but could be
effectively implemented in hardware. The one thing we know as a result
of the SHA-3 bake-off is that SHA-2 is a lot stronger than we thought
and we do not yet really need SHA-3. That said, if you want to add
agility to OpenPGP, you could define SHA3-256 and SHA3-512 code points.
I see little point in any of the other alternatives.

-- Mark

[Werner Koch]

Post by Mark D. Baushke
and we do not yet really need SHA-3. That said, if you want to add
agility to OpenPGP, you could define SHA3-256 and SHA3-512 code points.
I see little point in any of the other alternatives.

I added these codepoints to the list of hash algorithms.

| 12 | SHA3-256 [FIPS202] | "SHA3-256" |
| 13 | Reserved | |
| 14 | SHA3-512 [FIPS202] | "SHA3-512" |

Okay?

I also updated the reference to FIPS documents to the latest versions.


Salam-Shalom,

Werner

[Mark D. Baushke]

Post by Werner Koch

Post by Mark D. Baushke
and we do not yet really need SHA-3. That said, if you want to add
agility to OpenPGP, you could define SHA3-256 and SHA3-512 code points.
I see little point in any of the other alternatives.

I added these codepoints to the list of hash algorithms.
| 12 | SHA3-256 [FIPS202] | "SHA3-256" |
| 13 | Reserved | |
| 14 | SHA3-512 [FIPS202] | "SHA3-512" |
Okay?

Yeah, this seems reasonable to me.

I do worry a little bit that we are adding more flexibility than we need
today which could make it more painful for all implementations to
properly interoperate.

Post by Werner Koch
I also updated the reference to FIPS documents to the latest versions.

Okay.

-- Mark

[Werner Koch]

Post by Mark D. Baushke
I do worry a little bit that we are adding more flexibility than we need
today which could make it more painful for all implementations to
properly interoperate.

I can understand that. But for sure people will ask for those algo ids
and eventually the IETF will assign them anyway. Thus we save
discussion here in the WG and move that to the implementers which now
need to explain why they do not want to support SHA3.

Interoperability is only an issue for signed-only documents because for
encryption we use the preference system. These problems are not much
different than the status quo.

I won't insist on having the SHA3 code points, though.


Salam-Shalom,

Werner

[Werner Koch]

Post by Ryru
For RFC4880bis[0] in section 14.2. {13.2.} it's planned to stick with
TripleDES as least common denominator preference for a symmetric

Nope, that is for sure not the case. We are incrementally reworking
RFC-4880 and have not yet reached the algorithm selection. I merely
started that with my proposal to make SHA-256 mandatory.

Frankly, there are more important and controversial things to do than
the algorithm selection.

Thanks for your reminder.


Salam-Shalom,

Werner