[Bug 1647] Implement FIPS 186-3 for DSA keys

[Mark D. Baushke]

<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 mackyle at gmail.com ---
> 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.

SHA-1 is not allowed in digital signatures per NIST SP 800-131A after
December 31, 2013.

The problem is in the way that ssh-dss is specified in RFC 4253 to use a
SHA-1 hash in the dss_signature_blob. The same problems exist for
x509v3-ssh-dss which also specifies the use of SHA-1. 

In order to use a DSA-2048 or DSA-3072 with SHA-256 or SHA-512, one
would likely need to move to the pgp-sign-dss public key algorithm of
RFC2440 as obsoleted by RFC 4880 section 13.6 which allows for

 L=1024, N=160 [not useful given NIST SP 800-131A]
 L=2048, N=224 with SHA-224, SHA-256, SHA-384, or SHA-512 hash
 L=2048, N=256 with SHA-256, SHA-384, or SHA-512 hash
 L=3072, N=256 with SHA-256, SHA-384, or SHA-512 hash

I am not aware of any pgp-sign-dss implementations that implement the
RFC 4880 updated types, but you could use it if you wished.

Other alternatives would mean writing another RFC to deal with a new
public key algorithm name or set of names to handle the key sizes and
hash algorithms you want to allow.

> 
> It appears that OpenSSH has added support for SHA-256 and SHA-512 in
> version 5.9p1 (2011-09).

RFC 6668 is good if you want to use something like the Cipher aes128-cbc
with hmac-sha2-256 or hmac-sha2-512 as the MAC instead of implementing
AEAD_AES_128_GCM or AEAD_AES_256_GCM.

The way that RFC 5647 is written makes it hard to do the right thing
when the Cipher and Macs are negotiated separately as both have to agree
and having one of the AEAD_* ciphers with some other MAC just makes no
sense, but has no provision for forcing the two to be sane during
negotiations.

The OpenSSH community implemented aes128-gcm at openssh.com and
aes256-gcm at openssh.com with specified semantics during negotiation to
ensure that a non-toxic selection is made and otherwise uses the RFC
5647 wire protocol for the traffic.

> 
> [1] http://tools.ietf.org/html/rfc6668
> [2] http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf
> 
> -- 
> 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.
> _______________________________________________
> openssh-bugs mailing list
> openssh-bugs at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-bugs