http://cm.bell-labs.com/who/ken/trust.html [bell-labs.com]

There was recently a bit of a kerfuffle over RdRand [cryptome.org].

Matt Mackall, kernel hacker and Mercurial lead dev, quit Linux development two years ago because Linus insulted him repeatedly. Linus called Matt a paranoid idiot because Matt would not allow RdRand into the kernel, because it was an Intel CPU instruction for random numbers that could not be audited. Linus thought Matt's paranoia was unwarranted and wanted RdRand due to improved performance. Recently Theodore T'so has undone most of the damage, but call RdRand still exist in Linux. I do not understand exactly if there are lingering issues or not.

Even the almighty NSA with it's insanely high budget can't crack all the encryption. But it does make me wonder if I should avoid everything they recommend.

I suspect the NSA has developed custom hardware for the more common encryption types. Custom hardware was shown to work extremely well on DES by deep crack. http://en.wikipedia.org/wiki/EFF_DES_cracker [wikipedia.org]

Minor correction: They strengthened the DES algorithm by substituting a new set of S-boxes which protected against an attack that wasn't publicly known at the time. They shortened the key space which made it more susceptible to brute forcing the key. Full strength DES has held up very well against attacks overall until its key length became a problem. It lasted much longer in use than intended.

I seem to recall that DES was never approved for protecting classified data, but that AES does have that approval.

The AES was designed by Rijmen and Daemen, who are not working for the NSA (the former for a belgian university, and the other one for ST microelectronics), after a public competition. Every element of its design (which is simple) was justified. If the NSA wanted something they could break, then why not doing it themselves (that was the case of the DES).

The AES was chosen by the US government because it was apparently secure while fast and easy to implement. The academic crypto community widely considers it secure after more than 10 years of effort to break it (note that twofish does not look less secure, but what makes you think that the NSA could break the AES and not twofish ? In fact nobody can break any of them).

The point of the AES competition was to provide US companies (i.e. the public) with something secure enough against potential attacks from their competition.

All crypto algorithms have cracks for reduced round variants. Each round diffuses and mixes the state more--ideally increasing cracking difficulty exponentially.

Whether a break for N of M rounds is sufficient to lose trust in an algorithm is entirely a judgment call, and others disagree with Bruce regarding AES.

If you want to crank up the security of an algorithm, you should probably choose those from Dan Bernstein. His algorithms tend to be highly parameterized, to please both the tin foil hat crowd, as well as the hardware whiners trying to minimize the number of gates necessary.

But choosing a more widely used algorithm is more often preferable. You get the benefit of highly tuned implementations, including tuning which reduces weaknesses. It also reduces application complexity. These things are infinitely more important than the mathematics behind the algorithm, at least for the set of publicly vetted algorithms that meet a minimum standard of acceptability.

AES is _seems_ less secure than alternatives in large part because it's so visible. More academics are banging away on it. Other alternatives have received less attention, and there may be more serious, undiscovered flaws. Are there other algorithms that are better than AES? No doubt. But you're playing Russian Roulette by trying to pick them.

Don't forget that AES is derived from Serpent, which is an algorithm invented by some European academic cryptographers unaffiliated (as far as we know) from any government. Also, Bruce himself has published successor algorithms to Twofish. Why not choose one of them instead?

why do people keep suggesting to use lastpass?

Seriously!

You don't want Chrome to have acces to all your keys, but you're quite happy to fucking upload them to some server run by some random fucking mouth breather in some fucking country you don't know.

It is not easy to discover vulnerabilities through code examination.

The easy to discover problems are picked up by source management tools, LINTs and things.

Functional vulnerability in derived object code is less work-intensive, and generally returns richer results versus man-hours of investment.

Pen geniuses still "fuzz" binaries, rather than trawl millions of lines of code.

Think about how Android vulnerabilities are discovered, by Blackhat Briefing presenters. They don't usually delve into the monolithic available sources. Many vulns only make themselves evident, when combined with microcode on devices or in combination with radio stacks, etc.

Code is used to confirm findings. Sometimes. ;-)

The entire link inadvertently explains why cloud storage shouldn't be used, and that mobile devices are your worst enemy.

The only mention of TrueCrypt is this sentence:
  "Currently available for major software - Microsoft bitlocker,
  FileVault, BestCrypt, TrueCrypt, Etc" (sic)

  It does have these gems

  "The Patriot Act allows for the use of backdoors for counter terrorist investigations"

  The use of backdoors cannot be detected or proven.

  Vendors are legally and commercially prevented from acknowledging their backdoors.
  Defense will not be able to prove their existence.

  The files can be described as "forensically obtained"

Users of mobile devices and cloud storage sign off on their rights to data scanning.
There is no opt our option.

Lots more...

PDF can be downloaded here:
  http://www.techarp.com/article/LEA/Encryption_Backdoor/Computer_Forensics_for_Prosecutors_(2013)_Part_1.pdf [techarp.com]