search for: nistpubs

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

Following is sharelessly copied from one of the newsgroups I read on grc.com.. /Soren NIST issues recommendations for secure VOIP http://www.gcn.com/vol1_no1/daily-updates/34747-1.html http://csrc.nist.gov/publications/nistpubs/800-58/SP800-58-final.pdf *********************************************************** Quote *********************************************************** The National Institute of Standards and Technology has offered some cautionary advice for offices considering moving their telephone systems to vo...

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

...L = 3072, N = 256 And it would seem that the L=2048,N=256 L=3072,N=256 selections are now possible while remaining standards compliant. It appears that OpenSSH has added support for SHA-256 and SHA-512 in version 5.9p1 (2011-09). [1] http://tools.ietf.org/html/rfc6668 [2] http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf -- 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.

...L = 3072, N = 256 And it would seem that the L=2048,N=256 L=3072,N=256 selections are now possible while remaining standards compliant. It appears that OpenSSH has added support for SHA-256 and SHA-512 in version 5.9p1 (2011-09). [1] http://tools.ietf.org/html/rfc6668 [2] http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf -- 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.

...5PM -0400, Daniel Kahn Gillmor wrote: > On Tue 2015-05-26 15:39:49 -0400, Mark D. Baushke wrote: > > Hi Folks, > > > > The generator value of 5 does not lead to a q-ordered subgroup which > > is needed to pass tests in > > > > http://csrc.nist.gov/publications/nistpubs/800-56A/SP800-56A_Revision1_Mar08-2007.pdf > > I pulled revision 2 of this document from here: > > https://dx.doi.org/10.6028/nist.sp.800-56ar2 > > The "FFC Domain Parameter Generation" section does say: > > g is a generator of the cyclic subgroup of GF(p)*...

...PS 186-3/186-4 standards compliant. It also appears that OpenSSH added support for both SHA-256 and SHA-512 in version 5.9p1 (2011-09). I have updated bug 1647 with the additional information. Are there any plans to add support for generating DSA 2048, 3072 keys? [1] http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf [2] https://bugzilla.mindrot.org/show_bug.cgi?id=1647 [3] http://tools.ietf.org/html/rfc6668 --Kyle P.S. What, by the way, does OpenSSH do if you have an existing DSA 2048 or 3072 key? (OpenSSL will generate them just fine.)

...back to group14, even when specifically told not to (by the admin removing 2048-bit groups in /etc/ssh/moduli). There's currently no way to ensure 100% that 2048-bit DH is disabled. - Joe [1] See NIST Special Publication 800-57, Part 1, Revision 4, p. 53, <http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf>.

https://bugzilla.mindrot.org/show_bug.cgi?id=2302 --- Comment #4 from Damien Miller <djm at mindrot.org> --- Comment on attachment 2630 --> https://bugzilla.mindrot.org/attachment.cgi?id=2630 Make the DH-GEX fallback group 4k bit. Where did this group come from? IMO it would be best to use one of the standard groups if we're picking another fixed one - logjam attacks aren't

...emented aes128-gcm at openssh.com and aes256-gcm at openssh.com with specified semantics during negotiation to ensure that a non-toxic selection is made and otherwise uses the RFC 5647 wire protocol for the traffic. > > [1] http://tools.ietf.org/html/rfc6668 > [2] http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf > > -- > 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. > _______________________________________________ > openssh-bugs mailing list > openssh-bugs at mindrot....

...release) is good timing to consider this change. Is there a reason not to do this? OK? Kind regards, Job Further reading: Original Ed25519 paper: https://ed25519.cr.yp.to/ed25519-20110926.pdf IETF RFC 8032: https://datatracker.ietf.org/doc/html/rfc8032 FIPS 186-5: https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf Index: ssh-keygen.1 =================================================================== RCS file: /cvs/src/usr.bin/ssh/ssh-keygen.1,v retrieving revision 1.229 diff -u -p -r1.229 ssh-keygen.1 --- ssh-keygen.1 23 Jul 2023 20:04:45 -0000 1.229 +++ ssh-keygen.1 3 Sep 2023 21:...

...uss this change further The https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev mailing list is the best place to discuss this. Alternately you can email the OpenSSH developers at openssh at openssh.com. Thanks, Damien Miller, on behalf of the OpenSSH project [1] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf [2] https://www.rfc-editor.org/rfc/rfc9142.html#section-1.1 [3] https://www.rfc-editor.org/rfc/rfc4253.html#section-6.6

...uss this change further The https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev mailing list is the best place to discuss this. Alternately you can email the OpenSSH developers at openssh at openssh.com. Thanks, Damien Miller, on behalf of the OpenSSH project [1] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf [2] https://www.rfc-editor.org/rfc/rfc9142.html#section-1.1 [3] https://www.rfc-editor.org/rfc/rfc4253.html#section-6.6

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

...to 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 the case. See > > https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf > > (5.6.1 Comparable Algorithm Strengths) > > For DH, the "Comparable strengths" table lists L=3072 for 128 bits and > L=7680 for 192 bits. To me that puts 4k groups a bit above 128 bits > and well below 192 bits of security....

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

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

Hello, Sometime ago min rsa key length was increased to 1024 bit and i have a little understanding problem with this. I hope somebody with some crypto-experience can enlighten me. To make that clear, that is not about allowing lower keys in general. Personally i would tend to use even longer keys(2048bit+). However Due nature of RSA-algorithm in case of 1024bit this might result in a key

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