Boston Linux & UNIX was originally founded in 1994 as part of The Boston Computer Society. We meet on the third Wednesday of each month at the Massachusetts Institute of Technology, in Building E51.

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] Good and Bad Crypto



Richard Pieri <richard.pieri at gmail.com> writes:

> Mike Small wrote:
>> So this is kind of what troubles me in the line this thread has taken
>> re. checking that the encryption algorithms are well chosen and
>> implemented correctly.
>
> That's why the world trusts the cryptographic module in OpenSSL: it's
> been examined and confirmed to be implemented correctly where
> "correctly" is "what FIPS 140-2 says is correct". Microsoft's
> cryptographic library has undergone the same certification so I can
> say that it is implemented correctly to the same "what FIPS 140-2 says
> is correct". The world (and I) don't have the same trust for the
> GnuTLS cryptographic module because it doesn't have that
> certification.

GnuTLS I've heard negative things about.  On the other hand PolarSSL
seems to have a good reputation, yet it's not FIPS certified.

FIPS 140-2 I'm sure is useful in certain environments (though not
environments I'd ever subject myself to) but is it the be all and end
all? e.g. do you have to wait until FIPS corrects itself before you stop
using Dual EC DRBG?

>
> Heartbleed is something else entirely. It's not a failure to implement
> an algorithm properly. It's a stupid little hack to work around slow
> malloc() calls.

Well, that they wrote their own malloc wrapper prevented memory
debuggers having any hope of helping notice the bug, but that wasn't the
direct cause of heartbleed. But yes, it has nothing to do with
cryptography. And yet that's my point. You sure want your cryptography
done right, but there's lots of stuff around it you want done well too,
stuff you don't even have to be a cryptographer to understand and see
problems in (if you can see the code and bother to look).






BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org