similar to: [patch] ssh-keygen(1): generate Ed25519 keys when invoked without arguments

Greetings! According to documentation, "-x" and "-X" options of ssh-keygen designed to work only with DSA keys. It means that key_type_name variable have to be initialized to "dsa" if any of these options were specified. Regards, Dmitry +-------------------------------------------------------------------------+ Dmitry V. Levin mailto://ldv at fandra.org

On 9/4/23 16:43, Joseph S. Testa II wrote: > I very often see IT personnel and developers simply use the default > options for ssh-keygen. They just don't care/don't know to care. > Switching the default to ED25519 would bring the equivalent security > up from 112-bits to 128-bits (as 2048-bit RSA is equivalent to 112-bits > of symmetric strength), which would be a nice

What I'm hearing in this thread is: "a minority of people on planet Earth have a problem with the open-source implementation of ED25519, but instead of letting that minority choose to re-implement it when/if they want to, the rest of the community needs to stall their progress in improving security." And isn't the ED25519 code is already there on their machine? So isn't

Hi, I needed to convert a public RSA key to autorized_keys format and found ssh-keygen lacking this feature. I made the option -Q publicfile to allow an conversion like ssh-keygen -Q pubrsa.pem -y The patch is produced using unified diff and made on latest release. If you like it and can make a patch for the man-page also! Regards, /Lars -------------- next part -------------- diff -u

On 10/18/18 4:14 PM, Johnny Hughes wrote: > On 10/18/2018 12:36 PM, Walter H. wrote: >> On 18.10.2018 00:08, Johnny Hughes wrote: >>> The bottom line .. we don't make the decision whether or not to use >>> systemd or not.? We rebuild RHEL source code. >> will there come a CentOS 6.11 which will be capable of TLS1.3 or HTTP/2? >> I'm sure there will

On 10/18/18 11:06 PM, Barry Brimer wrote: > > > On Thu, 18 Oct 2018, Robert Moskowitz wrote: > >> >> >> On 10/18/18 4:14 PM, Johnny Hughes wrote: >>> On 10/18/2018 12:36 PM, Walter H. wrote: >>>> On 18.10.2018 00:08, Johnny Hughes wrote: >>>>> The bottom line .. we don't make the decision whether or not to use

Hello. Subramanian Moonesamy has gotten the ball rolling to include Ed25519 in IANA's registry for SSHFP key types [1]. I've opened a bug report [2] that includes a patch that adds the needed support code and provisionally assigns Ed25519 a value of 4 (values 1,2,3 reserved for RSA, DSA, and ECDA, respectively) [3]. The enhancement request/bug is meant to keep the issue on the radar.

Hi All, I've been working on a diff to get SSHFP support for ed25519 in OpenSSH. SM has been working through the IETF process to obtain the SSHFP RR Type number. Despite getting "rough consensus", we still haven't heard anything from the IETF Security Directors for the draft. SM sent a mail asking why it is taking so long, and it appears that his mail was ignored. Please see:

Hello, Maybe I'm asking an already answered question, if yes I'm sorry to bother you. Why in default HostKeyAlgorithms settings is ecdsa-sha2-nistp256-cert-v01 at openssh.com preferred over ssh-ed25519-cert-v01 at openssh.com ? For example in default settings for KexAlgorithms the curve25519-sha256 at libssh.org is preferred over ecdh-sha2-nistp256. Fedor Defaults in openssh-6.6p1

https://bugzilla.mindrot.org/show_bug.cgi?id=2179 Bug ID: 2179 Summary: ed25519 make install support Product: Portable OpenSSH Version: -current Hardware: All OS: All Status: NEW Severity: normal Priority: P5 Component: Build system Assignee: unassigned-bugs at mindrot.org

https://bugzilla.mindrot.org/show_bug.cgi?id=2215 Bug ID: 2215 Summary: Key fingerprint headline slightly broken with ED25519 Product: Portable OpenSSH Version: 6.5p1 Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 Component: ssh Assignee: unassigned-bugs at

https://bugzilla.mindrot.org/show_bug.cgi?id=2586 Damien Miller <djm at mindrot.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |WONTFIX CC|

https://bugzilla.mindrot.org/show_bug.cgi?id=2586 Damien Miller <djm at mindrot.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #2 from Damien Miller <djm at mindrot.org> --- Close all resolved bugs after 7.3p1 release

On Tue, Jan 26, 2016 at 07:35:10PM +0100, Anton Voyl wrote: > Is it possible to sign/verify data with the ed25519 keys of a tinc 1.1 host? In principle yes, but tinc does not offer a way to do that. Also, reusing a key for another purpose is not recommended. What do you want to do exactly? > More specifically, is it possible to sign a file with these keys using openssl? If so, how? If

On Tue, Jan 26, 2016 at 08:35:15PM +0100, Anton Voyl wrote: > My intention was to sign the content of export-all with the nodes' public key, which would require the corresponding private key to verify. > > Does this make sense ? Yes, that does make a lot of sense. I'll see if I can add a safe way to sign/verify arbitrary data with the tinc command. -- Met vriendelijke groet /

https://bugzilla.mindrot.org/show_bug.cgi?id=3725 Bug ID: 3725 Summary: Unclear error when configuring 'ed25519' as HostKeyAlgorithms Product: Portable OpenSSH Version: 9.8p1 Hardware: amd64 OS: Linux Status: NEW Severity: enhancement Priority: P5 Component:

https://bugzilla.mindrot.org/show_bug.cgi?id=2223 Bug ID: 2223 Summary: Ed25519 support in SSHFP DNS resource records Product: Portable OpenSSH Version: -current Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 Component: ssh Assignee: unassigned-bugs at

On Tue, Jan 26, 2016 at 08:52:29PM +0100, Guus Sliepen wrote: > > My intention was to sign the content of export-all with the nodes' public key, which would require the corresponding private key to verify. > > > > Does this make sense ? > > Yes, that does make a lot of sense. I'll see if I can add a safe way to > sign/verify arbitrary data with the tinc

Hello, Is it possible to sign/verify data with the ed25519 keys of a tinc 1.1 host? More specifically, is it possible to sign a file with these keys using openssl? If so, how? If not, what program could be used, and how? Thanks and cheers, @

https://bugzilla.mindrot.org/show_bug.cgi?id=2271 Bug ID: 2271 Summary: Regression test #89 "fuzz Ed25519 sig" fails under Solaris Product: Portable OpenSSH Version: 6.6p1 Hardware: All OS: Solaris Status: NEW Severity: normal Priority: P5 Component: