TODO:
- S2K stuff
- MUST NOT for old-style checksums
Re 3.7.2.2:
PGP 2.X always used IDEA with Simple string-to-key conversion when encrypting a message with a symmetric algorithm. This is deprecated, but MAY be used for backward-compatibility.
IDEA with the simple string-to-key algorithm MUST NOT be generated.
Implementations MAY provide an option to permit decrypting existing messages encrypted using this mode; if they do so, they MUST NOT enable decryption of such messages by default. Enabling this support MUST require explicit user confirmation.
Implementations SHOULD accept V3 signatures. Implementations SHOULD generate V4 signatures.
RFC 4880 5.2:
Implementations MUST NOT generate V3 signatures under any circumstance.
QUESTION: Are there any problems with V3 signatures? (Provided that a strong hash function is chosen...) QUESTION: Is there any use for them? They're considerably simpler than V4 signatures. But V4 support is a requirement for supporting new keys.
RFC 4880 5.2.3:
The body of a version 4 Signature packet contains: . . .
- Unhashed subpacket data set (zero or more subpackets).
Implementations MUST NOT generate unhashed subpackets. They MUST NOT parse the contents of unhashed subpackets; they MUST treat the packets as if they contained unrecognized subpacket types. They SHOULD strip unhashed subpackets from any key material prior to exporting it.
RATIONALE: Processing unauthenticated data is an unnecessary security risk.
Subpackets that must be emitted:
Implementations MUST set the no-modify key preference flag, with the critical bit set; this subpacket must therefore be 0xc0.
Implementations MUST support type 18 and 19 packets, and MUST indicate this support by including a features packet with the modification detection code bit set.
[Add obvious rationale.]
???? Are there security issues here?
[T]he wishy-washy language here allows a receiver to be generous in what they accept, while putting pressure on a creator to be stingy in what they generate.
Rationale:
Experience with the validation of complex formats has shown that being over-generous in accepting syntactically or semantically invalid constructions gives attackers excessive freedom. TODO citations
Therefore, an implementation SHOULD reject signatures that contain conflicting subpackets as malformed.
[Citation needed; various ASN1, X509 issues.]
V3 keys are deprecated; an implementation MUST NOT generate a V3 key, but MAY accept it.
RFC 4880 5.2.2
Implementations MUST NOT generate V3 keys. They MUST NOT accept V3 keys for any purpose, except that
- if an implementation supports "keyrings", and has a locally stored copy of a V3 public key in an existing "keyring", it MAY support verifying signatures using that key;
- an implementation MAY support using a V3 private key to decrypt messages, but it MUST NOT import such a key into a "keyring";
provided that these features require the user explicitly setting an option to enable them.
New implementations SHOULD NOT support V3, even subject to the limitations noted above.
[This idea of user consent should be factored.]
[Move to implementation notes. Note compression security issues?]
Implementations should be aware that -- regardless of the preferences in a user's key -- many new OpenPGP implementations do not support Bzip2 compression. Because users may use the same key with a different OpenPGP implementation than the one that generated it . . .
Implementations MUST NOT generate tag 9 packets.
Implementations MUST NOT accept tag 9 packets, except subject to the following requirements:
- a user MUST explicitly confirm decryption of a tag 9 packet at the time decryption is attempted
- if the packet is unsigned implementation MUST warn that the decrypted contents may have been modified
- the implementation MUST NOT support outputting decrypted data except to a file (in particular, implementations MUST NOT output decrypted data on standard output)
- the implementation MUST ignore any filename provided in a literal packet contained inside the packet composition enciphered with the tag 9 packet
- the implementation MUST NOT offer any permanent configuration options that disables any of these protections.
Implementations that operate without human interaction MUST NOT accept or process tag 9 packets under any circumstances.
The symmetric cipher used may be specified in a Public-Key or Symmetric-Key Encrypted Session Key packet that precedes the Symmetrically Encrypted Data packet. In that case, the cipher algorithm octet is prefixed to the session key before it is encrypted. If no packets of these types precede the encrypted data, the IDEA algorithm is used with the session key calculated as the MD5 hash of the passphrase, though this use is deprecated.
New implementations MUST NOT support IDEA with MD5 for any purposes. They MUST NOT offer to decrypt data
[Add cites; attacks on unauthenticated encryption...]
The body of this packet consists of:
- A one-octet field that describes how the data is formatted.
Implementations MUST NOT generate any value other than 'b' or 'u'. If the field is 'u', the implementation MUST only emit valid UTF-8 text; an implementation must not emit NULL characters except at the end of the packet.
An implementation processing a packet SHOULD reject as invalid any packet with type 'u' that contains material other than valid non-null UTF-8 followed by any number of null characters.
((citation to UTF-8, Unicode security considerations))
Implementations MAY accept any of the values specified in RFC4480.
Trust packets MUST NOT be emitted to output streams that are transmitted to other users. They MUST be ignored on any input other than local keyring files.
User ID packets MUST NOT contain any non-graphical characters; they MUST consist of a string of valid, non-null UTF-8 characters.
0: plaintext or unencrypted data. Implementations MUST NOT accept tag 18 packets using this encryption type. ((cite to NULL cipher TLS))
((This duplicates 13.4, but good to have in one place))
1: IDEA. Broken 2012; only 128-bit security; large classes of weak keys.
Khovratovich, D.; Leurent, G.; Rechberger, C. "Narrow-Bicliques: Cryptanalysis of Full IDEA". Advances in Cryptology – EUROCRYPT 2012 http://dx.doi.org/10.1007/978-3-642-29011-4_24
Daemen, Joan; Govaerts, Rene; Vandewalle, Joos (1993), "Weak Keys for IDEA", Advances in Cryptology, CRYPTO 93 Proceedings: 224–231
Biryukov, Alex; Nakahara, Jorge Jr.; Preneel, Bart; Vandewalle, Joos, "New Weak-Key Classes of IDEA", Information and Communications Security, 4th International Conference, ICICS 2002, Lecture Notes in Computer Science 2513: 315–326,
Keying option 1 provides less than 2^128 security, deprecated by NIST:
http://csrc.nist.gov/publications/nistpubs/800-67-Rev1/SP-800-67-Rev1.pdfc
128-bit security strength. Cf:
CAST5.Footnote iii Acceptable modes of operation are the same as those defined for AES. The 128-bit version of CAST5 is currently valid for all levels of Protected information. . . . For the 80-bit version, the cryptoperiod shall not exceed 24 hours. For the 128-bit version, the cryptoperiod shall not exceed 7 days.
https://www.cse-cst.gc.ca/en/node/227/html/15164 CSEC Approved Cryptographic Algorithms for the Protection of Sensitive Information and for Electronic Authentication and Authorization Applications within GC
Tom Gonzalez (January 2007). "A Reflection Attack on Blowfish". JOURNAL OF LATEX CLASS FILES. Jump up ^ Orhun Kara and Cevat Manap (March 2007). "A New Class of Weak Keys for Blowfish". FSE 2007.
http://www.iacr.org/archive/fse2007/45930168/45930168.pdf
I recommend Twofish instead [of Blowfish]
Implementations SHOULD use cryptographic primitives with a security strength strictly greater than 180 bits by default.
Practicality of multi-target attack:
http://www.ietf.org/mail-archive/web/cfrg/current/msg04824.html
Implementations MUST NOT support MD5 for any purposes except the use of V3 private keys for decryption subject to the limitations above.
Implementations MUST NOT generate signatures over SHA-1 hashes. Implementations SHOULD NOT accept, or recognize as valid, signatures over SHA-1 hashes, after January 2015. Implementations MUST NOT accept or use SHA-1 hashes for any purpose, other than the MDC or V4 fingerprint, after January 2016.
((cite deprecation of SHA-1 certs))
Implementations MUST NOT sign SHA-224 hashes. They SHOULD NOT accept signatures over SHA-224 hashes.
((collision resistance of 112-bits))
Implementations SHOULD NOT sign SHA-256 hashes. They MUST NOT default to signing SHA-256 hashes.
The security strength of SHA-224 and SHA-256 is adequate for S2K, where collision-resistance is not required.
Implementations SHOULD use SHA-512 for RSA or DSA signatures. They SHOULD NOT use SHA-384.
((cite to affine padding attacks; unproven status of RSA-PKCSv15))
Implementations SHOULD ignore the symmetric algorithm preferences of a recipient's public key; in particular, implementations MUST NOT choose an algorithm forbidden by this document because a recipient prefers it.
NEEDCITE downgrade attacks on TLS, other protocols
Implementations MUST ignore the hash algorithm preferences of a recipient when signing a message to a recipient. The difficulty of forging a signature under a given key, using generic attacks on hash functions, is the difficulty of the weakest hash signed by that key.
NEEDCITE
Implementations MUST default to using SHA-512 for RSA signatures, and either SHA-512 or the matched instance of SHA-2 for ECDSA signatures.
TODO: Ed25519
CITE: zooko's hash function table CITE: distinguishers on SHA-256
Implementations MAY omit support for DSA. Implementations MUST support generating either ECDSA, RSA, or Ed25519 signatures. Implementations SHOULD support encrypting to RSA and ElGamal keys; they MAY generate new RSA or ElGamal keys. They SHOULD, by default, generate ECDSA or Ed25519 keys for signing, and ECDH keys for encryption.
((recommend P384 for ECDH due to twist-security?))
CITE deterministic ECDSA nonce RFC
((add key-length guidelines))
Implementations MUST NOT generate RSA keys with a bitlength less than 2048 bits. After January 1, 2015, implementations MUST NOT generate RSA keys with a bitlength less than 3172 bits. After January 1, 2018, implementations MUST NOT generate new RSA keys.
Implementations MUST NOT accept, or treat any signature as valid, by an RSA key with bitlength less than 1023 bits. Implementations MUST NOT accept any RSA keys with bitlength less than 2047 bits after January 1, 2016.
One of the methods of B.3.2-6 MUST be used.
(What are implementations doing?)
CITE: Yung and Young on subliminal channels
Tentative:
Implementations MUST NOT generate DSA keys with a bitlength less than 2048 bits. Implementations are reminded that, per DSS, only SHA-2 may be used with keys of this bitlength. After January 1, 2015, implementations MUST NOT generate DSA keys with a bitlength less than 3172.
Implementations SHOULD use one of the DSA fields specified in TODO lookup RFC
If DSA parameters are generated randomly, the method of FIPS-186-4 MUST be used with SHA-512 as the approved hash function. The proof of generation MUST be stored in an implementation-defined format.
Implementations MUST use the method of FIPS-186-4 A.1.1.3 to generate DSA p and q parameters for all new keys. They MUST save the domain_parameter_seed for later verification; the format is implementation described.
They MUST use the method of A.2.3 to generate the generator g.
QQQQ: should there be a signature notation to include this info?
Implementations MUST NOT support ElGamal keys of bitlength less than 1024 bits. Implementations...etc.
Must either generate by modular reduction from a number twice the bitlength, or by reject and increment. Must generate seed from a 32B random number using HKDF. MUST save proof with private key.
http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf
Implementations SHOULD use Ed25519, X25519, etc. in preference to SECP curves unless they require a higher security strength.
PKCSv15 padding. Implementations MUST NOT use any method that reveals timing information to an attacker. A simple method to check PKCSv15 signatures is to generate the form the signature should take and then compare, using a "constant time" method, the recovered encoded hash and the generated encoded hash.
CITE TO Bernstein papers, cross-vm attacks, etc.
Implementations MUST NOT generate or accept V2 public-key packets under any circumstances; the exceptions for V3 public-keys supra do not apply.
0xa9 back signatures MUST be present; keys that are not cross-signed MUST be rejected.
Implementations SHOULD support RSA public keys of at least 8192 bits.