search for: rfc4344

...blocks as the + * 128-bit block ciphers do (i.e. every 32GB data). + */ + if ((c->flags & CFLAG_CHACHAPOLY) != 0) + return (uint64_t)1 << 32; + /* + * The 2^(blocksize*2) limit is too expensive for 3DES, + * so enforce a 1GB data limit for small blocksizes. + * See discussion in RFC4344 section 3.2. + */ + if (c->block_size < 16) + return ((uint64_t)1 << 30) / c->block_size; + /* + * 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 equ...

...2**32 blocks as the + * 128-bit block ciphers do (i.e. every 32GB data). + */ + if ((c->flags & CFLAG_CHACHAPOLY) != 0) + return (uint64_t)1 << 32; + /* + * The 2^(blocksize*2) limit is too expensive for 3DES, + * so enforce a 1GB data limit for small blocksizes. + * See discussion in RFC4344 section 3.2. + */ + if (c->block_size < 16) + return ((uint64_t)1 << 30) / c->block_size; + /* + * 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...

...mething >> obvious? > > That looks to be accidental. > > The default rekey limit is set in ssh_set_newkeys(): > /* > * The 2^(blocksize*2) limit is too expensive for 3DES, > * so enforce a 1GB limit for small blocksizes. > * See RFC4344 section 3.2. > */ > if (enc->block_size >= 16) > *max_blocks = (u_int64_t)1 << (enc->block_size*2); > else > *max_blocks = ((u_int64_t)1 << 30) / enc->block_size; > if (state->rekey_l...

...ock ciphers do (i.e. every 32GB data). > + */ > + if ((c->flags & CFLAG_CHACHAPOLY) != 0) > + return (uint64_t)1 << 32; > + /* > + * The 2^(blocksize*2) limit is too expensive for 3DES, > + * so enforce a 1GB data limit for small blocksizes. > + * See discussion in RFC4344 section 3.2. > + */ > + if (c->block_size < 16) > + return ((uint64_t)1 << 30) / c->block_size; > + /* > + * 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...

...ock ciphers do (i.e. every 32GB data). > + */ > + if ((c->flags & CFLAG_CHACHAPOLY) != 0) > + return (uint64_t)1 << 32; > + /* > + * The 2^(blocksize*2) limit is too expensive for 3DES, > + * so enforce a 1GB data limit for small blocksizes. > + * See discussion in RFC4344 section 3.2. > + */ > + if (c->block_size < 16) > + return ((uint64_t)1 << 30) / c->block_size; > + /* > + * 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...

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 (uint64_t)1 << (c->block_size * 2); ? this get an upper boun...

I'm wondering why the ChaCha20 cipher rekeys so frequently. At speed I'm seeing rekeys every second or two. So I'm spending a large amount of time in the rekey process. From what I've read about ChaCha20 it shouldn't need to be rekeyed quite so frequently. Am I missing something obvious? Just curious more than anything else. Chris

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 bit blocksize, so this equates to > >+ * 2**32 blocks / 64GB data. > >+ */ > >+ return (uint64_t)1 << (c->block_size * 2);...

Hi OpenSSH team, I find a url http://www.gossamer-threads.com/lists/openssh/dev/42808?do=post_view_threaded#42808, which provides unofficial patch for FIPS Capable OpenSSH. I try it and it seems working for some cases. (BTW, I also find that aes128-ctr, aes192-ctr and aes256-ctr ciphers can't work in FIPS mode properly. The fips mode sshd debug info is as following.

http://bugzilla.mindrot.org/show_bug.cgi?id=1340 Summary: Support for Camellia block cipher to OpenSSH-portable. Product: Portable OpenSSH Version: -current Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Miscellaneous AssignedTo: bitbucket at mindrot.org

https://bugzilla.mindrot.org/show_bug.cgi?id=2726 Bug ID: 2726 Summary: Uploading of large files (1GB+) fails when using SFTP in chrooted configuration Product: Portable OpenSSH Version: 7.3p1 Hardware: amd64 OS: Linux Status: NEW Severity: normal Priority: P5