[Cryptography] Back door competition for TrueCrypt fork?

ianG iang at iang.org
Mon Jun 9 06:18:37 EDT 2014


On 6/06/2014 13:46 pm, Bill Cox wrote:

> I really am paranoid.  As another poster said, "My paranoia goes to
> 11."  We may already have an NSA plant on this list.  How can we succeed
> while working with an NSA plant?  If he's good, he may create really
> difficult to detect back doors, and even if we find them, they will look
> like innocent mistakes.  Is there any defense?  The only way I can think
> of is diligent code review.  How can we tell if we're doing a good job?


As an alternate idea, CAcert has a process for addressing the risk of
secret cells, amongst others.  http://wiki.cacert.org/Risks/SecretCells


> I think it might be a lot of fun to see which of us can succeed in
> inserting a back door without the others noticing.  Every week each
> developer (core developer?) would publish a warrant canary containing an
> encrypted code snippet, as well as the key to the prior week's code
> snippet.  The code snippets would either say "No back doors were
> inserted this week", or show exactly where the back door is with an
> explanation.
> 
> Any time one of us finds a back door, we should raise the alarm.  The
> person responsible for the back door should then reveal the decryption
> key, proving to us that he had planned to reveal it next week anyway.
> 
> Whenever one of us gets away with an undetected back door, the next week
> everyone would know about it (and obviously remove it).  We could call
> that "winning", and having our back door detected "losing", and even
> keep tallies of wins and losses.


The issue I would see is that it is very hard to write a backdoor.  The
adversary manages to do it because that's all he is interested in, and
he is paid to do it.  You however are interested in writing clean code;
 time spent on a backdoor is time not spent on writing new clean code.

Above you are asking for a backdoor ever week :)  That seems way too
much load.

What devs could do is to write and escrow a disclosure file that could
be empty, or could have a backdoor documented in it.  Then, at some
agreed time such as one month before release, all of these could be
opened up and any undetected backdoors cleaned out.

In the disclosure file there should be a statement words to effect "this
file contains the only back doors known to this developer, the code
written contains the best efforts at user security."

It is useful to get a legally binding statement in place.  This will
block the attempts of most surreptitious plants.  It won't block the
downright criminal, but your own country's spies are generally trained
not to do things that will land them in their courts, especially if
those things might be illegal.



iang



More information about the cryptography mailing list