Hi Chris, On Fri, May 16, 2014 at 16:40:56 CEST, Chris Drake wrote: > Hi Arno, > > I would go even a step further. Since we know Truecrypt is popular, > and America alone spends $50billion+ annually to get 50,000+ of the > worlds smartest people to ensure they have back-door access to as much > as possible, I'd go so far as to say that some kind of back door is a > certainty. Honestly, I am not sure. I think it is possible that there are no backdoors (i.e. placed vulnerabilities). I am sure, however, that some accidental vulnerabilities (i.e. mistakes) are known. And then there are all these attempts to sabotage random number generation, e.g. by that EC generator and by RDRAND. If you have bad random numbers, the actual crypto does not need to be sabotaged anymore. > Hiding cunning back doors in source code is one of the most > interestingly compelling intellectual tasks you could ever dream to > work on. Lots of countries spend lots of money hiring lots of very > smart people to do just that... (and, just one example, the source > uses /dev/random - the current worlds-most-famous-place for hiding > backdoors; yet they didn't care to dive into the kernel code behind > that, not that doing so is even possible on closed-source windows > platforms...) Indeed. Own the CPRNG, and you own basically everything. However, I think that FOSS software has few or no insertred backdoors. What I do believe is that there may be some inserted incompetent people (the systemd-leaders come to mind) that produce plenty of vulnerabilities and those nobody else finds are by definition well hidden. A similar angle may bepresent by efforts to make crypto harder to get right, for example with IPSec. Just make it complex and non-KISS enough, and those 50'000+ bright people you mention _will_ find something. > The very start of the analysis reports that they didn't attempt to > build the binary we all use, from the source they examined. That's > pretty much as far as you need to read :-( Actually not. Some people already did that and posted hashes. I really do not think there is a problem from this angle. The thing you need to keep in mind is that they need to hide their information assets (i.e. vulnerabilities they know) well, or they will lose them. And these better intel they get, the less they can actually do with it, because every use risks exposing the source. That was the whole reason for the "parallell construction" (i.e. lying to the judge and jury under oath) used by law enforcement when they got tips from the NSA about drug and other activities: They committed perjury to protect their source. These things can only go so far, at some point correclations become obvious. Anyways, thanks for your thoughts! Arno > Kind Regards, > Chris Drake > > > Friday, May 16, 2014, 9:11:39 PM, you wrote: > > AW> Hi all, > > AW> I just want to warn everybody not to place too great stock > AW> into these results. I have participated in similar, non-public > AW> analyses and they can only ever go so deep. Cleverly hidden or > AW> disguised backdoors may easily be overlooked, as resources are > AW> constrained and attackers will make sure tool-support fails > AW> by running their backdoors against the usual tools to make sure > AW> they are not found. The same, incidentally, is done by malware > AW> writers that check their malware against current virus scanners > AW> before deploying them. > > AW> What you get with the report is a code-quality assessement which > AW> is realistic under the assumption that the implementer was > AW> non-malicious. That in itself has value, but it is a different > AW> kind of statement than people may assume when looking at the > AW> report. > > AW> So what do do if you want to be sure security software you > AW> use has no backdoors? By now I am convinced that the only > AW> cost-effective way is to have highly competent and careful > AW> people you trust implement it for you. Sure, that is expensive, > AW> but there are good reasons to believe that an analysis that > AW> has a good chance of finding most or all backdoors is a lot > AW> more effort and in addition requires a higher level of skill, > AW> making it orders of magnitide more expensive. > > AW> The following quote is even more true for security aspects: > > AW> "Debugging is twice as hard as writing the code in the first place. > AW> Therefore, if you write the code as cleverly as possible, you are, > AW> by definition, not smart enough to debug it." - Brian W. Kernighan > > AW> The only way to get the simplicity you need to be sure there > AW> are no backdoors is to enforce it by writing it yourself. > > AW> Yes, I know that is far from ideal but it is how the > AW> situation presents itself to me. > > AW> Arno > > > > AW> 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@xxxxxxxx > >> http://www.saout.de/mailman/listinfo/dm-crypt > > > > > _______________________________________________ > dm-crypt mailing list > dm-crypt@xxxxxxxx > http://www.saout.de/mailman/listinfo/dm-crypt -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx 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 _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
