search for: rfc4419

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

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 > versions <= 0.64 so they'll fall back to group14 (2k bit fix group). I think this is wrong. This commit [0] from 2005 appears to show the addition of diffie-hellman-grou...

...ution. Ever. > > If you are using OpenSSH, then look at the moduli command to generate > the moduli file. > > That said, you may generate P and Q any way you like, the goal is that > they be safe primes with a small generator G. > > Although, if you follow the suggestions in RFC4419, you will more than > likely select a safe-prime G,Q,P set where the generator g will not > generate a proper Q-Ordered subgroup of P. This is a big deal if you > want to do FIPS certification. That said, NIST still has not come out > with a change to their standards to allow safe-prime...

...erver's DH-GEX exchange hash includes the DH group sizes it received from the client. If these are modified in transit the exchange hash will not match. > it still doesn't give the server > admin a good way to "block out" weak clients. Do any such clients actually exist? RFC4419 says DH-GEX implementations SHOULD have a max group size of 8k. -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug.

I completely support this request. ?My organization is interested in supporting these public key algorithms to comply with NIST SP 800-131A too. Jeff, it is my understanding that through RFC4419, OpenSSH can be support the Key Agreement Using Diffie-Hellman and MQV guidelines in SP 800-131A using the "diffie-hellman-group-exchange-sha256" method. ?Is that correct? Thanks.

On Fri, 2019-02-15 at 15:57 +1100, Darren Tucker wrote: > That was the original intent (and it's mentioned in RFC4419) however > each moduli file we ship (70-80 instances of 6 sizes) takes about 1 > cpu-month to generate on a lowish-power x86-64 machine. Most of it > is > parallelizable, but even then it'd likely take a few hours to > generate > one of each size. I imagine that'd cause...

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

...hy 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. > > That was the original intent (and it's mentioned in RFC4419) however > each moduli file we ship (70-80 instances of 6 sizes) takes about 1 > cpu-month to generate on a lowish-power x86-64 machine. Most of it is > parallelizable, but even then it'd likely take a few hours to generate > one of each size. I imagine that'd cause some comp...

https://bugzilla.mindrot.org/show_bug.cgi?id=2302 Bug ID: 2302 Summary: ssh (and sshd) should not fall back to deselected KEX algos Product: Portable OpenSSH Version: 6.7p1 Hardware: All OS: All Status: NEW Severity: security Priority: P5 Component: ssh

https://bugzilla.mindrot.org/show_bug.cgi?id=2302 Bug ID: 2302 Summary: ssh (and sshd) should not fall back to deselected KEX algos Product: Portable OpenSSH Version: 6.7p1 Hardware: All OS: All Status: NEW Severity: security Priority: P5 Component: ssh

...t; 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: > > The diffie-hellman-group-exchange-sha1 is an optional key exchange > method provided by RFC4419 and updated by RFC8270. > > Support for it is not required and may (and in my opinion should) be > disabled by default without any impact to the SSHv2 protocol. > > The only two Mandatory To Implement (MTI) key exchange methods are those > in RFC3253 (diffie-hellman-group1-sha1 an...

...sion: -current Hardware: Other OS: All Status: NEW Severity: normal Priority: P5 Component: sshd Assignee: unassigned-bugs at mindrot.org Reporter: djm at mindrot.org Older versions of WinSCP don't implement RFC4419-style DH-GEX. WinSCP developer Martin Prikryl provided this list of versions: > > WinSCP_release_4* > > WinSCP_release_5.0* > > WinSCP_release_5.1* > > WinSCP_release_5.2* > > WinSCP_release_5.5* > > WinSCP_release_5.6* > > WinSCP_release_5.7 > > Win...

e.g. can we make it throw warnings etc. rsa-sha2-256 and rsa-sha2-512 are fine, they use PSS. On Sun, Jan 20, 2019 at 1:55 AM Yegor Ievlev <koops1997 at gmail.com> wrote: > > Also can we do anything with ssh-rsa? It uses both SHA-1 and > deprecated PKCS#1 padding. If it's used to sign certificates, there's > no additional protection of SHA-2 hashing before SHA-1

Hi, I'm interested in requiring a minimum of 3072-bit DH moduli when using the "diffie-hellman-group-exchange-sha256" kex, so I edited my /etc/ssh/moduli file such that only 3071+ moduli are left. However, when clients ask for a max of 2048-bit moduli, they actually get one (!). I poked around and found that a fallback mechanism exists (dh.c:185), which returns back the

https://bugzilla.mindrot.org/show_bug.cgi?id=2424 Bug ID: 2424 Summary: Compatibility for iSSH and Ubuntu/Mint Putty Product: Portable OpenSSH Version: 6.9p1 Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P5 Component: sshd Assignee: unassigned-bugs at

...* ssh(1), sshd(8): Refuse old proprietary clients and servers that use a weaker key exchange hash calculation. * ssh(1): Increase the size of the Diffie-Hellman groups requested for each symmetric key size. New values from NIST Special Publication 800-57 with the upper limit specified by RFC4419. * ssh(1), ssh-agent(1): Support pkcs#11 tokes that only provide X.509 certs instead of raw public keys (requested as bz#1908). * ssh(1): Add a ssh_config(5) "Match" keyword that allows conditional configuration to be applied by matching on hostname, user and result of arbitr...

https://bugzilla.mindrot.org/show_bug.cgi?id=2209 Bug ID: 2209 Summary: Problem logging into Cisco devices under 6.5p1 (kexgexc.c) Product: Portable OpenSSH Version: 6.5p1 Hardware: amd64 OS: FreeBSD Status: NEW Severity: normal Priority: P5 Component: ssh

...* ssh(1), sshd(8): Refuse old proprietary clients and servers that use a weaker key exchange hash calculation. * ssh(1): Increase the size of the Diffie-Hellman groups requested for each symmetric key size. New values from NIST Special Publication 800-57 with the upper limit specified by RFC4419. * ssh(1), ssh-agent(1): Support pkcs#11 tokes that only provide X.509 certs instead of raw public keys (requested as bz#1908). * ssh(1): Add a ssh_config(5) "Match" keyword that allows conditional configuration to be applied by matching on hostname, user and result of arbitr...

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

...* ssh(1), sshd(8): Refuse old proprietary clients and servers that use a weaker key exchange hash calculation. * ssh(1): Increase the size of the Diffie-Hellman groups requested for each symmetric key size. New values from NIST Special Publication 800-57 with the upper limit specified by RFC4419 * ssh(1), ssh-agent(1): Support pkcs#11 tokes that only provide X.509 certs instead of raw public keys (requested as bz#1908). * ssh(1): Add a ssh_config(5) "Match" keyword that allows conditional configuration to be applied by matching on hostname, user and result of arbitra...