Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] KeePassX

> From: Derek Martin [mailto:invalid at]
> if
> the attacker knows how to factor the algorithm, or has influenced its
> development to intentionally insert known weaknessess into it, etc..
> That's the part you (I believe) keep overlooking.

Correct, but I'm not overlooking such sabotages - I'm describing how to address them explicitly.  We know the NSA has influenced some things like weakening PRNG's and so forth.  But the only ones that Snowden's leaks explicitly identified were previously discovered by the community and products already abandoned.  There are still products where weaknesses probably still reside - And there are other products where we can pretty solidly conclude they do not reside.

Weaknesses probably have been implanted into the crypto random generators in windows, linux, solaris, and mac.  (And every other kernel.)  Even where they're open source, for example the linux kernel prng that I spent a fair amount of time examining, is supremely complex and the documentation refers to itself as "magic."  They're doing stuff that makes no sense whatsoever, with no explanation.  Despite being open source, it might as well be closed.

But guess what.  That's why puttygen and truecrypt don't rely on the kernel prng for key generation.  They require you to generate your own entropy via mouse control.

In particular, the AES and SHA open competitions are widely publicized, standardized, scrutinized.  While it's virtually certain the NSA has developed techniques (kept secret of course) of reducing the number of effective bits necessary in attack - This is precisely the reason we have said if you want n bits of security, every cryptographic value should be at least 2n bits long.  If you use 256 bits key, you should plan on effective 128 bits of effort required to attack.  And yes, that's enough to keep out a hostile government.  Your weak point will be something else - Either "the hammer," or a supposed random key that's poorly selected, or a trojan backdoor in your OS or in your application.  But not the cryptography.  

You've explicitly compensated for weaknesses of the cryptography by doubling the number of bits.

BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!

Boston Linux & Unix /