7:12 p.m.
Interesting link : http://en.wikipedia.org/wiki/Dual_EC_DRBG
It talks about the pros and cons of Dual_EC_DRBG which seems at best to be
not very good random, at worst picked because it makes the sequence surface
predictable, especially with a known secret key.. "possibility of the
existence of a known secret key, which facilitates solution of the problem"
and especially in light of : http://en.wikipedia.org/wiki/Key_disclosure_law
which by law requires people in the USA to give up said secret keys.
I guess it's fair enough in the USA where cryptographic freedom is given up
to the government by federal legislation, but in other parts of the world
this standard looks pretty terrible, as it is including this as a known or
at least suspected attack vector. In other countries you need to hand over
encryption keys, it usually needs a court order or some sort of evidence..
and in another country it seems silly to potentially facilitate another
country's inspection of your secure traffic.
On Sun, Oct 27, 2013 at 4:45 AM, Howard Chu <hyc(a)symas.com> wrote:
devzero2000 wrote:
> On Fri, Oct 25, 2013 at 7:59 PM, Michael Ströder <michael(a)stroeder.com>
> wrote:
>
>> Steve Eckmann wrote:
>>
>>> We are using {SSHA} (SHA-1) in OpenLDAP now. The customer wants SHA-512.
>>> And they require a FIPS-validated implementation, which I think narrows
>>> our
>>> options to using either OpenSSL or NSS in FIPS mode. I cannot see a
>>> better
>>> way to meet the customer's two requirements than gutting pw-sha2 and
>>> using
>>> that as a thin wrapper for the raw crypto functions in either openssl or
>>> nss.
>>>
>>
>> You probably should first ask on the openssl-users mailing list under
>> which
>> conditions you get some "FIPS-validated" code regarding the whole
>> OpenLDAP
>> "application". Likely it's not feasible.
>>
>> I'm pretty sure that your customer FIPS requirement is plain nonsense
>> and you
>> might work around this by some other strange policy text. ;-}
>>
> I am not sure "nonsense" if some distro are doing something in this
> area. Right or,
> perhaps, sometime wrong (o perhaps sometime break).
>
http://fedoraproject.org/wiki/**FedoraCryptoConsolidation<http://fedor...
>
FIPS spec is clearly nonsense, from a technical perspective. E.g. it
required support of Dual_EC_DRBG random number generator which was proven
to be inferior and almost certainly has an NSA backdoor.
The Fedora crypto consolidation rationale is completely bogus; in unifying
the crypto database across the entire machine it fails to recognize that
different services (and different clients) will have completely different
security policies and requirements. Of course this is common knowledge for
actual security practitioners - servers generally should only recognize and
trust client certificates issued by a single CA, while clients generally
need to be able to trust many different CAs for a wide range of services.
HTTP servers have much different certificate requirements from
LDAP/FTP/SMTP servers; almost nobody uses client certificates with HTTP but
they are commonplace for many other authenticated services.
Of course, the Fedora crypto scene is dictated more by political concerns
than technical.
https://bugzilla.redhat.com/**show_bug.cgi?id=319901<https://bugzilla....
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP
http://www.openldap.org/**project/<http://www.openldap.org/project/>
--
Whenever you find yourself on the side of the majority, it is time to pause
and reflect.
- Mark Twain