similar to: 2048-bit Diffie-Hellman parameters

A few questions regarding the OpenSSH support for the Diffie Hellman key exchange algorithms: (1) Are the diffie-hellman-group-exchange-sha256", "diffie-hellman-group-exchange-sha1" , "diffie-hellman-group14-sha1" "diffie-hellman-group1-sha1" (as defined in RFCs 4253 and RFC 4419) the complete list of key exchange algorithms supported by OpenSSH? (2) Is there a

Also, how are default moduli shipped with OpenSSH for use in diffie-hellman-group-exchange-sha1/sha256 chosen? Are they chosen randomly by developers or are they chosen for security properties? If they are random, why not use moduli from RFC 7919 instead, like Mozilla recommends? On Fri, Feb 15, 2019 at 3:48 AM Mark D. Baushke <mdb at juniper.net> wrote: > > Yegor Ievlev <koops1997

Hello, On Sun, Sep 22, 2024 at 10:15?AM Kurt Fitzner via openssh-unix-dev <openssh-unix-dev at mindrot.org> wrote: > > I would like to advocate for: > > - Change behaviour of the server to allow server operators to set the > minimum modulus group size allowable for a connection using > diffie-hellman-group-exchange-sha256 > Whether this is by having the server refuse

I referred to the fact that there is no value for 4096-bit groups at all. For higher strengths than 128 bits one should probably not use non-EC crypto at all, as the document suggests. On Fri, Feb 15, 2019 at 9:19 AM Darren Tucker <dtucker at dtucker.net> wrote: > > On Fri, 15 Feb 2019 at 16:45, Yegor Ievlev <koops1997 at gmail.com> wrote: > > That doesn't seem to be

I ask because the removal of diffie-hellman-group-exchange-sha1 happened accidently in 7.8 due to a mistake in a change to readconf.c. I noticed this and filed a bug about it along with a patch to fix readconf.c to use KEX_CLIENT_* like it used to: https://github.com/openssh/openssh-portable/commit/1b9dd4aa https://bugzilla.mindrot.org/show_bug.cgi?id=2967 Its clear the removal was unintentional

I'm not sure if collision resistance is required for DH key derivation, but generally, SHA-1 is on its way out. If it's possible (if there's not a very large percentage of servers that do not support anything newer), it should be disabled.

Can we disable diffie-hellman-group14-sha1 too? On Thu, Feb 14, 2019 at 10:23 PM Mark D. Baushke <mdb at juniper.net> wrote: > > Hi John, > > The short answer is YES. > > Jon DeVree <nuxi at vault24.org> writes: > > > I ask because the removal of diffie-hellman-group-exchange-sha1 happened > > accidently in 7.8 due to a mistake in a change to

https://bugzilla.mindrot.org/show_bug.cgi?id=2515 Bug ID: 2515 Summary: Implement diffie-hellman-group{14,15,16)-sha256 Product: Portable OpenSSH Version: -current Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P3 Component: ssh Assignee: dtucker at

Hello, I'd like to inform you that the next release of WinSCP SFTP client (version 5.7.5) will support Diffie-Hellman group exchange as specified by RFC 4419. http://winscp.net/tracker/show_bug.cgi?id=1345 So I'd like to ask you to kindly update the check in compat_datafellows() to WinSCP_release_4* WinSCP_release_5.0* WinSCP_release_5.1* WinSCP_release_5.2* WinSCP_release_5.5*

Hello all, I have recently had cause to dig a little into the specifics of how diffie-hellman-group-exchange-sha256 group sizes work. The belief in the wild, perpetuated by multiple sources of logjam mediation papers and also Andras Stribnik's very influential piece "Secure Secure Shell", is that server operators can force the use of a minimum group size by removing moduli

Thanks Joseph, Aki, but something missing from upgrade document, where does the dh param file go? I located ssl-parameters.dat so I will put it there. Quoting Joseph Tam <jtam.home at gmail.com>: > On Fri, 22 Jun 2018, Joseph Tam wrote: > >> However, recent advances make this condition obsolete [*] and not >> really safer, so a much faster way to generate a DH key is

hi sorry if question was asked already. Was reading https://wiki2.dovecot.org/Upgrading/2.3 first I'm confused on diffie hellman parameters file. I never set up ssl-parameters.dat before (should i have? do I have one that was automatically made for me by dovecot?) Do I need to make a fresh dh.pem? The upgrade doc tells how to convert ssl-parameters.dat but how to make a new one? other

Greetings, Given the weakness with Diffie-Hellman modp groups less than 2048, is it time to bump the suggested 1024 bit minimum value from the RFC 4419 to a more current 2048 value for OpenSSH 7.0? If so, should this be just a compile-time change, or should there be a new client and server runtime option? Thanks, -- Mark

Hi, You will be aware of https://weakdh.org/ by now, I presume; the take-home seems to be that 1024-bit DH primes might well be too weak. I'm wondering what (if anything!) you propose to do about this issue, and what Debian might do for our users? openssh already prefers ECDH, which must reduce the impact somewhat, although the main Windows client (PuTTY) doesn't support ECDH yet. But

I'm not nearly knowledgeable enough in crypto to fully understand your answer, but I will try. I wonder why moduli are not automatically generated the first time sshd is started though. That would make much more sense than shipping a default moduli file but also asking everyone to replace it with their own. On Fri, Feb 15, 2019 at 5:50 AM Mark D. Baushke <mdb at juniper.net> wrote: >

On 09/24/2017 12:21 AM, Mark D. Baushke wrote: > I suggest you upgrade to a more recent edition of the OpenSSH software. > The most recent release is OpenSSH 7.5 and OpenSSH 7.6 will be released > very soon. This problem is in v7.5 and v7.6. See dh.c:436. > OpenSSH 6.6 was first released on October 6, 2014. I brought up v6.6 to give an example that older clients wouldn't be

In message <Pine.LNX.4.30.0104031615270.8678-100000 at holly.crl.go.jp>, Tom Holro yd writes: >SRP has different requirements from Diffie-Hellman. In particular, >for SRP the generator must be primitive. It turns out that the "primes" >file contains only safe primes with primitive generators, and is thus >ideal for SRP, but so far in OpenSSH it has only been used for

Hi all, I am trying to implement an Incremental indexing scheme. The problem is that usually the modified documents are large but the modifications are limited. Ideally, I would like to reindex only the modified parts of these documents. If I am not mistaken, xapian cannot do that. Are there any other approaches? It would be nice if xapian supported something like the SQL "group by".

On Fri, May 22, 2015 at 12:27:01, Darren Tucker <dtucker at zip.com.au> wrote: > Note that PuTTY does do Diffie-Hellman Group Exchange, but until very > recently (ie after their 0.64 release) they didn't do the one that was > actually standardized in RFC4419. OpenSSH recently removed support for > that non-standard one and as a result we don't offer DHGEX to PuTTY >

https://bugzilla.mindrot.org/show_bug.cgi?id=2291 Bug ID: 2291 Summary: ssh -Q kex lists diffie-hellman-group1-sha1 twice Product: Portable OpenSSH Version: 6.7p1 Hardware: Other OS: Linux Status: NEW Severity: minor Priority: P5 Component: sftp-server Assignee: