[Cryptography] Techniques for malevolent crypto hardware

[Viktor Dukhovni]

On Sun, Sep 08, 2013 at 06:16:45PM -0400, John Kelsey wrote:

> I don't think you can do anything useful in crypto without some
> good source of random bits.  If there is a private key somewhere
> (say, used for signing, or the public DH key used alongside the
> ephemeral one), you can combine the hash of that private key into
> your PRNG state.  The result is that if your entropy source is bad,
> you get security to someone who doesn't compromise your private
> key in the future, and if your entropy source is good, you get
> security even against someone who compromises your private key in
> the future (that is, you get perfect forward secrecy).

Nice in theory of course, but in practice applications don't write
their own PRNGS.  They use whatever the SSL library provides, OpenSSL,
GnuTLS, ...  If we assume weak PRNGS in the toolkit (or crypto chip,
...) then EDH could be weaker than RSA key exchange (provided the
server's key is strong enough).

The other concern is that in practice many EDH servers offer 1024-bit
primes, even after upgrading the certificate strength to 2048-bits.

Knee-jerk reactions to very murky information may be counter-productive.
Until there are more specific details,  it is far from clear which is 
better:

    - RSA key exchange with a 2048-bit modulus.

    - EDH with (typically) 1024-bit per-site strong prime modulus

    - EDH with RFC-5114 2048-bit modulus and 256-bit "q" subgroup.

    - EECDH using secp256r1

Until there is credible information one way or the other, it may
be best to focus on things we already know make sense:

    - keep up with end-point software security patches

    - avoid already known weak crypto (RC4?)

    - Make sure VM provisioning includes initial PRNG seeding.

    - Save entropy across reboots.

    - ...

Yes PFS addresses after the fact server private key compromise,
but there is some risk that we don't know which if any of the PFS
mechanisms to trust, and implementations are not always well
engineered (see my post about GnuTLS and interoperability).

-- 
	Viktor.