| Summary: | Implement FIPS 186-3 for DSA keys | ||
|---|---|---|---|
| Product: | Portable OpenSSH | Reporter: | Fabio A. Correa <facorread> |
| Component: | ssh-keygen | Assignee: | Assigned to nobody <unassigned-bugs> |
| Status: | CLOSED WONTFIX | ||
| Severity: | enhancement | CC: | djm, dtucker, mackyle, pcerny |
| Priority: | P2 | ||
| Version: | 5.2p1 | ||
| Hardware: | Other | ||
| OS: | All | ||
|
Description
Fabio A. Correa
2009-09-06 09:22:37 AEST
It's not as simple as just increasing the allowable key size.
look in FIPS-186-3 section 4.2 where it mandates the hash lengths for the various DSA key sizes:
L = 1024, N = 160
L = 2048, N = 224
L = 2048, N = 256
L = 3072, N = 256
Now look at RFC4253 section 6.6 where it defines the ssh-dss authentication type as:
"Digital Signature Standard [FIPS-186-2] using the SHA-1 hash"
SHA-1 is 160 bits and is mandated by RFC 4253, thus the only way to be compliant with both it and FIPS-186-{2,3} is to allow only 1024 bit keys (which is what ssh-keygen does right now).
There was some discussion about this on the ietf working group about defining a new authentication method (http://thread.gmane.org/gmane.ietf.secsh/6186/focus=6193) but AFAIK it never went anywhere.
RFC 6668 [1] (2012-07) updated RFC 4253 adding the SHA-256 data integrity algorithm as a new recommended algorithm. FIPS 186-4 [2] (2013-07) section 4.2 includes the same DSA parameters as FIPS 186-3: L = 1024, N = 160 L = 2048, N = 224 L = 2048, N = 256 L = 3072, N = 256 And it would seem that the L=2048,N=256 L=3072,N=256 selections are now possible while remaining standards compliant. It appears that OpenSSH has added support for SHA-256 and SHA-512 in version 5.9p1 (2011-09). [1] http://tools.ietf.org/html/rfc6668 [2] http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf (In reply to mackyle from comment #2) > RFC 6668 [1] (2012-07) updated RFC 4253 adding the SHA-256 data > integrity algorithm as a new recommended algorithm. > > FIPS 186-4 [2] (2013-07) section 4.2 includes the same DSA > parameters as FIPS 186-3: > > L = 1024, N = 160 > L = 2048, N = 224 > L = 2048, N = 256 > L = 3072, N = 256 > > And it would seem that the L=2048,N=256 L=3072,N=256 selections are > now possible while remaining standards compliant. RFC 6668 adds a new HMAC (ie integrity) algorithm (RFC 4253 section 6.4) not a public key (ie authentication) algorithm (RFC 4253 section 6.6). OpenSSH does in fact implement RFC 6668 (run ssh -vvv and look at the MACS offered) but it doesn't change the situation with DSA authentication. We're not interested in implementing support for DSA with larger keys, because DSA still suffers catastrophic failure when its nonce isn't random. We're instead pushing to deprecate DSA entriely - recent versions no longer offer or accept it by default. Close all resolved bugs after 7.3p1 release |