This adds the OpenSSH HMACs that do encrypt then mac. This is a more
secure mode than the original HMAC. Newer AEAD ciphers like chacha20 and
AES-GCM are already encrypt-then-mac, but this also adds it for older
legacy clients that don't support those ciphers yet.
Signed-off-by: Dirkjan Bussink <d.bussink@gmail.com>
Reviewed-by: Jon Simons <jon@jonsimons.org>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
This adds a flag to the type structures to track if we use a
Encrypt-then-MAC cipher instead of Encrypt-and-MAC. EtM is a more secure
hashing mechanism.
Signed-off-by: Dirkjan Bussink <d.bussink@gmail.com>
Reviewed-by: Jon Simons <jon@jonsimons.org>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
This is not supported by OpenSSH and not recommended to be implemented
either.
Signed-off-by: Dirkjan Bussink <d.bussink@gmail.com>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
The commit also propares the internals throughout the code base
for the inclusion of a new AEAD cipher, because previously, the
source code counted only with chacha20-poly1305 cipher, which
is very specific in many cases.
The SSH_HMAC_AEAD_GCM mac algorithm is not actually used, but the name
needed to be defined so we can match in the algorithms selection per
OpenSSH specification (MACs are ignored in case GCM is select as a cipher [1]).
If the provided OpenSSL does not provide EVP_aes_128_gcm() function,
the AES-GCM ciphers will not be compiled in.
[1] https://cvsweb.openbsd.org/src/usr.bin/ssh/PROTOCOL.chacha20poly1305?annotate=HEAD
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
This involves mostly creation of host keys proofs but needs
to follow the same procedure as the client authentication
signatures.
At the same time, the SHA2 extension is enabled in the pkd
so we are able to atomicaly provide correct signatures and
pass tests.
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
With this change there is less code specific to the
chacha20-poly1305 cipher found in src/wrapper.c.
Signed-off-by: Jon Simons <jon@jonsimons.org>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
With this change, a HAVE_LIBCRYPTO #ifdef is removed from wrapper.c.
Now, the libcrypto-specific logic for EVP_CIPHER_CTX_free is moved
into the ssh_cipher_struct cleanup callback handler for those
ciphers.
Signed-off-by: Jon Simons <jon@jonsimons.org>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
Fix a gcrypt build error introduced with
48e7b098f8.
The ssh_cipher_struct only contains a `ctx` field on
the libcrypto builds, so it can't be referenced unless
within HAVE_LIBCRYPTO.
This build fix preserves the original spirit of the
change in 48e7b098f8:
only call `EVP_CIPHER_CTX_free` when `cipher->ctx`
is non-NULL.
Signed-off-by: Jon Simons <jon@jonsimons.org>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
This has been made opaque and it needs to be a pointer.
This is for OpenSSL 1.1.0 support.
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
* include/libssh/crypto.h (struct ssh_crypto_struct): Provide a
suitable 'ecdh_privkey'.
* include/libssh/ecdh.h: Also define 'HAVE_ECDH' if we do ECC using
libgcrypt.
(ecdh_build_k): New prototype.
* src/CMakeLists.txt (libssh_SRCS): Add backend-specific files.
* src/ecdh.c: Move backend-specific parts to...
* src/ecdh_crypto.c: ... this file.
* src/ecdh_gcrypt.c: New file.
* src/wrapper.c (crypto_free): Free 'ecdh_privkey'.
Signed-off-by: Justus Winter <justus@g10code.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
Ensure to free the z_stream structures as allocated from
the gzip.c initcompress, initdecompress functions.
Signed-off-by: Jon Simons <jon@jonsimons.org>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
The code is careful to reenable compression when rekeying.
Signed-off-by: Nicolas Viennot <nicolas@viennot.biz>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
The original code had a typo (COMP was CRYPT). This fixes the zlib compression
method.
Signed-off-by: Nicolas Viennot <nicolas@viennot.biz>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>