search for: nvlpub

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

...= 2048, N = 256 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.

...= 2048, N = 256 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.

...A choices from FIPS 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.)

...wishes, and falls 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>.

...SH community implemented 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 > opens...

...fore OpenBSD 7.4 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-keyg...

...* I want to discuss 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 want to discuss 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

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

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

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