openssh bugs - Jun 2013 - [Bug 2115] New: Support for DSA p=2048 q=256/224 bit keys

https://bugzilla.mindrot.org/show_bug.cgi?id=2115

            Bug ID: 2115
           Summary: Support for DSA p=2048 q=256/224 bit keys
           Product: Portable OpenSSH
           Version: 6.1p1
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: ssh-keygen
          Assignee: unassigned-bugs at mindrot.org
          Reporter: dhanukumar1990 at gmail.com

Created attachment 2292
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2292&action=edit
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

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2115

Cipher <dhanukumar1990 at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dhanukumar1990 at gmail.com
                URL|                            |openssh at openssh.com

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2115

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org
                URL|openssh at openssh.com         |

--- Comment #1 from Damien Miller <djm at mindrot.org> ---
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.

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

https://bugzilla.mindrot.org/show_bug.cgi?id=2115

--- Comment #2 from Cipher <dhanukumar1990 at gmail.com> ---
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.

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

> --- Comment #2 from Cipher <dhanukumar1990 at gmail.com> ---
> 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? 
NIST SP 800-131A also mandates you would need to use SHA2-256 instead of
SHA-1 for public key signature verification to meet FIPS 140-2/3
requirements.

Given ssh-dss in RFC 4253 specifies ssh-dss format as

|   ssh-dss           REQUIRED     sign   Raw DSS Key
|   ...
|   Signing and verifying using this key format is done according to the
|   Digital Signature Standard [FIPS-186-2] using the SHA-1 hash
|   [FIPS-180-2].
|
|   The resulting signature is encoded as follows:
|
|      string    "ssh-dss"
|      string    dss_signature_blob
|
|   The value for 'dss_signature_blob' is encoded as a string containing
|   r, followed by s (which are 160-bit integers, without lengths or
|   padding, unsigned, and in network byte order).

It is the 160-bit SHA-1 hash that is your real problem.

The openssh-unix-dev list has a suggestion for adding ssh-rsa-sha256 and
ssh-dss-sha256 

I believe this has been filed as Bug 2109 by Geoff Lowe.

I therefore suggest that Bug 2115 is not a sufficient representation of
your issue and that you would also need to see Bug 2109 addressed as
well.

	-- Mark

https://bugzilla.mindrot.org/show_bug.cgi?id=2115

Darren Tucker <dtucker at zip.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtucker at zip.com.au
             Status|NEW                         |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #3 from Darren Tucker <dtucker at zip.com.au> ---
(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 ***

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

https://bugzilla.mindrot.org/show_bug.cgi?id=2115

--- Comment #4 from Darren Tucker <dtucker at zip.com.au> ---
See also the followup to the mailing list from Mark Baushke:

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

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

https://bugzilla.mindrot.org/show_bug.cgi?id=2115

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #5 from Damien Miller <djm at mindrot.org> ---
Close all resolved bugs after 7.3p1 release

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.