mirror of
https://git.tartarus.org/simon/putty.git
synced 2025-01-10 09:58:01 +00:00
c1a2114b28
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.
111 lines
4.0 KiB
C
111 lines
4.0 KiB
C
/*
|
|
* Top-level vtables to select an AES implementation.
|
|
*/
|
|
|
|
#include <assert.h>
|
|
#include <stdlib.h>
|
|
|
|
#include "putty.h"
|
|
#include "ssh.h"
|
|
#include "aes.h"
|
|
|
|
static ssh_cipher *aes_select(const ssh_cipheralg *alg)
|
|
{
|
|
const ssh_cipheralg *const *real_algs = (const ssh_cipheralg **)alg->extra;
|
|
|
|
for (size_t i = 0; real_algs[i]; i++) {
|
|
const ssh_cipheralg *alg = real_algs[i];
|
|
const struct aes_extra *alg_extra =
|
|
(const struct aes_extra *)alg->extra;
|
|
if (check_availability(alg_extra))
|
|
return ssh_cipher_new(alg);
|
|
}
|
|
|
|
/* We should never reach the NULL at the end of the list, because
|
|
* the last non-NULL entry should be software-only AES, which is
|
|
* always available. */
|
|
unreachable("aes_select ran off the end of its list");
|
|
}
|
|
|
|
#if HAVE_AES_NI
|
|
#define IF_NI(...) __VA_ARGS__
|
|
#else
|
|
#define IF_NI(...)
|
|
#endif
|
|
|
|
#if HAVE_NEON_CRYPTO
|
|
#define IF_NEON(...) __VA_ARGS__
|
|
#else
|
|
#define IF_NEON(...)
|
|
#endif
|
|
|
|
#define AES_SELECTOR_VTABLE(mode_c, mode_protocol, mode_display, bits, ...) \
|
|
static const ssh_cipheralg * \
|
|
ssh_aes ## bits ## _ ## mode_c ## _impls[] = { \
|
|
IF_NI(&ssh_aes ## bits ## _ ## mode_c ## _ni,) \
|
|
IF_NEON(&ssh_aes ## bits ## _ ## mode_c ## _neon,) \
|
|
&ssh_aes ## bits ## _ ## mode_c ## _sw, \
|
|
NULL, \
|
|
}; \
|
|
const ssh_cipheralg ssh_aes ## bits ## _ ## mode_c = { \
|
|
.new = aes_select, \
|
|
.ssh2_id = "aes" #bits "-" mode_protocol, \
|
|
.blksize = 16, \
|
|
.real_keybits = bits, \
|
|
.padded_keybytes = bits/8, \
|
|
.text_name = "AES-" #bits " " mode_display \
|
|
" (dummy selector vtable)", \
|
|
.extra = ssh_aes ## bits ## _ ## mode_c ## _impls, \
|
|
__VA_ARGS__ \
|
|
}
|
|
|
|
AES_SELECTOR_VTABLE(cbc, "cbc", "CBC", 128);
|
|
AES_SELECTOR_VTABLE(cbc, "cbc", "CBC", 192);
|
|
AES_SELECTOR_VTABLE(cbc, "cbc", "CBC", 256);
|
|
AES_SELECTOR_VTABLE(sdctr, "ctr", "SDCTR", 128);
|
|
AES_SELECTOR_VTABLE(sdctr, "ctr", "SDCTR", 192);
|
|
AES_SELECTOR_VTABLE(sdctr, "ctr", "SDCTR", 256);
|
|
AES_SELECTOR_VTABLE(gcm, "gcm@openssh.com", "GCM", 128,
|
|
.required_mac = &ssh2_aesgcm_mac);
|
|
AES_SELECTOR_VTABLE(gcm, "gcm@openssh.com", "GCM", 256,
|
|
.required_mac = &ssh2_aesgcm_mac);
|
|
|
|
/* 192-bit AES-GCM is included only so that testcrypt can run standard
|
|
* test vectors against it. OpenSSH doesn't define a protocol id for
|
|
* it. Hence the silly macro trick here to set its ssh2_id to 0, and
|
|
* more importantly, leaving it out of aesgcm_list[] below. */
|
|
AES_SELECTOR_VTABLE(gcm, ?NULL:NULL, "GCM", 192,
|
|
.required_mac = &ssh2_aesgcm_mac);
|
|
|
|
static const ssh_cipheralg ssh_rijndael_lysator = {
|
|
/* Same as aes256_cbc, but with a different protocol ID */
|
|
.new = aes_select,
|
|
.ssh2_id = "rijndael-cbc@lysator.liu.se",
|
|
.blksize = 16,
|
|
.real_keybits = 256,
|
|
.padded_keybytes = 256/8,
|
|
.text_name = "AES-256 CBC (dummy selector vtable)",
|
|
.extra = ssh_aes256_cbc_impls,
|
|
};
|
|
|
|
static const ssh_cipheralg *const aes_list[] = {
|
|
&ssh_aes256_sdctr,
|
|
&ssh_aes256_cbc,
|
|
&ssh_rijndael_lysator,
|
|
&ssh_aes192_sdctr,
|
|
&ssh_aes192_cbc,
|
|
&ssh_aes128_sdctr,
|
|
&ssh_aes128_cbc,
|
|
};
|
|
|
|
const ssh2_ciphers ssh2_aes = { lenof(aes_list), aes_list };
|
|
|
|
static const ssh_cipheralg *const aesgcm_list[] = {
|
|
/* OpenSSH only defines protocol ids for 128- and 256-bit AES-GCM,
|
|
* not 192-bit. */
|
|
&ssh_aes128_gcm,
|
|
&ssh_aes256_gcm,
|
|
};
|
|
|
|
const ssh2_ciphers ssh2_aesgcm = { lenof(aesgcm_list), aesgcm_list };
|