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 | Linux Links | Bling | About BLU

BLU Discuss list archive


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

[Discuss] TrueCrypt with SSD



> From: discuss-bounces+blu=nedharvey.com at blu.org [mailto:discuss-
> bounces+blu=nedharvey.com at blu.org] On Behalf Of Brendan Kidwell
> 
> I'd say the same thing as you: what the point of spending all those CPU
> cycles if the data is effectively not encrypted?!

CPU cycles irrelevant.
First of all, when encrypting/decrypting my laptop HDD at sustained full
speed, CPU usage only goes up to 30% of a single core.  Second of all, if
you have a modern processor (i7) that includes the AES instruction set, it's
1-2 orders magnitude CPU performance enhancement, which means undetectable
additional load on the CPU to sustain all the encryption.  0.3% to 3%
maximum CPU load.

But yeah.  A few days maximum to brute force the 6-character password.  

And I don't buy the arguments a few people made - About the attack vector
being other than brute force and therefore brute force doesn't matter.   If
somebody laptop is lost or stolen, there is no guarantee it'll be powered on
at the time, which means there's no guarantee of *any* attack vector except
brute force.  And that includes brute force of the hammer & water bucket
sort, on the person who knows the password.

I understand the aversion to typing a long difficult password at boot time.
That's why they made things like the TPM, and key fobs and smart cards.  So
you can have strong encryption without the hassle.




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 / webmaster@blu.org