similar to: Rekeying

https://bugzilla.mindrot.org/show_bug.cgi?id=2929 Bug ID: 2929 Summary: OpenSSH server should not send the SSH_MSG_EXT_INFO message after rekeying Product: Portable OpenSSH Version: 7.7p1 Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P5

Hello, It seems to me the algorithm negotiation of the transport layer has a bug, it does not follow the specification of draft-ietf-secsh-transport-24, page 19, where the behaviour of first_kex_packet_follows is specified. I've got an ssh client that sends an SSH_MSG_KEXINIT message and specifies only 'diffie-hellman-group1-sha1' as key exchange algorithm. It sets

Hi, I am using OpenSSH_5.2p1. It seems ssh server doesn't support key regeneration after a specified amount of time. I manually verified the OpenSSH_5.2p1 and OpenSSH-6.2 source codes and haven?t found any code support for session rekeying in both releases. SSH2 supports session rekeying using the parameter ?RekeyIntervalSeconds? with default value 3600 seconds (one hour) in both

Dear all, For my thesis, I've been working on automatic inference of state machines for SSH servers. I ran into a couple of particularities regarding OpenSSH's inferred state machine, and was hoping some of you might be interested. Maybe you can even shed some light on it. Setup: I'm using LearnLib's (Java) version of the L* learning algorithm [1] to come up with sequences of

OpenSSH 2.9 has just been uploaded. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 implementation and includes sftp client and server support. This release contains many portability bug-fixes (listed in the ChangeLog) as well as several new features (listed below). We would like to thank the

OpenSSH 2.9 has just been uploaded. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 implementation and includes sftp client and server support. This release contains many portability bug-fixes (listed in the ChangeLog) as well as several new features (listed below). We would like to thank the

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

Hi, My name is Stefan Mangard and I plan to implement an extension to ssh as a final project in a cryptography class. Since I want to use an open source of ssh, I decided to use the openssh implementation. I am currently working with openssh-1.2.3, but I'd also like to implement my extension for protocol 2, I wanted to ask you how far the development of the implementation of openssh-2 is.

I could not find anything in the mailing list archive or bug tracker. In ssh2.h, the value (4) is re-used 148 #define SSH2_DISCONNECT_KEY_EXCHANGE_FAILED 3 149 #define SSH2_DISCONNECT_HOST_AUTHENTICATION_FAILED 4 150 #define SSH2_DISCONNECT_RESERVED 4 151 #define SSH2_DISCONNECT_MAC_ERROR 5 Is this intentional? Thanks, Noah Zalev

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

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

Greetings, Just wondering if there is an RFC describing the secure shell protocols? Thanks, Chris

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?

Old news, but ... http://lwn.net/Articles/298833/ I first posted about this back in 2001 and it's still not resolved: http://osdir.com/ml/ietf.secsh/2001-09/msg00000.html 1) high latency networks are a reality that will never go away. In fact they will only become more prevalent since distributed networks continue to grow broader but (surprise) the speed of light remains a constant. 2)

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

https://bugzilla.mindrot.org/show_bug.cgi?id=2948 Bug ID: 2948 Summary: implement "copy-data" sftp extension Product: Portable OpenSSH Version: -current Hardware: All URL: https://tools.ietf.org/html/draft-ietf-secsh-filexfer- extensions-00#section-7 OS: All Status: NEW

Hello, I had some difficulties in order to convert private keys between different implementations of SSH. So, I wrote the following patch to allow export of SSH2 RSA and DSA private keys into IETF SECSH format. Note that I also slightly revised the IETF SECSH key import code. Usage: use of the "-e" option on a private key file generates an unencrypted private key file in IETF SECSH

Is it possible to use encryption only for authenticate and then switch to no encryption? I've looked at the code for OpenSSH 3.5p1, cipher.c, and it looks like the answer is no, at least for protocol 1. However, I cannot tell if that is a deliberate design limitation of the implementation or if it is inherent in ssh protocol 2. My dilemma is a customer who wants to use their network IDS

Dear list, Attached is a patch that adds support for the SSH_FXP_LINK request, as described in draft-ietf-secsh-filexfer-07 onwards, to the sftp server and client. It is for and has been tested on the current portable snapshot but also applies to openbsd CVS. Thanks, -- Peter -------------- next part -------------- A non-text attachment was scrubbed... Name: openssh-sftp-hardlink-pcvs-v2.patch