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
b26077b1ae
putty-source/test/testcrypt-enum.h

180 lines
7.1 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)
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