simon-git: putty (main): Simon Tatham
Commits to Tartarus hosted VCS
tartarus-commits at lists.tartarus.org
Wed Apr 21 22:03:45 BST 2021
TL;DR:
5b30e6f7 Move crypto into its own subdirectory.
fca13a17 Break up crypto modules containing HW acceleration.
e06cf1ec Remove the 'compile-once' design principle.
Repository: https://git.tartarus.org/simon/putty.git
On the web: https://git.tartarus.org/?p=simon/putty.git
Branch updated: main
Committer: Simon Tatham <anakin at pobox.com>
Date: 2021-04-21 22:03:45
commit 5b30e6f7a6ff2ec5841b79bdc49671f6c3544f25
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=5b30e6f7a6ff2ec5841b79bdc49671f6c3544f25;hp=2b26ddf261fead6cde9521d287f52a6d56acfe71
Author: Simon Tatham <anakin at pobox.com>
Date: Sun Apr 18 13:16:59 2021 +0100
Move crypto into its own subdirectory.
Similarly to 'utils', I've moved all the stuff in the crypto
build-time library into a source directory of its own, and while I'm
at it, split up the monolithic sshauxcrypt.c into its various
unrelated parts.
This is also an opportunity to remove the annoying 'ssh' prefix from
the front of the file names, and give several of them less cryptic
names.
CMakeLists.txt | 9 +-
crypto/CMakeLists.txt | 30 ++++++
sshaes.c => crypto/aes.c | 2 +-
ssharcf.c => crypto/arcfour.c | 0
sshargon2.c => crypto/argon2.c | 0
sshbcrypt.c => crypto/bcrypt.c | 0
sshblake2.c => crypto/blake2.c | 0
sshblowf.c => crypto/blowfish.c | 0
sshccp.c => crypto/chacha20-poly1305.c | 0
sshcrc.c => crypto/crc32.c | 5 +
sshdes.c => crypto/des.c | 2 +-
sshdh.c => crypto/diffie-hellman.c | 0
sshdss.c => crypto/dsa.c | 2 +-
ecc.c => crypto/ecc-arithmetic.c | 4 +
sshecc.c => crypto/ecc-ssh.c | 10 +-
crypto/hash_simple.c | 13 +++
sshhmac.c => crypto/hmac.c | 0
sshmac.c => crypto/mac.c | 0
crypto/mac_simple.c | 16 ++++
sshmd5.c => crypto/md5.c | 0
mpint.c => crypto/mpint.c | 4 +
sshprng.c => crypto/prng.c | 2 +-
crypto/pubkey-pem.c | 32 +++++++
crypto/pubkey-ppk.c | 29 ++++++
crypto/pubkey-ssh1.c | 38 ++++++++
sshrsa.c => crypto/rsa.c | 0
sshsha.c => crypto/sha1.c | 0
sshsh256.c => crypto/sha256.c | 0
sshsha3.c => crypto/sha3.c | 0
sshsh512.c => crypto/sha512.c | 0
crypto/xdmauth.c | 53 +++++++++++
sshauxcrypt.c | 166 ---------------------------------
32 files changed, 230 insertions(+), 187 deletions(-)
commit fca13a17b160da3b5069df3ceab19d4448c4f389
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=fca13a17b160da3b5069df3ceab19d4448c4f389;hp=5b30e6f7a6ff2ec5841b79bdc49671f6c3544f25
Author: Simon Tatham <anakin at pobox.com>
Date: Mon Apr 19 06:42:12 2021 +0100
Break up crypto modules containing HW acceleration.
This applies to all of AES, SHA-1, SHA-256 and SHA-512. All those
source files previously contained multiple implementations of the
algorithm, enabled or disabled by ifdefs detecting whether they would
work on a given compiler. And in order to get advanced machine
instructions like AES-NI or NEON crypto into the output file when the
compile flags hadn't enabled them, we had to do nasty stuff with
compiler-specific pragmas or attributes.
Now we can do the detection at cmake time, and enable advanced
instructions in the more sensible way, by compile-time flags. So I've
broken up each of these modules into lots of sub-pieces: a file called
(e.g.) 'foo-common.c' containing common definitions across all
implementations (such as round constants), one called 'foo-select.c'
containing the top-level vtable(s), and a separate file for each
implementation exporting just the vtable(s) for that implementation.
One advantage of this is that it depends a lot less on compiler-
specific bodgery. My particular least favourite part of the previous
setup was the part where I had to _manually_ define some Arm ACLE
feature macros before including <arm_neon.h>, so that it would define
the intrinsics I wanted. Now I'm enabling interesting architecture
features in the normal way, on the compiler command line, there's no
need for that kind of trick: the right feature macros are already
defined and <arm_neon.h> does the right thing.
Another change in this reorganisation is that I've stopped assuming
there's just one hardware implementation per platform. Previously, the
accelerated vtables were called things like sha256_hw, and varied
between FOO-NI and NEON depending on platform; and the selection code
would simply ask 'is hw available? if so, use hw, else sw'. Now, each
HW acceleration strategy names its vtable its own way, and the
selection vtable has a whole list of possibilities to iterate over
looking for a supported one. So if someone feels like writing a second
accelerated implementation of something for a given platform - for
example, I've heard you can use plain NEON to speed up AES somewhat
even without the crypto extension - then it will now have somewhere to
drop in alongside the existing ones.
cmake/cmake.h.in | 8 +
crypto/CMakeLists.txt | 183 +++++++-
crypto/aes-common.c | 14 +
crypto/aes-neon.c | 294 ++++++++++++
crypto/aes-ni.c | 281 ++++++++++++
crypto/aes-select.c | 89 ++++
crypto/{aes.c => aes-sw.c} | 906 +------------------------------------
crypto/aes.h | 109 +++++
crypto/sha1-common.c | 10 +
crypto/sha1-neon.c | 190 ++++++++
crypto/sha1-ni.c | 325 ++++++++++++++
crypto/sha1-select.c | 44 ++
crypto/sha1-sw.c | 155 +++++++
crypto/sha1.c | 933 --------------------------------------
crypto/sha1.h | 109 +++++
crypto/sha256-common.c | 30 ++
crypto/sha256-neon.c | 162 +++++++
crypto/sha256-ni.c | 342 ++++++++++++++
crypto/sha256-select.c | 44 ++
crypto/sha256-sw.c | 157 +++++++
crypto/sha256.c | 939 ---------------------------------------
crypto/sha256.h | 105 +++++
crypto/sha512-common.c | 71 +++
crypto/sha512-neon.c | 329 ++++++++++++++
crypto/sha512-select.c | 61 +++
crypto/sha512-sw.c | 168 +++++++
crypto/sha512.c | 836 ----------------------------------
crypto/sha512.h | 131 ++++++
ssh.h | 36 +-
test/cryptsuite.py | 95 ++--
testcrypt.c | 84 +++-
testcrypt.h | 1 +
testsc.c | 66 ++-
unix/utils/arm_arch_queries.c | 8 +-
windows/utils/arm_arch_queries.c | 8 +-
35 files changed, 3621 insertions(+), 3702 deletions(-)
commit e06cf1ec40c30cded8d277e43fd4f1f3079a0e5f
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=e06cf1ec40c30cded8d277e43fd4f1f3079a0e5f;hp=fca13a17b160da3b5069df3ceab19d4448c4f389
Author: Simon Tatham <anakin at pobox.com>
Date: Wed Apr 21 21:25:32 2021 +0100
Remove the 'compile-once' design principle.
It's no longer a hard requirement, because now we're on cmake rather
than mkfiles.pl, we _can_ compile the same source file multiple times
with different ifdefs.
I still think it's a better idea not to: I'd prefer that most of this
code base remained in the form of libraries reused between
applications, with parametrisation done by choice of what other
objects to link them to rather than by recompiling the library modules
themselves with different settings. But the latter is now a
possibility at need.
doc/udp.but | 40 ----------------------------------------
1 file changed, 40 deletions(-)
More information about the tartarus-commits
mailing list