similar to: ChaCha20 Rekey Frequency

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);

On Wed, 29 Mar 2023, Chris Rapier wrote: > 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

I'm hardly an expert on this, but if I remember correctly, the rekey rate for good security is mostly dependent on the cipher block size. I left my reference books at home; so, I can't come up with a reference for you, but I would take Chris' "I'm deeply unsure of what impact that would have on the security of the cipher" comment seriously and switch to a cipher with a

That's true for block ciphers, but ChaCha20+poly1305 is a stream cipher. On Wed, 29 Mar 2023, Robinson, Herbie wrote: > > I?m hardly an expert on this, but if I remember correctly, the rekey rate > for good security is mostly dependent on the cipher block size.? I left my > reference books at home; so, I can?t come up with a reference for you, but I > would take Chris?

Ah, with an internal block size [Is that what one calls it?] of 64 bytes. From: Damien Miller <djm at mindrot.org> Sent: Wednesday, March 29, 2023 3:08 PM To: Robinson, Herbie <Herbie.Robinson at stratus.com> Cc: Chris Rapier <rapier at psc.edu>; Christian Weisgerber <naddy at mips.inka.de>; openssh-unix-dev at mindrot.org Subject: RE: [EXTERNAL] Re: ChaCha20 Rekey

Hi Damien, >This is what I'm playing with at the moment: if you?re playing with this currently anyway, shouldn?t? >+ /* >+ * Otherwise, use the RFC4344 s3.2 recommendation of 2**(L/4) blocks >+ * before rekeying where L is the blocksize in bits. >+ * Most other ciphers have a 128 bit blocksize, so this equates to >+ * 2**32 blocks / 64GB data. >+ */ >+ return

On Wed, 29 Mar 2023, Thorsten Glaser wrote: > Hi Damien, > > >This is what I'm playing with at the moment: > > if you?re playing with this currently anyway, shouldn?t? > > >+ /* > >+ * Otherwise, use the RFC4344 s3.2 recommendation of 2**(L/4) blocks > >+ * before rekeying where L is the blocksize in bits. > >+ * Most other ciphers have a 128

I plan to use ssh as the secure transport of a VPN. (Yes I know there are other solutions but...) These tunnels may be up for a long time, days or weeks, and escape characters will be turned off because I'll be passing binary data so I can't force a rekey with that method. Since the ssh spec says one should rekey every hour, I plan to patch the ssh client to implement an auto-rekey

https://bugzilla.mindrot.org/show_bug.cgi?id=2264 Bug ID: 2264 Summary: RekeyLimit option does not allow '4G' value when UINT_MAX is 0xffffffff Product: Portable OpenSSH Version: 6.6p1 Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P5

On Thu, 30 Mar 2023, Damien Miller wrote: >> >+ return (uint64_t)1 << (c->block_size * 2); >> >> ? this get an upper bound? This is UB for 256-bit blocksizes >> at least? > >block sizes in struct sshcipher are in bytes, not bits Yes, exactly. 256 bit = 32 bytes; 32*2 = 64; (uint64_t)1 << 64 is UB. bye, //mirabilos -- Infrastrukturexperte ?

Using OpenSSL, is there a preferred/recommended rate of rekeying an encrypted stream of data? Does OpenSSL handle this for developers behind the scenes? Does it even need to be rekeyed? Thanks in advance. -sc -- Sean Chittenden -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 202 bytes Desc: not available

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

https://bugzilla.mindrot.org/show_bug.cgi?id=2521 Bug ID: 2521 Summary: subtract buffer size from computed rekey limit to avoid exceeding it Product: Portable OpenSSH Version: 6.8p1 Hardware: amd64 OS: Linux Status: NEW Severity: minor Priority: P5 Component: sshd

From: Sebastian Andrzej Siewior <sebastian at breakpoint.cc> The "zstd at breakpoint.cc" compression algorithm enables ZSTD based compression as defined in RFC8478. The compression is delayed until the server sends the SSH_MSG_USERAUTH_SUCCESS which is the same time as with the "zlib at openssh.com" method. Signed-off-by: Sebastian Andrzej Siewior <sebastian at

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

On Fri, 9 Jun 2023, Chris Rapier wrote: > Hi all, > > When a client requests dynamic remote forwarding with -R it delays forking > into the background. In ssh.c we see > > if (options.fork_after_authentication) { > if (options.exit_on_forward_failure && > options.num_remote_forwards > 0) { > debug("deferring postauth fork until

Hi, mancha and me debugged a problem with OpenSSH 7.3p1 that was reported on the #openssh freenode channel. Symptoms were that this message was popping on the console during a busy X11 session: kex protocol error: type 7 seq 1234 I managed to reproduce the problem, it is related to the SSH_EXT_INFO packet that is send by the server every time it is sending an SSH_NEWKEYS packet, hence after

Dear all, while playing around with openssh-4.1p1 (trying to add AFS token forwarding in SSH-2), I noticed that agressive rekeying (as e.g. employed by regress/rekey.sh, rekeying every 16bytes) seems to disturb the various forwardings (X11, agent) set up at the beginning of the session. These do not trigger regression test errors, since the client does not ask for confirmation from the server for

> Portable OpenSSH is also available via [...] Github: https://github.com/openssh/openssh-portable > > Running the regression tests supplied with Portable OpenSSH does not require installation and is a simply: > > $ ./configure && make tests I was going to try this on Kali Linux (latest version), but ran into trouble right away. No "configure" script exists