[cryptography] Design Strategies for Defending against Backdoors
iang at iang.org
Mon Nov 18 02:27:30 EST 2013
In the cryptogram sent over the weekend, Bruce Schneier talks about how
to design protocols to stop backdoors. Comments?
Design Strategies for Defending against Backdoors
With these principles in mind, we can list design strategies. None of
them is foolproof, but they are all useful. I'm sure there's more; this
list isn't meant to be exhaustive, nor the final word on the topic. It's
simply a starting place for discussion. But it won't work unless
customers start demanding software with this sort of transparency.
Vendors should make their encryption code public, including the
protocol specifications. This will allow others to examine the code for
vulnerabilities. It's true we won't know for sure if the code we're
seeing is the code that's actually used in the application, but
surreptitious substitution is hard to do, forces the company to outright
lie, and increases the number of people required for the conspiracy to work.
The community should create independent compatible versions of
encryption systems, to verify they are operating properly. I envision
companies paying for these independent versions, and universities
accepting this sort of work as good practice for their students. And
yes, I know this can be very hard in practice.
There should be no master secrets. These are just too vulnerable.
All random number generators should conform to published and
accepted standards. Breaking the random number generator is the easiest
difficult-to-detect method of subverting an encryption system. A
corollary: we need better published and accepted RNG standards.
Encryption protocols should be designed so as not to leak any
random information. Nonces should be considered part of the key or
public predictable counters if possible. Again, the goal is to make it
harder to subtly leak key bits in this information.
More information about the cryptography