nhyatt/putty-source
1
0
Fork 0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-01-09 17:38:00 +00:00
Code Issues Projects Releases Wiki Activity
f58ddf26fe
putty-source/test/testcrypt-enum.h

186 lines
7.3 KiB
C
Raw Normal View History

testcrypt: move enumerated types out into another header. Now all the lookup functions like get_hashalg() and get_primegenpolicy() are autogenerated by macro expansion from a header a little like the existing testcrypt.h. But the macros are much simpler this time. This doesn't really change anything, _except_ that now I'll be able to reinclude the same header to do other things with the list of enumerated types.
2021-11-22 18:38:36 +00:00
BEGIN_ENUM_TYPE(hashalg)
ENUM_VALUE("md5", &ssh_md5)
ENUM_VALUE("sha1", &ssh_sha1)
ENUM_VALUE("sha1_sw", &ssh_sha1_sw)
ENUM_VALUE("sha256", &ssh_sha256)
ENUM_VALUE("sha384", &ssh_sha384)
ENUM_VALUE("sha512", &ssh_sha512)
ENUM_VALUE("sha256_sw", &ssh_sha256_sw)
ENUM_VALUE("sha384_sw", &ssh_sha384_sw)
ENUM_VALUE("sha512_sw", &ssh_sha512_sw)
#if HAVE_SHA_NI
ENUM_VALUE("sha1_ni", &ssh_sha1_ni)
ENUM_VALUE("sha256_ni", &ssh_sha256_ni)
#endif
#if HAVE_NEON_CRYPTO
ENUM_VALUE("sha1_neon", &ssh_sha1_neon)
ENUM_VALUE("sha256_neon", &ssh_sha256_neon)
#endif
#if HAVE_NEON_SHA512
ENUM_VALUE("sha384_neon", &ssh_sha384_neon)
ENUM_VALUE("sha512_neon", &ssh_sha512_neon)
#endif
ENUM_VALUE("sha3_224", &ssh_sha3_224)
ENUM_VALUE("sha3_256", &ssh_sha3_256)
ENUM_VALUE("sha3_384", &ssh_sha3_384)
ENUM_VALUE("sha3_512", &ssh_sha3_512)
ENUM_VALUE("shake256_114bytes", &ssh_shake256_114bytes)
ENUM_VALUE("blake2b", &ssh_blake2b)
END_ENUM_TYPE(hashalg)
BEGIN_ENUM_TYPE(macalg)
ENUM_VALUE("hmac_md5", &ssh_hmac_md5)
ENUM_VALUE("hmac_sha1", &ssh_hmac_sha1)
ENUM_VALUE("hmac_sha1_buggy", &ssh_hmac_sha1_buggy)
ENUM_VALUE("hmac_sha1_96", &ssh_hmac_sha1_96)
ENUM_VALUE("hmac_sha1_96_buggy", &ssh_hmac_sha1_96_buggy)
ENUM_VALUE("hmac_sha256", &ssh_hmac_sha256)
Add support for HMAC-SHA512. I saw a post on comp.security.ssh just now where someone had encountered an SSH server that would _only_ speak that, which makes it worth bothering to implement. The totally obvious implementation works, and passes the test cases from RFC 6234.
2023-04-21 19:17:43 +00:00
ENUM_VALUE("hmac_sha512", &ssh_hmac_sha512)
testcrypt: move enumerated types out into another header. Now all the lookup functions like get_hashalg() and get_primegenpolicy() are autogenerated by macro expansion from a header a little like the existing testcrypt.h. But the macros are much simpler this time. This doesn't really change anything, _except_ that now I'll be able to reinclude the same header to do other things with the list of enumerated types.
2021-11-22 18:38:36 +00:00
ENUM_VALUE("poly1305", &ssh2_poly1305)
Implement AES-GCM using the @openssh.com protocol IDs. I only recently found out that OpenSSH defined their own protocol IDs for AES-GCM, defined to work the same as the standard ones except that they fixed the semantics for how you select the linked cipher+MAC pair during key exchange. (RFC 5647 defines protocol ids for AES-GCM in both the cipher and MAC namespaces, and requires that you MUST select both or neither - but this contradicts the selection policy set out in the base SSH RFCs, and there's no discussion of how you resolve a conflict between them! OpenSSH's answer is to do it the same way ChaCha20-Poly1305 works, because that will ensure the two suites don't fight.) People do occasionally ask us for this linked cipher/MAC pair, and now I know it's actually feasible, I've implemented it, including a pair of vector implementations for x86 and Arm using their respective architecture extensions for multiplying polynomials over GF(2). Unlike ChaCha20-Poly1305, I've kept the cipher and MAC implementations in separate objects, with an arm's-length link between them that the MAC uses when it needs to encrypt single cipher blocks to use as the inputs to the MAC algorithm. That enables the cipher and the MAC to be independently selected from their hardware-accelerated versions, just in case someone runs on a system that has polynomial multiplication instructions but not AES acceleration, or vice versa. There's a fourth implementation of the GCM MAC, which is a pure software implementation of the same algorithm used in the vectorised versions. It's too slow to use live, but I've kept it in the code for future testing needs, and because it's a convenient place to dump my design comments. The vectorised implementations are fairly crude as far as optimisation goes. I'm sure serious x86 _or_ Arm optimisation engineers would look at them and laugh. But GCM is a fast MAC compared to HMAC-SHA-256 (indeed compared to HMAC-anything-at-all), so it should at least be good enough to use. And we've got a working version with some tests now, so if someone else wants to improve them, they can.
2022-08-16 17:36:58 +00:00
ENUM_VALUE("aesgcm", &ssh2_aesgcm_mac)
ENUM_VALUE("aesgcm", &ssh2_aesgcm_mac)
ENUM_VALUE("aesgcm_sw", &ssh2_aesgcm_mac_sw)
ENUM_VALUE("aesgcm_ref_poly", &ssh2_aesgcm_mac_ref_poly)
#if HAVE_CLMUL
ENUM_VALUE("aesgcm_clmul", &ssh2_aesgcm_mac_clmul)
#endif
#if HAVE_NEON_PMULL
ENUM_VALUE("aesgcm_neon", &ssh2_aesgcm_mac_neon)
#endif
testcrypt: move enumerated types out into another header. Now all the lookup functions like get_hashalg() and get_primegenpolicy() are autogenerated by macro expansion from a header a little like the existing testcrypt.h. But the macros are much simpler this time. This doesn't really change anything, _except_ that now I'll be able to reinclude the same header to do other things with the list of enumerated types.
2021-11-22 18:38:36 +00:00
END_ENUM_TYPE(macalg)
BEGIN_ENUM_TYPE(keyalg)
ENUM_VALUE("dsa", &ssh_dsa)
ENUM_VALUE("rsa", &ssh_rsa)
ENUM_VALUE("ed25519", &ssh_ecdsa_ed25519)
ENUM_VALUE("ed448", &ssh_ecdsa_ed448)
ENUM_VALUE("p256", &ssh_ecdsa_nistp256)
ENUM_VALUE("p384", &ssh_ecdsa_nistp384)
ENUM_VALUE("p521", &ssh_ecdsa_nistp521)
Family of key types for OpenSSH certificates. This commit is groundwork for full certificate support, but doesn't complete the job by itself. It introduces the new key types, and adds a test in cryptsuite ensuring they work as expected, but nothing else. If you manually construct a PPK file for one of the new key types, so that it has a certificate in the public key field, then this commit enables PuTTY to present that key to a server for user authentication, either directly or via Pageant storing and using it. But I haven't yet provided any mechanism for making such a PPK, so by itself, this isn't much use. Also, these new key types are not yet included in the KEXINIT host keys list, because if they were, they'd just be treated as normal host keys, in that you'd be asked to manually confirm the SSH fingerprint of the certificate. I'll enable them for host keys once I add the missing pieces.
2022-04-19 13:48:31 +00:00
ENUM_VALUE("dsa-cert", &opensshcert_ssh_dsa)
ENUM_VALUE("rsa-cert", &opensshcert_ssh_rsa)
ENUM_VALUE("ed25519-cert", &opensshcert_ssh_ecdsa_ed25519)
ENUM_VALUE("p256-cert", &opensshcert_ssh_ecdsa_nistp256)
ENUM_VALUE("p384-cert", &opensshcert_ssh_ecdsa_nistp384)
ENUM_VALUE("p521-cert", &opensshcert_ssh_ecdsa_nistp521)
testcrypt: move enumerated types out into another header. Now all the lookup functions like get_hashalg() and get_primegenpolicy() are autogenerated by macro expansion from a header a little like the existing testcrypt.h. But the macros are much simpler this time. This doesn't really change anything, _except_ that now I'll be able to reinclude the same header to do other things with the list of enumerated types.
2021-11-22 18:38:36 +00:00
END_ENUM_TYPE(keyalg)
BEGIN_ENUM_TYPE(cipheralg)
ENUM_VALUE("3des_ctr", &ssh_3des_ssh2_ctr)
ENUM_VALUE("3des_ssh2", &ssh_3des_ssh2)
ENUM_VALUE("3des_ssh1", &ssh_3des_ssh1)
ENUM_VALUE("des_cbc", &ssh_des)
ENUM_VALUE("aes256_ctr", &ssh_aes256_sdctr)
Implement AES-GCM using the @openssh.com protocol IDs. I only recently found out that OpenSSH defined their own protocol IDs for AES-GCM, defined to work the same as the standard ones except that they fixed the semantics for how you select the linked cipher+MAC pair during key exchange. (RFC 5647 defines protocol ids for AES-GCM in both the cipher and MAC namespaces, and requires that you MUST select both or neither - but this contradicts the selection policy set out in the base SSH RFCs, and there's no discussion of how you resolve a conflict between them! OpenSSH's answer is to do it the same way ChaCha20-Poly1305 works, because that will ensure the two suites don't fight.) People do occasionally ask us for this linked cipher/MAC pair, and now I know it's actually feasible, I've implemented it, including a pair of vector implementations for x86 and Arm using their respective architecture extensions for multiplying polynomials over GF(2). Unlike ChaCha20-Poly1305, I've kept the cipher and MAC implementations in separate objects, with an arm's-length link between them that the MAC uses when it needs to encrypt single cipher blocks to use as the inputs to the MAC algorithm. That enables the cipher and the MAC to be independently selected from their hardware-accelerated versions, just in case someone runs on a system that has polynomial multiplication instructions but not AES acceleration, or vice versa. There's a fourth implementation of the GCM MAC, which is a pure software implementation of the same algorithm used in the vectorised versions. It's too slow to use live, but I've kept it in the code for future testing needs, and because it's a convenient place to dump my design comments. The vectorised implementations are fairly crude as far as optimisation goes. I'm sure serious x86 _or_ Arm optimisation engineers would look at them and laugh. But GCM is a fast MAC compared to HMAC-SHA-256 (indeed compared to HMAC-anything-at-all), so it should at least be good enough to use. And we've got a working version with some tests now, so if someone else wants to improve them, they can.
2022-08-16 17:36:58 +00:00
ENUM_VALUE("aes256_gcm", &ssh_aes256_gcm)
testcrypt: move enumerated types out into another header. Now all the lookup functions like get_hashalg() and get_primegenpolicy() are autogenerated by macro expansion from a header a little like the existing testcrypt.h. But the macros are much simpler this time. This doesn't really change anything, _except_ that now I'll be able to reinclude the same header to do other things with the list of enumerated types.
2021-11-22 18:38:36 +00:00
ENUM_VALUE("aes256_cbc", &ssh_aes256_cbc)
ENUM_VALUE("aes192_ctr", &ssh_aes192_sdctr)
Implement AES-GCM using the @openssh.com protocol IDs. I only recently found out that OpenSSH defined their own protocol IDs for AES-GCM, defined to work the same as the standard ones except that they fixed the semantics for how you select the linked cipher+MAC pair during key exchange. (RFC 5647 defines protocol ids for AES-GCM in both the cipher and MAC namespaces, and requires that you MUST select both or neither - but this contradicts the selection policy set out in the base SSH RFCs, and there's no discussion of how you resolve a conflict between them! OpenSSH's answer is to do it the same way ChaCha20-Poly1305 works, because that will ensure the two suites don't fight.) People do occasionally ask us for this linked cipher/MAC pair, and now I know it's actually feasible, I've implemented it, including a pair of vector implementations for x86 and Arm using their respective architecture extensions for multiplying polynomials over GF(2). Unlike ChaCha20-Poly1305, I've kept the cipher and MAC implementations in separate objects, with an arm's-length link between them that the MAC uses when it needs to encrypt single cipher blocks to use as the inputs to the MAC algorithm. That enables the cipher and the MAC to be independently selected from their hardware-accelerated versions, just in case someone runs on a system that has polynomial multiplication instructions but not AES acceleration, or vice versa. There's a fourth implementation of the GCM MAC, which is a pure software implementation of the same algorithm used in the vectorised versions. It's too slow to use live, but I've kept it in the code for future testing needs, and because it's a convenient place to dump my design comments. The vectorised implementations are fairly crude as far as optimisation goes. I'm sure serious x86 _or_ Arm optimisation engineers would look at them and laugh. But GCM is a fast MAC compared to HMAC-SHA-256 (indeed compared to HMAC-anything-at-all), so it should at least be good enough to use. And we've got a working version with some tests now, so if someone else wants to improve them, they can.
2022-08-16 17:36:58 +00:00
ENUM_VALUE("aes192_gcm", &ssh_aes192_gcm)
testcrypt: move enumerated types out into another header. Now all the lookup functions like get_hashalg() and get_primegenpolicy() are autogenerated by macro expansion from a header a little like the existing testcrypt.h. But the macros are much simpler this time. This doesn't really change anything, _except_ that now I'll be able to reinclude the same header to do other things with the list of enumerated types.
2021-11-22 18:38:36 +00:00
ENUM_VALUE("aes192_cbc", &ssh_aes192_cbc)
ENUM_VALUE("aes128_ctr", &ssh_aes128_sdctr)
Implement AES-GCM using the @openssh.com protocol IDs. I only recently found out that OpenSSH defined their own protocol IDs for AES-GCM, defined to work the same as the standard ones except that they fixed the semantics for how you select the linked cipher+MAC pair during key exchange. (RFC 5647 defines protocol ids for AES-GCM in both the cipher and MAC namespaces, and requires that you MUST select both or neither - but this contradicts the selection policy set out in the base SSH RFCs, and there's no discussion of how you resolve a conflict between them! OpenSSH's answer is to do it the same way ChaCha20-Poly1305 works, because that will ensure the two suites don't fight.) People do occasionally ask us for this linked cipher/MAC pair, and now I know it's actually feasible, I've implemented it, including a pair of vector implementations for x86 and Arm using their respective architecture extensions for multiplying polynomials over GF(2). Unlike ChaCha20-Poly1305, I've kept the cipher and MAC implementations in separate objects, with an arm's-length link between them that the MAC uses when it needs to encrypt single cipher blocks to use as the inputs to the MAC algorithm. That enables the cipher and the MAC to be independently selected from their hardware-accelerated versions, just in case someone runs on a system that has polynomial multiplication instructions but not AES acceleration, or vice versa. There's a fourth implementation of the GCM MAC, which is a pure software implementation of the same algorithm used in the vectorised versions. It's too slow to use live, but I've kept it in the code for future testing needs, and because it's a convenient place to dump my design comments. The vectorised implementations are fairly crude as far as optimisation goes. I'm sure serious x86 _or_ Arm optimisation engineers would look at them and laugh. But GCM is a fast MAC compared to HMAC-SHA-256 (indeed compared to HMAC-anything-at-all), so it should at least be good enough to use. And we've got a working version with some tests now, so if someone else wants to improve them, they can.
2022-08-16 17:36:58 +00:00
ENUM_VALUE("aes128_gcm", &ssh_aes128_gcm)
testcrypt: move enumerated types out into another header. Now all the lookup functions like get_hashalg() and get_primegenpolicy() are autogenerated by macro expansion from a header a little like the existing testcrypt.h. But the macros are much simpler this time. This doesn't really change anything, _except_ that now I'll be able to reinclude the same header to do other things with the list of enumerated types.
2021-11-22 18:38:36 +00:00
ENUM_VALUE("aes128_cbc", &ssh_aes128_cbc)
ENUM_VALUE("aes256_ctr_sw", &ssh_aes256_sdctr_sw)
Implement AES-GCM using the @openssh.com protocol IDs. I only recently found out that OpenSSH defined their own protocol IDs for AES-GCM, defined to work the same as the standard ones except that they fixed the semantics for how you select the linked cipher+MAC pair during key exchange. (RFC 5647 defines protocol ids for AES-GCM in both the cipher and MAC namespaces, and requires that you MUST select both or neither - but this contradicts the selection policy set out in the base SSH RFCs, and there's no discussion of how you resolve a conflict between them! OpenSSH's answer is to do it the same way ChaCha20-Poly1305 works, because that will ensure the two suites don't fight.) People do occasionally ask us for this linked cipher/MAC pair, and now I know it's actually feasible, I've implemented it, including a pair of vector implementations for x86 and Arm using their respective architecture extensions for multiplying polynomials over GF(2). Unlike ChaCha20-Poly1305, I've kept the cipher and MAC implementations in separate objects, with an arm's-length link between them that the MAC uses when it needs to encrypt single cipher blocks to use as the inputs to the MAC algorithm. That enables the cipher and the MAC to be independently selected from their hardware-accelerated versions, just in case someone runs on a system that has polynomial multiplication instructions but not AES acceleration, or vice versa. There's a fourth implementation of the GCM MAC, which is a pure software implementation of the same algorithm used in the vectorised versions. It's too slow to use live, but I've kept it in the code for future testing needs, and because it's a convenient place to dump my design comments. The vectorised implementations are fairly crude as far as optimisation goes. I'm sure serious x86 _or_ Arm optimisation engineers would look at them and laugh. But GCM is a fast MAC compared to HMAC-SHA-256 (indeed compared to HMAC-anything-at-all), so it should at least be good enough to use. And we've got a working version with some tests now, so if someone else wants to improve them, they can.
2022-08-16 17:36:58 +00:00
ENUM_VALUE("aes256_gcm_sw", &ssh_aes256_gcm_sw)
testcrypt: move enumerated types out into another header. Now all the lookup functions like get_hashalg() and get_primegenpolicy() are autogenerated by macro expansion from a header a little like the existing testcrypt.h. But the macros are much simpler this time. This doesn't really change anything, _except_ that now I'll be able to reinclude the same header to do other things with the list of enumerated types.
2021-11-22 18:38:36 +00:00
ENUM_VALUE("aes256_cbc_sw", &ssh_aes256_cbc_sw)
ENUM_VALUE("aes192_ctr_sw", &ssh_aes192_sdctr_sw)
Implement AES-GCM using the @openssh.com protocol IDs. I only recently found out that OpenSSH defined their own protocol IDs for AES-GCM, defined to work the same as the standard ones except that they fixed the semantics for how you select the linked cipher+MAC pair during key exchange. (RFC 5647 defines protocol ids for AES-GCM in both the cipher and MAC namespaces, and requires that you MUST select both or neither - but this contradicts the selection policy set out in the base SSH RFCs, and there's no discussion of how you resolve a conflict between them! OpenSSH's answer is to do it the same way ChaCha20-Poly1305 works, because that will ensure the two suites don't fight.) People do occasionally ask us for this linked cipher/MAC pair, and now I know it's actually feasible, I've implemented it, including a pair of vector implementations for x86 and Arm using their respective architecture extensions for multiplying polynomials over GF(2). Unlike ChaCha20-Poly1305, I've kept the cipher and MAC implementations in separate objects, with an arm's-length link between them that the MAC uses when it needs to encrypt single cipher blocks to use as the inputs to the MAC algorithm. That enables the cipher and the MAC to be independently selected from their hardware-accelerated versions, just in case someone runs on a system that has polynomial multiplication instructions but not AES acceleration, or vice versa. There's a fourth implementation of the GCM MAC, which is a pure software implementation of the same algorithm used in the vectorised versions. It's too slow to use live, but I've kept it in the code for future testing needs, and because it's a convenient place to dump my design comments. The vectorised implementations are fairly crude as far as optimisation goes. I'm sure serious x86 _or_ Arm optimisation engineers would look at them and laugh. But GCM is a fast MAC compared to HMAC-SHA-256 (indeed compared to HMAC-anything-at-all), so it should at least be good enough to use. And we've got a working version with some tests now, so if someone else wants to improve them, they can.
2022-08-16 17:36:58 +00:00
ENUM_VALUE("aes192_gcm_sw", &ssh_aes192_gcm_sw)
testcrypt: move enumerated types out into another header. Now all the lookup functions like get_hashalg() and get_primegenpolicy() are autogenerated by macro expansion from a header a little like the existing testcrypt.h. But the macros are much simpler this time. This doesn't really change anything, _except_ that now I'll be able to reinclude the same header to do other things with the list of enumerated types.
2021-11-22 18:38:36 +00:00
ENUM_VALUE("aes192_cbc_sw", &ssh_aes192_cbc_sw)
ENUM_VALUE("aes128_ctr_sw", &ssh_aes128_sdctr_sw)
Implement AES-GCM using the @openssh.com protocol IDs. I only recently found out that OpenSSH defined their own protocol IDs for AES-GCM, defined to work the same as the standard ones except that they fixed the semantics for how you select the linked cipher+MAC pair during key exchange. (RFC 5647 defines protocol ids for AES-GCM in both the cipher and MAC namespaces, and requires that you MUST select both or neither - but this contradicts the selection policy set out in the base SSH RFCs, and there's no discussion of how you resolve a conflict between them! OpenSSH's answer is to do it the same way ChaCha20-Poly1305 works, because that will ensure the two suites don't fight.) People do occasionally ask us for this linked cipher/MAC pair, and now I know it's actually feasible, I've implemented it, including a pair of vector implementations for x86 and Arm using their respective architecture extensions for multiplying polynomials over GF(2). Unlike ChaCha20-Poly1305, I've kept the cipher and MAC implementations in separate objects, with an arm's-length link between them that the MAC uses when it needs to encrypt single cipher blocks to use as the inputs to the MAC algorithm. That enables the cipher and the MAC to be independently selected from their hardware-accelerated versions, just in case someone runs on a system that has polynomial multiplication instructions but not AES acceleration, or vice versa. There's a fourth implementation of the GCM MAC, which is a pure software implementation of the same algorithm used in the vectorised versions. It's too slow to use live, but I've kept it in the code for future testing needs, and because it's a convenient place to dump my design comments. The vectorised implementations are fairly crude as far as optimisation goes. I'm sure serious x86 _or_ Arm optimisation engineers would look at them and laugh. But GCM is a fast MAC compared to HMAC-SHA-256 (indeed compared to HMAC-anything-at-all), so it should at least be good enough to use. And we've got a working version with some tests now, so if someone else wants to improve them, they can.
2022-08-16 17:36:58 +00:00
ENUM_VALUE("aes128_gcm_sw", &ssh_aes128_gcm_sw)
testcrypt: move enumerated types out into another header. Now all the lookup functions like get_hashalg() and get_primegenpolicy() are autogenerated by macro expansion from a header a little like the existing testcrypt.h. But the macros are much simpler this time. This doesn't really change anything, _except_ that now I'll be able to reinclude the same header to do other things with the list of enumerated types.
2021-11-22 18:38:36 +00:00
ENUM_VALUE("aes128_cbc_sw", &ssh_aes128_cbc_sw)
#if HAVE_AES_NI
ENUM_VALUE("aes256_ctr_ni", &ssh_aes256_sdctr_ni)
Implement AES-GCM using the @openssh.com protocol IDs. I only recently found out that OpenSSH defined their own protocol IDs for AES-GCM, defined to work the same as the standard ones except that they fixed the semantics for how you select the linked cipher+MAC pair during key exchange. (RFC 5647 defines protocol ids for AES-GCM in both the cipher and MAC namespaces, and requires that you MUST select both or neither - but this contradicts the selection policy set out in the base SSH RFCs, and there's no discussion of how you resolve a conflict between them! OpenSSH's answer is to do it the same way ChaCha20-Poly1305 works, because that will ensure the two suites don't fight.) People do occasionally ask us for this linked cipher/MAC pair, and now I know it's actually feasible, I've implemented it, including a pair of vector implementations for x86 and Arm using their respective architecture extensions for multiplying polynomials over GF(2). Unlike ChaCha20-Poly1305, I've kept the cipher and MAC implementations in separate objects, with an arm's-length link between them that the MAC uses when it needs to encrypt single cipher blocks to use as the inputs to the MAC algorithm. That enables the cipher and the MAC to be independently selected from their hardware-accelerated versions, just in case someone runs on a system that has polynomial multiplication instructions but not AES acceleration, or vice versa. There's a fourth implementation of the GCM MAC, which is a pure software implementation of the same algorithm used in the vectorised versions. It's too slow to use live, but I've kept it in the code for future testing needs, and because it's a convenient place to dump my design comments. The vectorised implementations are fairly crude as far as optimisation goes. I'm sure serious x86 _or_ Arm optimisation engineers would look at them and laugh. But GCM is a fast MAC compared to HMAC-SHA-256 (indeed compared to HMAC-anything-at-all), so it should at least be good enough to use. And we've got a working version with some tests now, so if someone else wants to improve them, they can.
2022-08-16 17:36:58 +00:00
ENUM_VALUE("aes256_gcm_ni", &ssh_aes256_gcm_ni)
testcrypt: move enumerated types out into another header. Now all the lookup functions like get_hashalg() and get_primegenpolicy() are autogenerated by macro expansion from a header a little like the existing testcrypt.h. But the macros are much simpler this time. This doesn't really change anything, _except_ that now I'll be able to reinclude the same header to do other things with the list of enumerated types.
2021-11-22 18:38:36 +00:00
ENUM_VALUE("aes256_cbc_ni", &ssh_aes256_cbc_ni)
ENUM_VALUE("aes192_ctr_ni", &ssh_aes192_sdctr_ni)
Implement AES-GCM using the @openssh.com protocol IDs. I only recently found out that OpenSSH defined their own protocol IDs for AES-GCM, defined to work the same as the standard ones except that they fixed the semantics for how you select the linked cipher+MAC pair during key exchange. (RFC 5647 defines protocol ids for AES-GCM in both the cipher and MAC namespaces, and requires that you MUST select both or neither - but this contradicts the selection policy set out in the base SSH RFCs, and there's no discussion of how you resolve a conflict between them! OpenSSH's answer is to do it the same way ChaCha20-Poly1305 works, because that will ensure the two suites don't fight.) People do occasionally ask us for this linked cipher/MAC pair, and now I know it's actually feasible, I've implemented it, including a pair of vector implementations for x86 and Arm using their respective architecture extensions for multiplying polynomials over GF(2). Unlike ChaCha20-Poly1305, I've kept the cipher and MAC implementations in separate objects, with an arm's-length link between them that the MAC uses when it needs to encrypt single cipher blocks to use as the inputs to the MAC algorithm. That enables the cipher and the MAC to be independently selected from their hardware-accelerated versions, just in case someone runs on a system that has polynomial multiplication instructions but not AES acceleration, or vice versa. There's a fourth implementation of the GCM MAC, which is a pure software implementation of the same algorithm used in the vectorised versions. It's too slow to use live, but I've kept it in the code for future testing needs, and because it's a convenient place to dump my design comments. The vectorised implementations are fairly crude as far as optimisation goes. I'm sure serious x86 _or_ Arm optimisation engineers would look at them and laugh. But GCM is a fast MAC compared to HMAC-SHA-256 (indeed compared to HMAC-anything-at-all), so it should at least be good enough to use. And we've got a working version with some tests now, so if someone else wants to improve them, they can.
2022-08-16 17:36:58 +00:00
ENUM_VALUE("aes192_gcm_ni", &ssh_aes192_gcm_ni)
testcrypt: move enumerated types out into another header. Now all the lookup functions like get_hashalg() and get_primegenpolicy() are autogenerated by macro expansion from a header a little like the existing testcrypt.h. But the macros are much simpler this time. This doesn't really change anything, _except_ that now I'll be able to reinclude the same header to do other things with the list of enumerated types.
2021-11-22 18:38:36 +00:00
ENUM_VALUE("aes192_cbc_ni", &ssh_aes192_cbc_ni)
ENUM_VALUE("aes128_ctr_ni", &ssh_aes128_sdctr_ni)
Implement AES-GCM using the @openssh.com protocol IDs. I only recently found out that OpenSSH defined their own protocol IDs for AES-GCM, defined to work the same as the standard ones except that they fixed the semantics for how you select the linked cipher+MAC pair during key exchange. (RFC 5647 defines protocol ids for AES-GCM in both the cipher and MAC namespaces, and requires that you MUST select both or neither - but this contradicts the selection policy set out in the base SSH RFCs, and there's no discussion of how you resolve a conflict between them! OpenSSH's answer is to do it the same way ChaCha20-Poly1305 works, because that will ensure the two suites don't fight.) People do occasionally ask us for this linked cipher/MAC pair, and now I know it's actually feasible, I've implemented it, including a pair of vector implementations for x86 and Arm using their respective architecture extensions for multiplying polynomials over GF(2). Unlike ChaCha20-Poly1305, I've kept the cipher and MAC implementations in separate objects, with an arm's-length link between them that the MAC uses when it needs to encrypt single cipher blocks to use as the inputs to the MAC algorithm. That enables the cipher and the MAC to be independently selected from their hardware-accelerated versions, just in case someone runs on a system that has polynomial multiplication instructions but not AES acceleration, or vice versa. There's a fourth implementation of the GCM MAC, which is a pure software implementation of the same algorithm used in the vectorised versions. It's too slow to use live, but I've kept it in the code for future testing needs, and because it's a convenient place to dump my design comments. The vectorised implementations are fairly crude as far as optimisation goes. I'm sure serious x86 _or_ Arm optimisation engineers would look at them and laugh. But GCM is a fast MAC compared to HMAC-SHA-256 (indeed compared to HMAC-anything-at-all), so it should at least be good enough to use. And we've got a working version with some tests now, so if someone else wants to improve them, they can.
2022-08-16 17:36:58 +00:00
ENUM_VALUE("aes128_gcm_ni", &ssh_aes128_gcm_ni)
testcrypt: move enumerated types out into another header. Now all the lookup functions like get_hashalg() and get_primegenpolicy() are autogenerated by macro expansion from a header a little like the existing testcrypt.h. But the macros are much simpler this time. This doesn't really change anything, _except_ that now I'll be able to reinclude the same header to do other things with the list of enumerated types.
2021-11-22 18:38:36 +00:00
ENUM_VALUE("aes128_cbc_ni", &ssh_aes128_cbc_ni)
#endif
#if HAVE_NEON_CRYPTO
ENUM_VALUE("aes256_ctr_neon", &ssh_aes256_sdctr_neon)
Implement AES-GCM using the @openssh.com protocol IDs. I only recently found out that OpenSSH defined their own protocol IDs for AES-GCM, defined to work the same as the standard ones except that they fixed the semantics for how you select the linked cipher+MAC pair during key exchange. (RFC 5647 defines protocol ids for AES-GCM in both the cipher and MAC namespaces, and requires that you MUST select both or neither - but this contradicts the selection policy set out in the base SSH RFCs, and there's no discussion of how you resolve a conflict between them! OpenSSH's answer is to do it the same way ChaCha20-Poly1305 works, because that will ensure the two suites don't fight.) People do occasionally ask us for this linked cipher/MAC pair, and now I know it's actually feasible, I've implemented it, including a pair of vector implementations for x86 and Arm using their respective architecture extensions for multiplying polynomials over GF(2). Unlike ChaCha20-Poly1305, I've kept the cipher and MAC implementations in separate objects, with an arm's-length link between them that the MAC uses when it needs to encrypt single cipher blocks to use as the inputs to the MAC algorithm. That enables the cipher and the MAC to be independently selected from their hardware-accelerated versions, just in case someone runs on a system that has polynomial multiplication instructions but not AES acceleration, or vice versa. There's a fourth implementation of the GCM MAC, which is a pure software implementation of the same algorithm used in the vectorised versions. It's too slow to use live, but I've kept it in the code for future testing needs, and because it's a convenient place to dump my design comments. The vectorised implementations are fairly crude as far as optimisation goes. I'm sure serious x86 _or_ Arm optimisation engineers would look at them and laugh. But GCM is a fast MAC compared to HMAC-SHA-256 (indeed compared to HMAC-anything-at-all), so it should at least be good enough to use. And we've got a working version with some tests now, so if someone else wants to improve them, they can.
2022-08-16 17:36:58 +00:00
ENUM_VALUE("aes256_gcm_neon", &ssh_aes256_gcm_neon)
testcrypt: move enumerated types out into another header. Now all the lookup functions like get_hashalg() and get_primegenpolicy() are autogenerated by macro expansion from a header a little like the existing testcrypt.h. But the macros are much simpler this time. This doesn't really change anything, _except_ that now I'll be able to reinclude the same header to do other things with the list of enumerated types.
2021-11-22 18:38:36 +00:00
ENUM_VALUE("aes256_cbc_neon", &ssh_aes256_cbc_neon)
ENUM_VALUE("aes192_ctr_neon", &ssh_aes192_sdctr_neon)
Implement AES-GCM using the @openssh.com protocol IDs. I only recently found out that OpenSSH defined their own protocol IDs for AES-GCM, defined to work the same as the standard ones except that they fixed the semantics for how you select the linked cipher+MAC pair during key exchange. (RFC 5647 defines protocol ids for AES-GCM in both the cipher and MAC namespaces, and requires that you MUST select both or neither - but this contradicts the selection policy set out in the base SSH RFCs, and there's no discussion of how you resolve a conflict between them! OpenSSH's answer is to do it the same way ChaCha20-Poly1305 works, because that will ensure the two suites don't fight.) People do occasionally ask us for this linked cipher/MAC pair, and now I know it's actually feasible, I've implemented it, including a pair of vector implementations for x86 and Arm using their respective architecture extensions for multiplying polynomials over GF(2). Unlike ChaCha20-Poly1305, I've kept the cipher and MAC implementations in separate objects, with an arm's-length link between them that the MAC uses when it needs to encrypt single cipher blocks to use as the inputs to the MAC algorithm. That enables the cipher and the MAC to be independently selected from their hardware-accelerated versions, just in case someone runs on a system that has polynomial multiplication instructions but not AES acceleration, or vice versa. There's a fourth implementation of the GCM MAC, which is a pure software implementation of the same algorithm used in the vectorised versions. It's too slow to use live, but I've kept it in the code for future testing needs, and because it's a convenient place to dump my design comments. The vectorised implementations are fairly crude as far as optimisation goes. I'm sure serious x86 _or_ Arm optimisation engineers would look at them and laugh. But GCM is a fast MAC compared to HMAC-SHA-256 (indeed compared to HMAC-anything-at-all), so it should at least be good enough to use. And we've got a working version with some tests now, so if someone else wants to improve them, they can.
2022-08-16 17:36:58 +00:00
ENUM_VALUE("aes192_gcm_neon", &ssh_aes192_gcm_neon)
testcrypt: move enumerated types out into another header. Now all the lookup functions like get_hashalg() and get_primegenpolicy() are autogenerated by macro expansion from a header a little like the existing testcrypt.h. But the macros are much simpler this time. This doesn't really change anything, _except_ that now I'll be able to reinclude the same header to do other things with the list of enumerated types.
2021-11-22 18:38:36 +00:00
ENUM_VALUE("aes192_cbc_neon", &ssh_aes192_cbc_neon)
ENUM_VALUE("aes128_ctr_neon", &ssh_aes128_sdctr_neon)
Implement AES-GCM using the @openssh.com protocol IDs. I only recently found out that OpenSSH defined their own protocol IDs for AES-GCM, defined to work the same as the standard ones except that they fixed the semantics for how you select the linked cipher+MAC pair during key exchange. (RFC 5647 defines protocol ids for AES-GCM in both the cipher and MAC namespaces, and requires that you MUST select both or neither - but this contradicts the selection policy set out in the base SSH RFCs, and there's no discussion of how you resolve a conflict between them! OpenSSH's answer is to do it the same way ChaCha20-Poly1305 works, because that will ensure the two suites don't fight.) People do occasionally ask us for this linked cipher/MAC pair, and now I know it's actually feasible, I've implemented it, including a pair of vector implementations for x86 and Arm using their respective architecture extensions for multiplying polynomials over GF(2). Unlike ChaCha20-Poly1305, I've kept the cipher and MAC implementations in separate objects, with an arm's-length link between them that the MAC uses when it needs to encrypt single cipher blocks to use as the inputs to the MAC algorithm. That enables the cipher and the MAC to be independently selected from their hardware-accelerated versions, just in case someone runs on a system that has polynomial multiplication instructions but not AES acceleration, or vice versa. There's a fourth implementation of the GCM MAC, which is a pure software implementation of the same algorithm used in the vectorised versions. It's too slow to use live, but I've kept it in the code for future testing needs, and because it's a convenient place to dump my design comments. The vectorised implementations are fairly crude as far as optimisation goes. I'm sure serious x86 _or_ Arm optimisation engineers would look at them and laugh. But GCM is a fast MAC compared to HMAC-SHA-256 (indeed compared to HMAC-anything-at-all), so it should at least be good enough to use. And we've got a working version with some tests now, so if someone else wants to improve them, they can.
2022-08-16 17:36:58 +00:00
ENUM_VALUE("aes128_gcm_neon", &ssh_aes128_gcm_neon)
testcrypt: move enumerated types out into another header. Now all the lookup functions like get_hashalg() and get_primegenpolicy() are autogenerated by macro expansion from a header a little like the existing testcrypt.h. But the macros are much simpler this time. This doesn't really change anything, _except_ that now I'll be able to reinclude the same header to do other things with the list of enumerated types.
2021-11-22 18:38:36 +00:00
ENUM_VALUE("aes128_cbc_neon", &ssh_aes128_cbc_neon)
#endif
ENUM_VALUE("blowfish_ctr", &ssh_blowfish_ssh2_ctr)
ENUM_VALUE("blowfish_ssh2", &ssh_blowfish_ssh2)
ENUM_VALUE("blowfish_ssh1", &ssh_blowfish_ssh1)
ENUM_VALUE("arcfour256", &ssh_arcfour256_ssh2)
ENUM_VALUE("arcfour128", &ssh_arcfour128_ssh2)
ENUM_VALUE("chacha20_poly1305", &ssh2_chacha20_poly1305)
END_ENUM_TYPE(cipheralg)
BEGIN_ENUM_TYPE(dh_group)
ENUM_VALUE("group1", &ssh_diffiehellman_group1_sha1)
ENUM_VALUE("group14", &ssh_diffiehellman_group14_sha256)
Add RFC8268 / RFC3126 Diffie-Hellman group{15,16,17,18}. These are a new set of larger integer Diffie-Hellman fixed groups, using SHA-512 as the hash.
2022-08-29 06:44:39 +00:00
ENUM_VALUE("group15", &ssh_diffiehellman_group15_sha512)
ENUM_VALUE("group16", &ssh_diffiehellman_group16_sha512)
ENUM_VALUE("group17", &ssh_diffiehellman_group17_sha512)
ENUM_VALUE("group18", &ssh_diffiehellman_group18_sha512)
testcrypt: move enumerated types out into another header. Now all the lookup functions like get_hashalg() and get_primegenpolicy() are autogenerated by macro expansion from a header a little like the existing testcrypt.h. But the macros are much simpler this time. This doesn't really change anything, _except_ that now I'll be able to reinclude the same header to do other things with the list of enumerated types.
2021-11-22 18:38:36 +00:00
END_ENUM_TYPE(dh_group)
BEGIN_ENUM_TYPE(ecdh_alg)
ENUM_VALUE("curve25519", &ssh_ec_kex_curve25519)
ENUM_VALUE("curve448", &ssh_ec_kex_curve448)
ENUM_VALUE("nistp256", &ssh_ec_kex_nistp256)
ENUM_VALUE("nistp384", &ssh_ec_kex_nistp384)
ENUM_VALUE("nistp521", &ssh_ec_kex_nistp521)
END_ENUM_TYPE(ecdh_alg)
BEGIN_ENUM_TYPE(rsaorder)
ENUM_VALUE("exponent_first", RSA_SSH1_EXPONENT_FIRST)
ENUM_VALUE("modulus_first", RSA_SSH1_MODULUS_FIRST)
END_ENUM_TYPE(rsaorder)
BEGIN_ENUM_TYPE(primegenpolicy)
ENUM_VALUE("probabilistic", &primegen_probabilistic)
ENUM_VALUE("provable_fast", &primegen_provable_fast)
ENUM_VALUE("provable_maurer_simple", &primegen_provable_maurer_simple)
ENUM_VALUE("provable_maurer_complex", &primegen_provable_maurer_complex)
END_ENUM_TYPE(primegenpolicy)
BEGIN_ENUM_TYPE(argon2flavour)
ENUM_VALUE("d", Argon2d)
ENUM_VALUE("i", Argon2i)
ENUM_VALUE("id", Argon2id)
/* I expect to forget which spelling I chose, so let's support many */
ENUM_VALUE("argon2d", Argon2d)
ENUM_VALUE("argon2i", Argon2i)
ENUM_VALUE("argon2id", Argon2id)
ENUM_VALUE("Argon2d", Argon2d)
ENUM_VALUE("Argon2i", Argon2i)
ENUM_VALUE("Argon2id", Argon2id)
END_ENUM_TYPE(argon2flavour)
New post-quantum kex: ML-KEM, and three hybrids of it. As standardised by NIST in FIPS 203, this is a lattice-based post-quantum KEM. Very vaguely, the idea of it is that your public key is a matrix A and vector t, and the private key is the knowledge of how to decompose t into two vectors with all their coefficients small, one transformed by A relative to the other. Encryption of a binary secret starts by turning each bit into one of two maximally separated residues mod a prime q, and then adding 'noise' based on the public key in the form of small increments and decrements mod q, again with some of the noise transformed by A relative to the rest. Decryption uses the knowledge of t's decomposition to align the two sets of noise so that the _large_ changes (which masked the secret from an eavesdropper) cancel out, leaving only a collection of small changes to the original secret vector. Then the vector of input bits can be recovered by assuming that those accumulated small pieces of noise haven't concentrated in any particular residue enough to push it more than half way to the other of its possible starting values. A weird feature of it is that decryption is not a true mathematical inverse of encryption. The assumption that the noise doesn't get large enough to flip any bit of the secret is only probabilistically valid, not a hard guarantee. In other words, key agreement can fail, simply by getting particularly unlucky with the distribution of your random noise! However, the probability of a failure is very low - less than 2^-138 even for ML-KEM-512, and gets even smaller with the larger variants. An awkward feature for our purposes is that the matrix A, containing a large number of residues mod the prime q=3329, is required to be constructed by a process of rejection sampling, i.e. generating random 12-bit values and throwing away the out-of-range ones. That would be a real pain for our side-channel testing system, which generally handles rejection sampling badly (since it necessarily involves data-dependent control flow and timing variation). Fortunately, the matrix and the random seed it was made from are both public: the matrix seed is transmitted as part of the public key, so it's not necessary to try to hide it. Accordingly, I was able to get the implementation to pass testsc by means of not varying the matrix seed between runs, which is justified by the principle of testsc that you vary the _secrets_ to ensure timing is independent of them - and the matrix seed isn't a secret, so you're allowed to keep it the same. The three hybrid algorithms, defined by the current Internet-Draft draft-kampanakis-curdle-ssh-pq-ke, include one hybrid of ML-KEM-768 with Curve25519 in exactly the same way we were already hybridising NTRU Prime with Curve25519, and two more hybrids of ML-KEM with ECDH over a NIST curve. The former hybrid interoperates with the implementation in OpenSSH 9.9; all three interoperate with the fork 'openssh-oqs' at github.com/open-quantum-safe/openssh, and also with the Python library AsyncSSH.
2024-12-07 19:33:39 +00:00
BEGIN_ENUM_TYPE(mlkem_params)
ENUM_VALUE("mlkem512", &mlkem_params_512)
ENUM_VALUE("mlkem768", &mlkem_params_768)
ENUM_VALUE("mlkem1024", &mlkem_params_1024)
END_ENUM_TYPE(mlkem_params)
testcrypt: move enumerated types out into another header. Now all the lookup functions like get_hashalg() and get_primegenpolicy() are autogenerated by macro expansion from a header a little like the existing testcrypt.h. But the macros are much simpler this time. This doesn't really change anything, _except_ that now I'll be able to reinclude the same header to do other things with the list of enumerated types.
2021-11-22 18:38:36 +00:00
BEGIN_ENUM_TYPE(fptype)
ENUM_VALUE("md5", SSH_FPTYPE_MD5)
ENUM_VALUE("sha256", SSH_FPTYPE_SHA256)
Certificate-aware handling of key fingerprints. OpenSSH, when called on to give the fingerprint of a certified public key, will in many circumstances generate the hash of the public blob of the _underlying_ key, rather than the hash of the full certificate. I think the hash of the certificate is also potentially useful (if nothing else, it provides a way to tell apart multiple certificates on the same key). But I can also see that it's useful to be able to recognise a key as the same one 'really' (since all certificates on the same key share a private key, so they're unavoidably related). So I've dealt with this by introducing an extra pair of fingerprint types, giving the cross product of {MD5, SHA-256} x {base key only, full certificate}. You can manually select which one you want to see in some circumstances (notably PuTTYgen), and in others (such as diagnostics) both fingerprints will be emitted side by side via the new functions ssh2_double_fingerprint[_blob]. The default, following OpenSSH, is to just fingerprint the base key.
2022-08-05 17:08:59 +00:00
ENUM_VALUE("md5-cert", SSH_FPTYPE_MD5_CERT)
ENUM_VALUE("sha256-cert", SSH_FPTYPE_SHA256_CERT)
testcrypt: move enumerated types out into another header. Now all the lookup functions like get_hashalg() and get_primegenpolicy() are autogenerated by macro expansion from a header a little like the existing testcrypt.h. But the macros are much simpler this time. This doesn't really change anything, _except_ that now I'll be able to reinclude the same header to do other things with the list of enumerated types.
2021-11-22 18:38:36 +00:00
END_ENUM_TYPE(fptype)
/*
* cproxy.h already has a list macro mapping protocol-specified
* strings to the list of HTTP Digest hash functions. Rather than
* invent a separate one for testcrypt, reuse the existing names.
*/
BEGIN_ENUM_TYPE(httpdigesthash)
Withdraw support for SHA-512-256 in HTTP Digest. I was dubious about it to begin with, when I found that RFC 7616's example seemed to be treating it as a 256-bit truncation of SHA-512, and not the thing FIPS 180-4 section 6.7 specifies as "SHA-512/256" (which also changes the initial hash state). Having failed to get a clarifying response from the RFC authors, I had the idea this morning of testing other HTTP clients to see what _they_ thought that hash function meant, and then at least I could go with an existing in-practice consensus. There is no in-practice consensus. Firefox doesn't support that algorithm at all (but they do support SHA-256); wget doesn't support anything that RFC 7616 added to the original RFC 2617. But the prize for weirdness goes to curl, which does accept the name "SHA-512-256" and ... treats it as an alias for SHA-256! So I think the situation among real clients is too confusing to even try to work with, and I'm going to stop adding to it. PuTTY will follow Firefox's policy: if a proxy server asks for SHA-256 digests we'll happily provide them, but if they ask for SHA-512-256 we'll refuse on the grounds that it's not clear enough what it means.
2021-11-27 11:41:00 +00:00
#define DECL_ARRAY(id, str, alg, bits, accepted) ENUM_VALUE(str, id)
testcrypt: move enumerated types out into another header. Now all the lookup functions like get_hashalg() and get_primegenpolicy() are autogenerated by macro expansion from a header a little like the existing testcrypt.h. But the macros are much simpler this time. This doesn't really change anything, _except_ that now I'll be able to reinclude the same header to do other things with the list of enumerated types.
2021-11-22 18:38:36 +00:00
HTTP_DIGEST_HASHES(DECL_ARRAY)
#undef DECL_ARRAY
END_ENUM_TYPE(httpdigesthash)
Reference in New Issue Copy Permalink