similar to: Typo in a manpage

On Tue 2015-05-26 14:02:07 -0400, Hubert Kario wrote: > On Tuesday 26 May 2015 13:43:13 Daniel Kahn Gillmor wrote: >> On Tue 2015-05-26 12:57:05 -0400, Hubert Kario wrote: >> > creating composites that will pass even 100000 rounds of Miller-Rabin is >> > relatively simple.... >> > (assuming the values for M-R tests are picked randomly) >> >> Can you

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 Tue 2015-05-26 12:57:05 -0400, Hubert Kario wrote: > creating composites that will pass even 100000 rounds of Miller-Rabin is > relatively simple.... > (assuming the values for M-R tests are picked randomly) Can you point me to the algorithms for doing that? This would suggest that we really do want primality proofs (and a good way to verify them). Do those algorithms hold for

Hello, I was re-generating the moduli for SSH, and during that process I noticed that, when running the following command: ssh-keygen -M screen -O prime-tests=600 -O generator=3 -f moduli-2048-01.candidates moduli-2048-01c It does not produce any errors, only the following: ebug2: ???1467763: (4) Sophie-Germain debug2: ???1467763: generator 0 != 3 debug2: ???1467764: (4) Sophie-Germain

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

Works on my netbsd tinkerbox. NetBSD 5.0.2 NetBSD 5.0.2 (GENERIC) It uses rlimit. Privsep sandbox style: rlimit I also get warnings during make. fmt_scaled.c: In function 'scan_scaled': fmt_scaled.c:84: warning: array subscript has type 'char' fmt_scaled.c:111: warning: array subscript has type 'char' fmt_scaled.c:155: warning: array subscript has type 'char'

Hi folks, This applies to src/share/man/man5/moduli.5 in the OpenBSD source tree, and doesn't seem to apply to the portable OpenSSH, so I've sent this change here instead of via Bugzilla. The wording of moduli(5) implies that sshd puts more thought about which modulus it selects than it really does. The following patch corrects this. Simon. -- Simon Burge

On Wed 2015-05-27 05:23:41 -0400, Hubert Kario wrote: > On Tuesday 26 May 2015 15:10:01 Daniel Kahn Gillmor wrote: >> On Tue 2015-05-26 14:02:07 -0400, Hubert Kario wrote: >> > OEIS A014233 >> >> Hm, this is a sequence, but not an algorithm. It looks to me like it is >> not exhaustive, just a list of those integers which are known to have >> the stated

Hello, I was re-generating the moduli for SSH, and during that process I noticed that, when running the following command: ssh-keygen -M screen -O prime-tests=600 -O generator=3 -f moduli-2048-01.candidates moduli-2048-01c It does not produce any errors, only the following: ebug2: ???1467763: (4) Sophie-Germain debug2: ???1467763: generator 0 != 3 debug2: ???1467764: (4) Sophie-Germain

Hello, Just found a typo in sftp.1 manpage: s/ether/either/ Regards -- ^L.

Hi, I want to integrate openpam with openssh in our server (which uses QNX632 operating system). I am facing some problems in the "make install" part of openssh. Following are the steps I followed to build zlib, openssl, openpam and openssh. *NOTE*: Since I want the sshd and ssh binaries in my server(using QNX), I had to cross compile the packages for QNX (environment was set to x86)

Hi, Can anybody briefly explain the significance of the updated moduli file? Is this a critical update? Should all existing installations update their moduli file? Thanks in advance, -- Dan

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

https://bugzilla.mindrot.org/show_bug.cgi?id=1408 Summary: Remove references to login.conf from sshd_config man page on Mac OS X. Classification: Unclassified Product: Portable OpenSSH Version: 4.7p1 Platform: Other OS/Version: Mac OS X Status: NEW Severity: normal Priority: P2

Hi, my question is related to the kex algorithm diffie-hellman-group-exchange-sha256 and moduli generation. I've seen that through ssh-keygen, I'm able to re-generate my moduli file used by DH but I'm note sure to understand one point in the ssh-keygen manpage : "Screened DH groups may be installed in /etc/ssh/moduli. It is important that this file contains moduli of a range of

When doing a make with the portable developer version, I came across this error: ssh/ssh_host_ecdsa_key|/opt/etc/ssh_host_ecdsa_key|g' -e 's|/etc/ssh/ssh_host_dsa_key|/opt/etc/ssh_host_dsa_key|g' -e 's|/etc/ssh/ssh_host_rsa_key|/opt/etc/ssh_host_rsa_key|g' -e 's|/var/run/sshd.pid|/var/run/sshd.pid|g' -e 's|/etc/moduli|/opt/etc/moduli|g' -e

Hello, System info: Sparcstation 5, Solaris 2.7, openssl-0.9.8i. I've tried to install openssh-3.9p1 openssh-4.9p1 openssh-5.1p1 all failed the similar way. The following is the last portion of the 'make install' printout. ./install-sh -c -m 0755 -s ssh /usr/local/bin/ssh BFD: /usr/local/bin/stkuaiGw: warning: allocated section `.interp' not in segment ./install-sh -c -m 0755

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, 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

On Thu, 28 May 2015, Hubert Kario wrote: > > If this is the only attack you're trying to address, and you've > > already limited yourself to safe primes, then NUMS properties don't > > really add anything. The NUMS approach is there are to try to avoid > > the possibility of other, unknown cryptanalytic attacks against some > > infrequent type of group,