[Cryptography] Other obvious issues being ignored?

Henry Baker hbaker1 at pipeline.com
Mon Oct 19 13:56:31 EDT 2015


At 06:10 AM 10/19/2015, Thierry Moreau wrote:
>The recent realization that public key cryptosystems having common parameters (DH) may be vulnerable from the very fact that they rely on common parameters is puzzling to me.
>
>In hindsight, the question would have been (highly) relevant ever since the practitioner had a choice between such cryptosystems and cryptosystems having entity-specific parameters (RSA, Rabin-Williams), the latter being vulnerable to flaws or trapdoors in the parameter generation implementation for each entity.
>
>Moreover, the basic finding in the "Imperfect forward secrecy" publication
>
>(https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf)
>
>was within the reach of skilled mathematicians ever since the number field sieve algorithm could be explained in a university classroom.
>
>It's a shame that this old issue has been ignored until now!
>
>What other "obvious" questions are we ignoring?
>
>- Thierry Moreau

So-called "hardware" crypto instructions on Intel/AMD/ARM/... are dead giveaways that crypto keys are nearby.  Since the microcode on modern architectures can be changed, it can also be hacked or "backed" (as in back-doored/hack-doored), such a hack can simply log potential key material to a hidden storage area for future exfiltration.  Perhaps it is better to stay away from "hardware" crypto instructions and come up with schemes that hide SW crypto calculations as side-effects of other calculations.

The nVidia version of ARM allows for "optimizations" that take a look at the instruction stream and compile something else entirely.  The code looks right & proves out mathematically, but fails because the *compiler* changed the meaning of the instructions.

Standardized crypto schemes with standardized parameters make it too easy for NSA/NOBUS to generate attacking ASIC's.  Better to have *simple* algorithms, but with enough parameters that are simultaneously & randomly chosen to run up the combinatorial complexity of any attack.  Of course, some combinations of parameters might lead to trivial breakage, so such systems need to be understood well enough to check for & eliminate these degenerate cases.  As in the case with hashes, try to force the attacker to use lots of memory accesses.

In general, the "expert" crypto advice against "newbie crypto" with "rookie mistakes" means a far greater reliance on a handful of standardized HW & SW implementations than is otherwise healthy.  Such advice paints targets on these standardized HW/SW implementations for all NSA/NOBUS wannabes, and dramatically reduces their costs for generic surveillance.  Yes, the costs are large in terms of cores and coal, but small in terms of crypto brainpower.  Better to have multi-parameter *families* of crypto algorithms to ensure enough genetic diversity of implementations to force each break to be ad hoc/non-generalizable.  The next generation of hashes/crypto needs to force not just CPU cycles & memory accesses, but *human brain operations*.  Such systems will penalize NSA wannabes who attempt to replace quality of analysts with quantity of analysts.

A lot of water has passed under various (Euler?) bridges since the current protocols were set in silicon.  Some new protocols need to be developed that stop carrying *legacy vulnerabilities* around with them.  Just like "buffer overflows" aren't funny anymore, neither are "protocol downgrades".  Go secure or go home.

Parallelism is in decent supply these days.  How come we can't have "parametric protocols" that combine two different crypto schemes -- e.g., a prime-number-based scheme and an elliptic-curve-based-scheme -- and run them both in parallel to achieve the security of the stronger scheme (which one we don't know a priori), instead of the insecurity of the worst scheme ?  Any attacker would then have to break both schemes, or at least the harder scheme, in order to break the overall "parametric protocol".  After all, our automobiles have both hydraulic brakes and a cable-based handbrake for stopping; an attacker would have to drain the hydraulic fluid *and* cut the brake cable to keep the car from stopping.




More information about the cryptography mailing list