Bug 2115

Summary:

Support for DSA p=2048 q=256/224 bit keys

Product:

Portable OpenSSH

Reporter:

Cipher <dhanukumar1990>

Component:

ssh-keygen

Assignee:

Assigned to nobody <unassigned-bugs>

Status:

CLOSED DUPLICATE

Severity:

enhancement

CC:

dhanukumar1990, djm, dtucker

Priority:

Version:

6.1p1

Hardware:

All

OS:

All

Attachments:

Description	Flags
sshd debug mode-connection failure with bad sig size error while using 2048 bit DSA keys	none

Description Cipher 2013-06-03 17:49:32 AEST

Created attachment 2292 [details]
sshd debug mode-connection failure with bad sig size error while using 2048 bit DSA keys

ssh-dss.c in openssh 6.1p1 limits sig parts to 20 bytes (matching a SHA1 hash), consistent with RFC 4253 6.6 which specifies SHA1 and 160-bit (20-byte).
Whereas openssl starting from 1.0.0 creates DSA 2048 bit keys with q=256(SHA2) incompatible with openssh which validates against q=160(SHA1 hash).

Using openssl version 0.9.8 or less solves the issue since it generates DSA 2048 keys with q=160, but there is no security benefit since SP800-57 rates DSA=2048/160 as 80 bit strength which is less than the nom 112 bits.

For more info: http://openssl.6102.n7.nabble.com/openssl-1-0-1e-bad-sig-size-32-32-for-DSA-2048-keys-tc45189.html#a45246

Comment 1 Damien Miller 2013-06-03 18:51:25 AEST

Right, we don't support DSA keys with q!=160 because the SSH protocol isn't specified for them. We also refuse to generate DSA keys with bit lengths other than 1024 for this reason. Are you generating your keys using openssl directly?

Changing this will require a protocol extension and the keys used will be called something other than "ssh-dss". I'm not sure whether it is worth it, since we support ECDSA modes that are faster and more secure.

Comment 2 Cipher 2013-06-05 15:44:18 AEST

Thanks Damien.

Yes we were creating the keys using openssl and also using ssh-keygen(After removing 1024 bit limit gate in the code).
One of our third party applications support only DSA keys, so we cant use ECDSA. FIPS 140-2/3 requires 2048 with q=224/256. So how difficult it will be and how much sense will it make to change ssh-dss to use 32 byte seg parts? 

Thanks.

Comment 3 Darren Tucker 2013-06-06 00:28:40 AEST

(In reply to Cipher from comment #2)
> Thanks Damien.
> 
> Yes we were creating the keys using openssl and also using
> ssh-keygen(After removing 1024 bit limit gate in the code).

If you're hacking ssh-keygen or generating keys by hand then you're on you're own, but what you're doing is almost certainly not compliant with FIPS 140-3.

Short of the new key exchange methods (ie the enhancement request in bug #2109) the only way to comply with both rfc4253 (which requires sha1) and FIPS 140-3 (which says sha1 is permissible for key lengths of exactly 1024 bits) is to allow dsa keys of only 1024 bits, which is what ssh-keygen does. See the discussion in bug #1647.

> One of our third party applications support only DSA keys, so we
> cant use ECDSA. FIPS 140-2/3 requires 2048 with q=224/256. So how
> difficult it will be and how much sense will it make to change
> ssh-dss to use 32 byte seg parts? 

it makes no sense since ssh-dss specifically requires sha1.

*** This bug has been marked as a duplicate of bug 2109 ***

Comment 4 Darren Tucker 2013-06-06 00:30:46 AEST

See also the followup to the mailing list from Mark Baushke:

http://lists.mindrot.org/pipermail/openssh-unix-dev/2013-June/031432.html

Comment 5 Damien Miller 2016-08-02 10:40:36 AEST

Close all resolved bugs after 7.3p1 release