mirror of
https://git.tartarus.org/simon/putty.git
synced 2025-01-10 01:48:00 +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.
58 lines
1.6 KiB
C
58 lines
1.6 KiB
C
#cmakedefine NO_IPV6
|
|
#cmakedefine NO_GSSAPI
|
|
#cmakedefine STATIC_GSSAPI
|
|
|
|
#cmakedefine NO_MULTIMON
|
|
|
|
#cmakedefine01 HAVE_WINRESRC_H
|
|
#cmakedefine01 HAVE_WINRES_H
|
|
#cmakedefine01 HAVE_WIN_H
|
|
#cmakedefine01 HAVE_NO_STDINT_H
|
|
#cmakedefine01 HAVE_AFUNIX_H
|
|
#cmakedefine01 HAVE_GCP_RESULTSW
|
|
#cmakedefine01 HAVE_ADDDLLDIRECTORY
|
|
#cmakedefine01 HAVE_GETNAMEDPIPECLIENTPROCESSID
|
|
#cmakedefine01 HAVE_SETDEFAULTDLLDIRECTORIES
|
|
#cmakedefine01 HAVE_STRTOUMAX
|
|
#cmakedefine01 HAVE_DWMAPI_H
|
|
|
|
#cmakedefine NOT_X_WINDOWS
|
|
#cmakedefine OMIT_UTMP
|
|
|
|
#cmakedefine01 HAVE_ASM_HWCAP_H
|
|
#cmakedefine01 HAVE_SYS_AUXV_H
|
|
#cmakedefine01 HAVE_SYS_SYSCTL_H
|
|
#cmakedefine01 HAVE_SYS_TYPES_H
|
|
#cmakedefine01 HAVE_GLOB_H
|
|
#cmakedefine01 HAVE_UTMP_H
|
|
#cmakedefine01 HAVE_FUTIMES
|
|
#cmakedefine01 HAVE_GETADDRINFO
|
|
#cmakedefine01 HAVE_POSIX_OPENPT
|
|
#cmakedefine01 HAVE_PTSNAME
|
|
#cmakedefine01 HAVE_SETRESUID
|
|
#cmakedefine01 HAVE_SETRESGID
|
|
#cmakedefine01 HAVE_STRSIGNAL
|
|
#cmakedefine01 HAVE_UPDWTMPX
|
|
#cmakedefine01 HAVE_FSTATAT
|
|
#cmakedefine01 HAVE_DIRFD
|
|
#cmakedefine01 HAVE_SETPWENT
|
|
#cmakedefine01 HAVE_ENDPWENT
|
|
#cmakedefine01 HAVE_GETAUXVAL
|
|
#cmakedefine01 HAVE_ELF_AUX_INFO
|
|
#cmakedefine01 HAVE_SYSCTLBYNAME
|
|
#cmakedefine01 HAVE_CLOCK_MONOTONIC
|
|
#cmakedefine01 HAVE_CLOCK_GETTIME
|
|
#cmakedefine01 HAVE_SO_PEERCRED
|
|
#cmakedefine01 HAVE_PANGO_FONT_FAMILY_IS_MONOSPACE
|
|
#cmakedefine01 HAVE_PANGO_FONT_MAP_LIST_FAMILIES
|
|
|
|
#cmakedefine01 HAVE_AES_NI
|
|
#cmakedefine01 HAVE_SHA_NI
|
|
#cmakedefine01 HAVE_SHAINTRIN_H
|
|
#cmakedefine01 HAVE_CLMUL
|
|
#cmakedefine01 HAVE_NEON_CRYPTO
|
|
#cmakedefine01 HAVE_NEON_PMULL
|
|
#cmakedefine01 HAVE_NEON_SHA512
|
|
#cmakedefine01 HAVE_NEON_SHA512_INTRINSICS
|
|
#cmakedefine01 USE_ARM64_NEON_H
|