similar to: [Bug 2793] New: DH Group Exchange Incorrect Fallback

On 09/22/2017 06:55 PM, Tim Broberg wrote: > Do I understand correctly, that you find the security of group 14 unacceptable and yet you left it enabled? In the end, I'm trying to ensure a minimum equivalent of 128-bits of security. Group14 is 2048-bits, which roughly translates to 112-bits. [1] To this end, I disabled the "diffie-hellman-group14-sha1" and

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

On 09/22/2017 03:22 PM, Daniel Kahn Gillmor wrote: > On Thu 2017-09-21 18:12:44 -0400, Joseph S Testa II wrote: >> I gotta say... having a fallback mechanism here seems pretty >> strange. The entire point of the group exchange is to use a dynamic >> group and not a static one. > > fwiw, i think dynamic groups for DHE key exchange is intrinsically > problematic

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

On 09/22/2017 06:10 PM, Mark D. Baushke wrote: > I suppose you want to be more paranoid: > > DH * > dh_new_group_fallback(int max) > { > debug3("%s: requested max size %d", __func__, max); > if (max <= 2048) { > debug3("using 2k bit group 14"); > return dh_new_group14(); > }

http://bugzilla.mindrot.org/show_bug.cgi?id=769 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From dtucker at zip.com.au 2004-01-29

i'm not sure if anything has changed since https://marc.info/?l=openbsd-misc&m=151233345723889&w=2 On Wed, Jun 26, 2024 at 9:32?AM Joseph S. Testa II <jtesta at positronsecurity.com> wrote: > > Has anyone done any initial research into how much effort it would take > to port OpenSSH to Rust? If not, I might find that interesting to > start. (Mind you, this would

https://bugzilla.mindrot.org/show_bug.cgi?id=3705 Bug ID: 3705 Summary: Disk space exhaustion from PerSourcePenalties logging Product: Portable OpenSSH Version: -current Hardware: amd64 OS: Linux Status: NEW Severity: normal Priority: P5 Component: sshd Assignee:

I've had a patch on the bugzilla for a while related to U2F with support for a few additional settings such as providing a path to a specific key to use instead of the first one found and setting if user presence is required when using the key. Is there any objection to folding those parts in if appropriate? Joseph, to offer comment on NIST P-256. There was originally quite a limited subset

On 25 September 2017 at 02:32, Mark D. Baushke <mdb at juniper.net> wrote: > [+CC Loganaden Velvindron <logan at hackers.mu>] primary author of > the RFC 4419 refresh draft. https://datatracker.ietf.org/doc/draft-lvelvindron-curdle-dh-group-exchange/ ? Tangent: has any consideration been given to increasing the maximum allowed beyond 8192 bits (which is below the current NIST

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 Fri 2015-05-22 00:06:29 -0400, Darren Tucker wrote: > On Thu, May 21, 2015 at 11:26 PM, Matthew Vernon <matthew at debian.org> wrote: >> >> 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, >>

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

I don't think there is any point to generate so many moduli. Actually, 3 moduli of sizes 2048, 3072 and 4096 seem like a sane choice. On Fri, Feb 15, 2019 at 7:58 AM Darren Tucker <dtucker at dtucker.net> wrote: > > On Fri, 15 Feb 2019 at 14:22, Yegor Ievlev <koops1997 at gmail.com> wrote: > > I'm not nearly knowledgeable enough in crypto to fully understand your

http://bugzilla.mindrot.org/show_bug.cgi?id=769 Summary: dh-group-exchange should be configurable off in client and server Product: Portable OpenSSH Version: 3.7p1 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: ssh AssignedTo:

> Can this be addressed in ssh_config/sshd_config with the KexAlgorithms setting? weakdh.org/sysadmin.html recommends adding: KexAlgorithms curve25519-sha256 at libssh.org But this thread makes it sound as if it's not necessary. Can anyone confirm? Personally I'm on openssh-6.7. - Grant > You will be aware of https://weakdh.org/ by now, I presume; the take-home seems to be

https://bugzilla.mindrot.org/show_bug.cgi?id=2303 Bug ID: 2303 Summary: ssh (and perhaps even sshd) should allow to specify the minimum DH group sizes for DH GEX Product: Portable OpenSSH Version: 6.7p1 Hardware: All OS: All Status: NEW Severity: security Priority: P5

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

Hi, I admin a box that has Subversion users authenticate with public keys to a restricted 'svnuser' account. The comment field of all the keys describe who they belong to (it has their usernames), but unfortunately, sshd does not log this when a user successfully authenticates: Jun 21 08:18:22 localhost sshd[23636]: Accepted publickey for svnuser from x.x.x.x port 2065 ssh2 Jun

That doesn't seem to be the case. See https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf (5.6.1 Comparable Algorithm Strengths) On Fri, Feb 15, 2019 at 8:28 AM Darren Tucker <dtucker at dtucker.net> wrote: > > On Fri, 15 Feb 2019 at 16:00, Yegor Ievlev <koops1997 at gmail.com> wrote: > > I don't think there is any point to generate so