Top-to-bottom review. #50
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
dconnolly
reviewed
Jul 24, 2024
Remove reference to Picnic Co-authored-by: Deirdre Connolly <[email protected]>
tireddy2
reviewed
Jul 30, 2024
tireddy2
reviewed
Jul 30, 2024
tireddy2
reviewed
Jul 30, 2024
tireddy2
reviewed
Jul 30, 2024
tireddy2
reviewed
Jul 30, 2024
tireddy2
reviewed
Jul 30, 2024
tireddy2
reviewed
Jul 30, 2024
tireddy2
reviewed
Jul 30, 2024
tireddy2
reviewed
Jul 30, 2024
tireddy2
reviewed
Aug 2, 2024
tireddy2
reviewed
Aug 2, 2024
tireddy2
reviewed
Aug 2, 2024
tireddy2
reviewed
Aug 2, 2024
tireddy2
reviewed
Aug 6, 2024
draft-ietf-pquip-pqc-engineers.md
Outdated
| @@ -657,7 +691,7 @@ One last consideration is the pairs of algorithms that can be combined. A recen | |||
|
|
|||
| The same considerations apply when using multiple certificates to transport a pair of related keys for the same subject. Exactly how two certificates should be managed in order to avoid some of the pitfalls mentioned above is still an active area of investigation. Using two certificates keeps the certificate tooling simple and straightforward, but in the end simply moves the problems with requiring that both certs are intended to be used as a pair, must produce two signatures which must be carried separately, and both must validate, to the certificate management layer, where addressing these concerns in a robust way can be difficult. | |||
|
|
|||
| An important security note when using particularly hybrid signature keys, but also to a lesser extent hybrid KEM keys, is key re-use. In traditional cryptography, problems can occur with so-called "cross-protocol attacks" when the same key can be used for multiple protocols; for example signing TLS handshakes and signing S/MIME emails, however re-using the same key within the same protocol is generally ok -- for example when your certificate expires, renewing it with the same public key. However, key re-use becomes a large security problem within hybrids. Consider an \{RSA, ML-DSA\} hybrid key where the RSA key also appears within a single-algorithm certificate. In this case, an attacker could perform a "stripping attack" where they take some peice of data signed with the \{RSA, ML-DSA\} key, remove the ML-DSA signature and present the data as if it was intended for the RSA only certificate. This leads to a set of security definitions called "non-separability properties", which refers to how well the signature scheme resists various complexities of downgrade / stripping attacks {{?I-D.draft-hale-pquip-hybrid-signature-spectrums}} | |||
| An important security note when using particularly hybrid signature keys, but also to a lesser extent hybrid KEM keys, is key re-use. In traditional cryptography, problems can occur with so-called "cross-protocol attacks" when the same key can be used for multiple protocols; for example signing TLS handshakes and signing S/MIME emails. While it is not best-practice to re-use keys within the same protocol, for example using the same key for multiple S/MIME certificates for the same user, it is not generally catestrophic for security. However, key re-use becomes a large security problem within hybrids. Consider an \{RSA, ML-DSA\} hybrid key where the RSA key also appears within a single-algorithm certificate. In this case, an attacker could perform a "stripping attack" where they take some peice of data signed with the \{RSA, ML-DSA\} key, remove the ML-DSA signature and present the data as if it was intended for the RSA only certificate. This leads to a set of security definitions called "non-separability properties", which refers to how well the signature scheme resists various complexities of downgrade / stripping attacks {{?I-D.draft-hale-pquip-hybrid-signature-spectrums}} | |||
There was a problem hiding this comment.
It is not clear to me how the "stripping attack" is related to key use, please clarify. Replace draft-hale-pquip-hybrid-signature-spectrums with draft-ietf-pquip-hybrid-signature-spectrums
There was a problem hiding this comment.
Tiru, I don't really understand your comment, but I have added another sentence to clarify.
There was a problem hiding this comment.
Thanks, the new line is helpful but I don't think it is allowed to use normative language in an Informational draft. Please replace "SHOULD" with "must" and "SHOULD NOT" with "must not".
There was a problem hiding this comment.
Now that you have merged this, I can no longer edit it. You'll have to make that change yourself on the main branch.
tireddy2
reviewed
Aug 6, 2024
OR13
approved these changes
Aug 23, 2024
draft-ietf-pquip-pqc-engineers.md
Outdated
|
|
||
| It is crucial for the reader to understand that when the word "PQC" is mentioned in the document, it means Asymmetric Cryptography (or Public key Cryptography) and not any algorithms from the Symmetric side based on stream, block ciphers, hash functions, MACs, etc. This document does not cover such topics as when traditional algorithms might become vulnerable (for that, see documents such as [QC-DNS] and others). It also does not cover unrelated technologies like Quantum Key Distribution or Quantum Key Generation, which use quantum hardware to exploit quantum effects to protect communications and generate keys, respectively. Post-quantum cryptography is based on conventional (i.e., non-quantum) math and software and can be run on any general purpose computer. | ||
| It is crucial for the reader to understand that when the word "PQC" is mentioned in the document, it means Asymmetric Cryptography (or Public key Cryptography) and not any algorithms from the Symmetric side based on stream, block ciphers, hash functions, MACs, etc, which are already considered to be quantum secure. This document does not cover such topics as when traditional algorithms might become vulnerable (for that, see documents such as [QC-DNS] and others). It also does not cover unrelated technologies like Quantum Key Distribution or Quantum Key Generation, which use quantum hardware to exploit quantum effects to protect communications and generate keys, respectively. Post-quantum cryptography is based on conventional (i.e., non-quantum) math and software and can be run on any general purpose computer. |
There was a problem hiding this comment.
Suggested change
| It is crucial for the reader to understand that when the word "PQC" is mentioned in the document, it means Asymmetric Cryptography (or Public key Cryptography) and not any algorithms from the Symmetric side based on stream, block ciphers, hash functions, MACs, etc, which are already considered to be quantum secure. This document does not cover such topics as when traditional algorithms might become vulnerable (for that, see documents such as [QC-DNS] and others). It also does not cover unrelated technologies like Quantum Key Distribution or Quantum Key Generation, which use quantum hardware to exploit quantum effects to protect communications and generate keys, respectively. Post-quantum cryptography is based on conventional (i.e., non-quantum) math and software and can be run on any general purpose computer. | |
| It is crucial for the reader to understand that when the word "PQC" is mentioned in the document, it means Asymmetric Cryptography (or Public key Cryptography) and not any algorithms from the Symmetric side based on stream, block ciphers, hash functions, MACs, etc, which are currently believed to be quantum resistant. This document does not cover such topics as when traditional algorithms might become vulnerable (for that, see documents such as [QC-DNS] and others). It also does not cover unrelated technologies like Quantum Key Distribution or Quantum Key Generation, which use quantum hardware to exploit quantum effects to protect communications and generate keys, respectively. Post-quantum cryptography is based on conventional (i.e., non-quantum) math and software and can be run on any general purpose computer. |
draft-ietf-pquip-pqc-engineers.md
Outdated
| @@ -279,22 +303,27 @@ Finally, in their evaluation criteria for PQC, NIST is assessing the security le | |||
|
|
|||
| For example, to provide some context, one would need 20 million noisy qubits to break RSA-2048 in 8 hours {{RSAShor}}{{RSA8HRS}} or 4099 stable (or logical) qubits to break it in 10 seconds {{RSA10SC}}. | |||
|
|
|||
| For structured data such as public-key and signatures, instead, CRQCs can fully solve the underlying hard problems used in classic cryptography (see Shor's Algorithm). Because an increase of the size of the key-pair would not provide a secure solution short of RSA keys that are many gigabytes in size {{PQRSA}}, a complete replacement of the algorithm is needed. Therefore, post-quantum public-key cryptography must rely on problems that are different from the ones used in classic public-key cryptography (i.e., the integer factorization problem, the finite-field discrete logarithm problem, and the elliptic-curve discrete logarithm problem). | |||
| For structured data such as public-keys and signatures, instead, CRQCs can fully solve the underlying hard problems used in classic cryptography (see Shor's Algorithm). Because an increase of the size of the key-pair would not provide a secure solution short of RSA keys that are many gigabytes in size {{PQRSA}}, a complete replacement of the algorithm is needed. Therefore, post-quantum public-key cryptography must rely on problems that are different from the ones used in classic public-key cryptography (i.e., the integer factorization problem, the finite-field discrete logarithm problem, and the elliptic-curve discrete logarithm problem). | |||
There was a problem hiding this comment.
Suggested change
| For structured data such as public-keys and signatures, instead, CRQCs can fully solve the underlying hard problems used in classic cryptography (see Shor's Algorithm). Because an increase of the size of the key-pair would not provide a secure solution short of RSA keys that are many gigabytes in size {{PQRSA}}, a complete replacement of the algorithm is needed. Therefore, post-quantum public-key cryptography must rely on problems that are different from the ones used in classic public-key cryptography (i.e., the integer factorization problem, the finite-field discrete logarithm problem, and the elliptic-curve discrete logarithm problem). | |
| For structured data such as public keys and signatures, instead, CRQCs can fully solve the underlying hard problems used in classic cryptography (see Shor's Algorithm). Because an increase of the size of the key-pair would not provide a secure solution short of RSA keys that are many gigabytes in size {{PQRSA}}, a complete replacement of the algorithm is needed. Therefore, post-quantum public-key cryptography must rely on problems that are different from the ones used in classic public-key cryptography (i.e., the integer factorization problem, the finite-field discrete logarithm problem, and the elliptic-curve discrete logarithm problem). |
| @@ -357,7 +393,7 @@ where pk is public key, sk is secret key, ct is the ciphertext representing an e | |||
| | Client | | Server | | |||
| +---------+ +---------+ | |||
| +----------------------+ | | | |||
| | sk, pk = kemKeyGen() |-| | | |||
| | pk, sk = kemKeyGen() |-| | | |||
There was a problem hiding this comment.
Is there a preferred order or is this just matching convention earlier in the document?
There was a problem hiding this comment.
The output should be (pk, sk) to maintain consistency.
Co-authored-by: Orie Steele <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This corresponds to feedback on-list here:
https://mailarchive.ietf.org/arch/msg/pqc/eymSMhEjJbUHO53j_jvkkWLtuc8/