[Cryptography] Back door competition for TrueCrypt fork?

Bill Cox waywardgeek at gmail.com
Mon Jun 9 09:41:08 EDT 2014


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 6/9/2014 6:18 AM, ianG wrote:
> 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

Grr... the link to describing the risk is still there, but the link to
how they defend is gone.  This link offered no help at all.

>> 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.

Good point.  Maybe just one per release cycle would be better.

> 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

I'll take your word for what US spies are trained to do.  I have no
idea!  However, with so little transparency, it is hard to know just
what public laws have been overturned by secret laws.  Is it legal to
force someone to break a contract or lie in the US for national
security purposes?  It's a good theory...

Bill
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJTlbl0AAoJEL9an3rWhBk+cMwP/2M0iAmhCBfGiAJLvaIUfNVv
RZtkma0V6auSuPHftOfS8cdISyTWfEXx2R7kQaFi8znCd2ieuXFlCviEUKARVxrZ
MlYf0gREtlu6JSZfcZ5Ac4guSVzRXWh73rC+1mqu5RD64/McdiyLsxY6e5NZ9mgt
MPZHqdANw2hBAsrI6vqTZqmSyvDHsLQv1YmuoU3iIfm5S0z29EzRLx/8puTEOO8D
Ns/1c8e1rTtz750C2+xxKKsfA1gtnHJo2vHTVaGS6xcHmboimF2h1OGN+2ZDTNAq
EBscQDuLPvkCQX4IZKs3kxyOMNGsmRZL8+H5I9RP45da0VetKyeDWslhrBGLmeHt
w2El/YqHNGLk0pbsZw42u9aYUAusqGbUyMHlRcbsiKtW+t5ehnDGIKdCmnH2R+hk
32XC9lFZKGD1Fid38RVWGAOMcLqH4H6Fj2sn8s0v2M15L4yEnqWsI0gz+kWfz9be
0XQgTAkxxEKilClddnrU1XqzZ01u4mym6mW2j2R4vwpQ9bynnzzwC8LikuD1h6sU
Ya0WxfvnUg3U4NO+Wgl/0kQ2cm1gpSYWCzXDM2RL0eA3UpEZB0jLVJ9UI+ThmmKO
nv0QkhTR8j+RlaQ15z3B7CzMS0fpWZrAwoGX/c24X3sUPZZi6q64XlOyqLPO7ZPk
jLNqgXQ6vAu+mccOQoRJ
=ASja
-----END PGP SIGNATURE-----


More information about the cryptography mailing list