search for: mode_out

...COMP_ZLIB || - (comp->type == COMP_DELAYED && + ((comp->type == COMP_DELAYED || comp->type == COMP_ZSTD) && state->after_authentication)) && comp->enabled == 0) { if ((r = ssh_packet_init_compression(ssh)) < 0) return r; - if (mode == MODE_OUT) { - if ((r = start_compression_out(ssh, 6)) != 0) - return r; + if (comp->type == COMP_ZSTD) { + if (mode == MODE_OUT) { + if ((r = start_compression_zstd_out(ssh)) != 0) + return r; + } else { + if ((r = start_compression_zstd_in(ssh)) != 0) + return r; + } + comp-&...

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

...child_state.ivin = buffer_get_binary(&m, &child_state.ivinlen); goto skip; } else { /* Get the Kex for rekeying */ *pmonitor->m_pkex = mm_get_kex(&m); } - blob = buffer_get_string(&m, &bloblen); + blob = buffer_get_binary(&m, &bloblen); current_keys[MODE_OUT] = mm_newkeys_from_blob(blob, bloblen); xfree(blob); debug3("%s: Waiting for second key", __func__); - blob = buffer_get_string(&m, &bloblen); + blob = buffer_get_binary(&m, &bloblen); current_keys[MODE_IN] = mm_newkeys_from_blob(blob, bloblen); xfree(blob); @@...

....c @@ -55,6 +55,7 @@ #include <poll.h> #include <signal.h> #include <time.h> +#include <util.h> #ifdef WITH_ZLIB #include <zlib.h> @@ -850,6 +851,7 @@ ssh_set_newkeys(struct ssh *ssh, int mode) const char *wmsg; int r, crypt_type; const char *dir = mode == MODE_OUT ? "out" : "in"; + char blocks_s[FMT_SCALED_STRSIZE], bytes_s[FMT_SCALED_STRSIZE]; debug2_f("mode %d", mode); @@ -917,20 +919,18 @@ ssh_set_newkeys(struct ssh *ssh, int mode) } comp->enabled = 1; } - /* - * The 2^(blocksize*2) limit is too expensive fo...

...+++ b/packet.c @@ -55,6 +55,7 @@ #include <poll.h> #include <signal.h> #include <time.h> +#include <util.h> #ifdef WITH_ZLIB #include <zlib.h> @@ -850,6 +851,7 @@ ssh_set_newkeys(struct ssh *ssh, int mode) const char *wmsg; int r, crypt_type; const char *dir = mode == MODE_OUT ? "out" : "in"; + char blocks_s[FMT_SCALED_STRSIZE], bytes_s[FMT_SCALED_STRSIZE]; debug2_f("mode %d", mode); @@ -917,20 +919,18 @@ ssh_set_newkeys(struct ssh *ssh, int mode) } comp->enabled = 1; } - /* - * The 2^(blocksize*2) limit is too expensive for 3DES, - * s...

...Severity: trivial Priority: P5 Component: ssh Assignee: unassigned-bugs at mindrot.org Reporter: markus at blueflash.cc During initialization there a memory leak occurs in ssh_set_newkeys(). During startup ssh_set_newkeys() is called twice, once with MODE_OUT and once with MODE_IN. Accordingly the ccp pointer points to state->send_context and state->receive_context At this time state->newkeys[mode] is stil NULL, so the if-clause ("rekeying") does not apply. Further down cipher_init(ccp, ) is called. First thing that cipher_init()...

....h> > #include <signal.h> > #include <time.h> > +#include <util.h> > > #ifdef WITH_ZLIB > #include <zlib.h> > @@ -850,6 +851,7 @@ ssh_set_newkeys(struct ssh *ssh, int mode) > const char *wmsg; > int r, crypt_type; > const char *dir = mode == MODE_OUT ? "out" : "in"; > + char blocks_s[FMT_SCALED_STRSIZE], bytes_s[FMT_SCALED_STRSIZE]; > > debug2_f("mode %d", mode); > > @@ -917,20 +919,18 @@ ssh_set_newkeys(struct ssh *ssh, int mode) > } > comp->enabled = 1; > } > - /* > - * The 2^(b...

I was wondering if there was something specific to the internal chacha20 cipher as opposed to OpenSSL implementation. I can't just change the block size because it breaks compatibility. I can do something like as a hack (though it would probably be better to do it with the compat function): if (strstr(enc->name, "chacha")) *max_blocks = (u_int64_t)1 << (16*2);

...l.h> > #include <signal.h> > #include <time.h> > +#include <util.h> > > #ifdef WITH_ZLIB > #include <zlib.h> > @@ -850,6 +851,7 @@ ssh_set_newkeys(struct ssh *ssh, int mode) > const char *wmsg; > int r, crypt_type; > const char *dir = mode == MODE_OUT ? "out" : "in"; > + char blocks_s[FMT_SCALED_STRSIZE], bytes_s[FMT_SCALED_STRSIZE]; > > debug2_f("mode %d", mode); > > @@ -917,20 +919,18 @@ ssh_set_newkeys(struct ssh *ssh, int mode) > } > comp->enabled = 1; > } > - /* > - * The 2^(blo...

I'm reading this fine article on O'Reilly: http://linux.oreillynet.com/lpt/a//linux/2001/11/08/ssh_keystroke.html <quote> The paper concludes that the keystroke timing data observable from today's SSH implementations reveals a dangerously significant amount of information about user terminal sessions--enough to locate typed passwords in the session data stream and reduce the

...75,7 @@ enc->iv, enc->cipher->block_size); memset(enc->iv, 0, enc->cipher->block_size); memset(enc->key, 0, enc->cipher->key_len); +#ifdef WITH_COMPRESSION if (comp->type != 0 && comp->enabled == 0) { packet_init_compression(); if (mode == MODE_OUT) @@ -475,6 +484,7 @@ buffer_compress_init_recv(); comp->enabled = 1; } +#endif } /* @@ -509,6 +519,7 @@ buffer_dump(&outgoing_packet); #endif +#ifdef WITH_COMPRESSION if (comp && comp->enabled) { len = buffer_len(&outgoing_packet); /* skip header, com...