similar to: ssh-keygen -t dsa limited to 1024?

https://bugzilla.mindrot.org/show_bug.cgi?id=1647 mackyle at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mackyle at gmail.com --- Comment #2 from mackyle at gmail.com --- RFC 6668 [1] (2012-07) updated RFC 4253 adding the SHA-256 data

https://bugzilla.mindrot.org/show_bug.cgi?id=1647 mackyle at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mackyle at gmail.com --- Comment #2 from mackyle at gmail.com --- RFC 6668 [1] (2012-07) updated RFC 4253 adding the SHA-256 data

<bugzilla-daemon at mindrot.org> writes: > https://bugzilla.mindrot.org/show_bug.cgi?id=1647 > > mackyle at gmail.com changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |mackyle at gmail.com > > --- Comment #2 from

Hi, Why is there still a limit on the length of a DSA key generated by ssh-keygen? I mean that ssh-keygen only expects 1024 as key length, or fails. Here is the code excerpt that enforces the limitation: if (type == KEY_DSA && *bitsp != 1024) fatal("DSA keys must be 1024 bits"); Commenting these two lines allows the generation of, say, 2048 bit DSA keys that work just fine

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

Dear all, Ed25519 public keys being as small as they are is very convenient. There is an opportunity to nudge the world towards modern algorithms. I believe choices made in OpenSSH can positively impact the wider eco-system and industry. I'd like to suggest ssh-keygen to generate an Ed25519 keypair, if invoked without any arguments. OpenSSH has supported Ed25519 since version 6.5 (January

Hi, OpenSSH plans to remove support for DSA keys in the near future. This message describes our rationale, process and proposed timeline. Rationale --------- DSA, as specified in the SSHv2 protocol, is inherently weak - being limited to a 160 bit private key and use of the SHA1 digest. Its estimated security level is <=80 bits symmetric equivalent[1][2]. OpenSSH has disabled DSA keys by

Hi, OpenSSH plans to remove support for DSA keys in the near future. This message describes our rationale, process and proposed timeline. Rationale --------- DSA, as specified in the SSHv2 protocol, is inherently weak - being limited to a 160 bit private key and use of the SHA1 digest. Its estimated security level is <=80 bits symmetric equivalent[1][2]. OpenSSH has disabled DSA keys by

I referred to the fact that there is no value for 4096-bit groups at all. For higher strengths than 128 bits one should probably not 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

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

Hello, I had some difficulties in order to convert private keys between different implementations of SSH. So, I wrote the following patch to allow export of SSH2 RSA and DSA private keys into IETF SECSH format. Note that I also slightly revised the IETF SECSH key import code. Usage: use of the "-e" option on a private key file generates an unencrypted private key file in IETF SECSH

On Fri, Feb 17, 2017 at 09:28:52AM +1100, Darren Tucker wrote: [...] > so yeah, ssh-keygen should have probably errored out "unsupported key type". diff --git a/sshkey.c b/sshkey.c index 4768790..f45e239 100644 --- a/sshkey.c +++ b/sshkey.c @@ -89,7 +89,9 @@ static const struct keytype keytypes[] = { { "ssh-ed25519-cert-v01 at openssh.com", "ED25519-CERT",

ssh-keygen already supports importing and exporting ssh keys using various formats. The "-m PEM" which should have been the easiest to be used with various of external application expects PKCS#1 encoded key, while many applications use SubjectPublicKeyInfo encoded key. This change adds SubjectPublicKeyInfo support, to ease integration with applications. Examples: ## convert

On Wed, Feb 15, 2017 at 9:50 PM, Kelly Dunlop <kdunlop at guralp.com> wrote: > > > Hi, > > I am running openssh7.3p1 on an embedded Linux system and discovered this problem. > > If I run: > > ssh-keygen -t rsa1 -f testfile > > it appears to generate the key and I get the output: > > Generating public/private rsa1 key pair. >

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

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

https://bugzilla.mindrot.org/show_bug.cgi?id=1647 Summary: Implement FIPS 186-3 for DSA keys Product: Portable OpenSSH Version: 5.2p1 Platform: Other OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: ssh-keygen AssignedTo: unassigned-bugs at mindrot.org ReportedBy:

Hello all, I recently found myself wanting to run sshd with passphrase-protected host keys rather than the usual unencrypted format, and was somewhat surprised to discover that sshd did not support this. I'm not sure if there's any particular reason for that, but I've developed the below patch (relative to current CVS at time of writing) that implements this. It prompts for the

As you know, revoking RSA/DSA keys in an SSH environment requires editing all authorized_keys and authorized_keys2 files that reference those public keys. This is, well, difficult at best but certainly very obnoxious, particularly in a large environment. SSH key management is difficult. This patch simplifies key management wherever GSS-API/Kerberos is used and is general enough to be used with

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