All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arno Wagner <arno@wagner.name>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] Truecrypt audit
Date: Fri, 16 May 2014 13:11:39 +0200	[thread overview]
Message-ID: <20140516111139.GC31000@tansi.org> (raw)

Hi all,

I just want to warn everybody not to place too great stock 
into these results. I have participated in similar, non-public
analyses and they can only ever go so deep. Cleverly hidden or
disguised backdoors may easily be overlooked, as resources are
constrained and attackers will make sure tool-support fails
by running their backdoors against the usual tools to make sure
they are not found. The same, incidentally, is done by malware
writers that check their malware against current virus scanners
before deploying them. 

What you get with the report is a code-quality assessement which
is realistic under the assumption that the implementer was
non-malicious. That in itself has value, but it is a different
kind of statement than people may assume when looking at the
report. 

So what do do if you want to be sure security software you 
use has no backdoors? By now I am convinced that the only
cost-effective way is to have highly competent and careful 
people you trust implement it for you. Sure, that is expensive,
but there are good reasons to believe that an analysis that
has a good chance of finding most or all backdoors is a lot 
more effort and in addition requires a higher level of skill,
making it orders of magnitide more expensive.

The following quote is even more true for security aspects:

  "Debugging is twice as hard as writing the code in the first place.
   Therefore, if you write the code as cleverly as possible, you are,
   by definition, not smart enough to debug it." - Brian W. Kernighan

The only way to get the simplicity you need to be sure there
are no backdoors is to enforce it by writing it yourself.

Yes, I know that is far from ideal but it is how the
situation presents itself to me.

Arno



On Fri, May 16, 2014 at 07:02:57 CEST, Heinz Diehl wrote:
> Hi,
> 
> because cryptsetup is supporting truecrypt, I thought this one could
> be of interest:
> 
> http://tinyurl.com/n8z4tcu
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -  Plato

             reply	other threads:[~2014-05-16 11:11 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-16 11:11 Arno Wagner [this message]
2014-05-16 14:40 ` [dm-crypt] Truecrypt audit Chris Drake
2014-05-16 17:23   ` Arno Wagner
2014-05-17  7:08 ` Heinz Diehl
2014-05-17 11:42   ` Arno Wagner
  -- strict thread matches above, loose matches on Subject: below --
2014-05-16  5:02 Heinz Diehl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140516111139.GC31000@tansi.org \
    --to=arno@wagner.name \
    --cc=dm-crypt@saout.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.