search for: curve25519_size

...llo, I have question about buffer_put_bignum2_from_string function used in kexc25519.c in (OpenSSH >= 6.5) Is it 1:1 replacement for formating bignums from OpenSSL? If yes, then buffer_put_bignum2_from_string has different results for numbers starting with zeros. How to reproduce: shared_key[CURVE25519_SIZE] = "\0\0\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1"; buffer_put_bignum2_from_string(out, shared_key, CURVE25519_SIZE); and than same number format into bignum and than into wire format. Best regards, Jan

...--git a/kex.h b/kex.h index c35329501871a..159cfc794bd67 100644 --- a/kex.h +++ b/kex.h @@ -68,6 +68,9 @@ /* pre-auth compression (COMP_ZLIB) is only supported in the client */ #define COMP_ZLIB 1 #define COMP_DELAYED 2 +#define COMP_ZSTD 3 +#define COMP_ALL_C 4 +#define COMP_ALL_S 5 #define CURVE25519_SIZE 32 diff --git a/myproposal.h b/myproposal.h index ee6e9f7415261..a015190b35d9f 100644 --- a/myproposal.h +++ b/myproposal.h @@ -88,7 +88,7 @@ "rsa-sha2-512," \ "rsa-sha2-256" -#define KEX_DEFAULT_COMP "none,zlib at openssh.com" +#define KEX_DEFAULT_COMP "n...

I added ZSTD support to OpenSSH roughly three years ago and I've been playing with it ever since. The nice part is that ZSTD achieves reasonable compression (like zlib) but consumes little CPU so it is unlikely that compression becomes the bottle neck of a transfer. The compression overhead (CPU) is negligible even when uncompressed data is tunneled over the SSH connection (SOCKS proxy, port

I hacked zstd support into OpenSSH a while ago and just started to clean it up in the recent days. The cleanup includes configuration support among other things that I did not have. During testing I noticed the following differences compared to zlib: - highly interactive shell output (as in refreshed at a _very_ high rate) may result in higher bandwidth compared to zlib. Since zstd is quicker

I added ZSTD support to OpenSSH roughly over a year and I've been playing with it ever since. The nice part is that ZSTD achieves reasonable compression (like zlib) but consumes little CPU so it is unlikely that compression becomes the bottle neck of a transfer. The compression overhead (CPU) is negligible even when uncompressed data is tunneled over the SSH connection (SOCKS proxy, port

In sshconnect.c there are two global variables for server_version_string client_version_string. These are used just in a few functions and can easily be passed as parameters. Also, there is a strange construct, where their memory is allocated to the global pointers, then copies of these pointers are assigned to the kex structure. The kex_free finally frees them via cleanup of the kex