openssh bugs - Nov 2005 - [Bug 1119] Enhancement request for raising minimum acceptable key length.

http://bugzilla.mindrot.org/show_bug.cgi?id=1119

           Summary: Enhancement request for raising minimum acceptable key
                    length.
           Product: Portable OpenSSH
           Version: 4.2p1
          Platform: Other
               URL: http://www.rsasecurity.com/press_release.asp?doc_id=488&
                    id=1034
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: ssh-keygen
        AssignedTo: bitbucket at mindrot.org
        ReportedBy: senthilkumar_sen at hotpop.com


The minimum key length recommended for RSA at the specified URL is 768. This is
an enhancement request to raise the minimum level of key length from 512 to 768
in ssh-keygen. I will attach the patch for this enhancement




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1119





------- Comment #1 from senthilkumar_sen at hotpop.com  2005-11-23 17:18 -------
Created an attachment (id=1031)
 --> (http://bugzilla.mindrot.org/attachment.cgi?id=1031&action=view)
Patch to update the minimum keylength bits to 1024

I received an input from Tom, the author of libtomcrypt
(http://libtomcrypt.org/) that minimum recommended key length is 1024 in
general. So the patch is modified from the description of enhancement request
#1, so that it checks for atleast 1024 bits.




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1119


dtucker at zip.com.au changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
OtherBugsDependingO|                            |1047
              nThis|                            |
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




------- Comment #2 from dtucker at zip.com.au  2005-11-28 16:25 -------
As a compromise we increased the minimum RSA key size to 768 bits so it's
still
usable on older/slower machines.

We have also enforced a DSA key size of exactly 1024 bits since that's
apparently what FIPS 186-2 specifies (and the SSH protocol specs reference that
for the DSA definition).

Thanks.




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1119


t8m at centrum.cz changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |t8m at centrum.cz




------- Comment #3 from t8m at centrum.cz  2005-11-28 22:02 -------
Well the FIPS may specify 1024 bits for DSA but is there any reason besides the
FIPS why larger DSA keys should not be used? Are they less secure (probably
not).
Maybe issuing a warning instead of fatal() would be much more appropriate.




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1119





------- Comment #4 from dtucker at zip.com.au  2005-11-28 22:15 -------
(In reply to comment #3)
> Well the FIPS may specify 1024 bits for DSA but is there any reason besides
the
> FIPS why larger DSA keys should not be used? Are they less secure (probably
> not).
They're not less secure, but they're apparently not (much?) more secure.
The
security is apparently limited by the 160 bit subgroup that's part of the
public key, and the use of SHA1 (again, 160 bits).

So there's no real security gain, and the larger keys can confuse other
implementations which do adhere strictly to the spec.  If you want big keys,
use RSA.




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.