https://bugzilla.mindrot.org/show_bug.cgi?id=2115
Darren Tucker <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Darren Tucker <[email protected]> --- (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. _______________________________________________ openssh-bugs mailing list [email protected] https://lists.mindrot.org/mailman/listinfo/openssh-bugs
