[cryptography] Design Strategies for Defending against Backdoors

ianG 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?

https://www.schneier.com/blog/archives/2013/10/defending_again_1.html

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 mailing list