[Discuss] Good and Bad Crypto

[Edward Ned Harvey (blu)]

> From: discuss-bounces+blu=nedharvey.com at blu.org [mailto:discuss-
> bounces+blu=nedharvey.com at blu.org] On Behalf Of Tom Metro
> 
> Being open source [...]. It's
> is merely a necessary precondition for determining that crypto is
> trustworthy.

Sorry, but this statement is simply false.

Tell me the difference between the AesManaged class library, when I run it under closed-source .NET, and when I run it under open-source mono?  There is literally no difference.  It's a standard, deterministic library with literally the exact same binary output given the same input.  Closed or open is irrelevant, because the behavior is standard, published, verifiable, deterministic.

The characteristic that differentiates good crypto from bad crypto is not whether the source is open or closed - it's whether the standards are strong, and whether the libraries are used correctly.

All you have to do, with closed source, to demonstrate that you're doing good crypto, is to publish a whitepaper describing the standards you use, and how you use them, and how somebody can verify that their data has been encrypted as described.


> Using a proprietary library that implements an open *standard* is way
> better than one where the developer decided to roll his own crypto
> algorithm.

Nobody rolls his own crypto algorithm.  And I mean nobody.

Everybody, and I mean everybody, uses a standard library implementation of an open standard.


> If you want crypto quality random numbers that the NSA can't monkey
> with, use a hardware random number generator. Google and you'll find
> lots of options.

First, every system has hardware random sources.  If you want to sample hardware random yourself, free of NSA monkeying, you can.  Many applications ask you to move your mouse around, type random characters for a minute, etc.  In addition to this, crypto rngs source from hard drive timings, ethernet timings, etc.

Second, a hardware crypto random generator such as TPM is just a black box executing some crypto functions such as standard prng, exactly as your kernel does.  Which means it's *equally* subject to NSA monkeying.  Yes, there do exist quantum hardware random generators, but if that's what you seek, you have to specifically search for it, specifically.

As I said, the right way to ensure strong crypto random is to show distrust for them all, and mix multiple sources.  As long as any of them is random, then the bastardized other ones are irrelevant.  


> Then there is Steve Gibson's SQRL approach to this;
> https://www.grc.com/sqrl/sqrl.htm

Yup.  I read about sqrl.  It's equally as good as a randomized password keychain system, because it requires you to carry something secret to yourself and synchronize with yourself across any multiple devices you may use.

If you instead don't assume the user always carries their secret wallet...  Take it for granted, that there exists a server/client model, and the client has a secret that only was communicated from client device A to client device B by storing in the user's brain, and the secret needs to be verified without exposing the secret, then the asymmetric solution I've described becomes a natural conclusion.  I can see the biometric solution as being an alternative...