Discussion:
[lopsa-tech] Bitlocker vs Truecrypt
(too old to reply)
Edward Ned Harvey (lopser)
2013-06-28 11:42:39 UTC
Permalink
For the last few years, I've been a fan of deploying Bitlocker, largely because I was so impressed with its ease of use and overall performance. Recently, I accidentally bought Win7 Pro, which doesn't have bitlocker, and decided to figure out Truecrypt whole disk encryption rather than paying for the Windows upgrade or exchanging the laptop. Here is my experience:

First of all, all the major characteristics are the same, which is to say, very well implemented. They both use strong encryption, to encrypt the whole drive, decrypt it just an instant before booting the OS... Truecrypt supports multiboot bootloader, and they both prompt you to save a backup encryption key for recovery. They both perform a test boot before encrypting the whole drive, they both allow you to continue doing stuff while the application applies encryption as a background process. You can pause the encryption process, reboot if you want, and later resume. They both use the AES-NI instruction set when available.

So all in all, it's quite good. But there are a couple of differences that I felt were significant:

Truecrypt definitely uses a 256bit key, but that's enormously irrelevant because it's using a password key derivation process, and there's no conceivable way a user is going to type a password with 256 bits of entropy. A typical PC can brute force approx 10m keys per second, while a government super computer is approx a few million times that. Other techniques such as GPU and FPGA cracking can increase the attack rate by another factor of 1,000 to 1,000,000. So the world's most powerful FPGA cracking array might be able to attack 10^12 or 10^13 keys per second. And then of course, some clever people have identified smarter attack techniques rather than naive brute force. I have no knowledge how much they gain with improved technique. So the strength of your encryption very much depends on the strength of your key.

Bitlocker has conflicting reports on the internet. Some say it's 128, some say 256. I'm guessing it's actually 128 by default, with an option to go stronger somehow. I recently did a calculation to see how significant this difference is, and concluded that if somebody tries to brute force 128 bits with a normal laptop, it will take ~ 60,000 years. Which means either key strength is good enough to keep out typical attackers. But if a government agency wanted to brute force attack, based on info at top500.org, the 128bit key is brute forceable in a matter of minutes, while the 256bit key still keeps them out for like 10^12 or 10^19 years, way longer than the life of the Sun. End result: I prefer 256 bit whenever possible, but if it's not possible, I still consider 128 acceptable for anything less significant than national security.

In bitlocker, your "backup" key is random digits, stored in Active Directory, or something. So when a user gets locked out of their system (because they had motherboard replaced on warranty, or they applied a BIOS update) they can call your support desk, who can read the key across the phone, and get the user back into operation.

In Truecrypt - Oh, I forgot to mention -

In Truecrypt, you have a password, which is salted & stretched, to decrypt the Master Key, which is a random 256 bit number, which is then used to decrypt the hard drive. So normally, there's no way to "backdoor" or "recover" when you lose your password. But you can create a backup of your Header (which includes the key info), and create a rescue CD. This means I'm able to set a secret the initial truecrypt password, create rescue media, wait for the whole disk to finish encrypting, and then together, the user and I can change the password to whatever they like. They don't need to know my recovery password, and I don't need to know their password. If they're unavailable for some reason, I can boot from the recovery CD, type in the old password, and restore the bootloader key information. So then the system is bootable using my recovery password.

Problem is, if a user gets locked out (they forgot their password) they need a key reset - it can't be done remotely. Recovery involves booting from rescue media. You can only help them remotely if they have another computer handy with internet and a CD burner, or if they're willing to wait for a disc to arrive in the mail.

So that's thing #1.
Here's thing #2:

In bitlocker, the TPM does a pre-boot security assessment. Checking the BIOS, the boot device, the boot sectors... Only if it's untampered, does the TPM release the decryption key. That's good. :-)

In Truecrypt, it seems almost trivial to implement a bootloader attack. A malicious person could install a bootloader that puts up a fake login prompt, get the user to type in their password. Now that I think of it, both bitlocker and truecrypt have the same vulnerability here: If you have physical access to the machine you're attacking, you swap out the hard drive. The fake hard drive does nothing except put a fake login prompt on the screen that looks the same as the one the user expects. (Put up a video of the Windows boot screen to attack a user of bitlocker, followed by a fake login prompt that activates when the user presses ctrl-alt-del). But I think the tampered Truecrypt boot prompt is much more obvious and easier to implement than the Bitlocker implementation.

And finally, thing #3.

I use whole-disk backup software too. Acronis TrueImage. I know this works on bitlocker (although the backup itself is not encrypted.) I tried trueimage on truecrypt a few years ago and it didn't work at that time. I have not repeated the test in recent years, nor with different products. So I don't know what/if any whole disk backup program works with TrueCrypt.

Conclusion:

All in all, both solutions are very good. For general purposes, especially in company deployments, bitlocker is better due to remote unlock and compatibility with backup software. In an unrealistic world where a user memorizes a key having 256 bit strength, TrueCrypt definitely has the potential to be 256 bit strong... Whereas bitlocker, maybe can do 256 bits. I emphasize it's unrealistic for anyone to memorize such a key, while the 256 bit bitlocker implementation might just be a simple config change, or a simple update patch or future release. So in theory they're just as strong as each other. In practice, bitlocker is better.

But they're both very good.
Mathew Snyder
2013-06-28 12:25:56 UTC
Permalink
I recently had to encrypt my hard drive for work. Unfortunately, the laptop
they bought me doesn't have a TPM so I was left with other options. Having
used TrueCrypt in the past to simply encrypt files I went with that.
Implementation is simple for the most part.

One thing that left me scratching my head with TrueCrypt is the fact that,
while defaulted to not wipe the disk, doing a system disk encryption on a
running system should not even offer the option of wiping. It should be
greyed out to prevent any accidental destruction.

-Mathew

"When you do things right, people won't be sure you've done anything at
all." - God; Futurama

"We'll get along much better once you accept that you're wrong and neither
am I." - Me


On Fri, Jun 28, 2013 at 12:42 PM, Edward Ned Harvey (lopser) <
Post by Edward Ned Harvey (lopser)
For the last few years, I've been a fan of deploying Bitlocker, largely
because I was so impressed with its ease of use and overall performance.
Recently, I accidentally bought Win7 Pro, which doesn't have bitlocker, and
decided to figure out Truecrypt whole disk encryption rather than paying
for the Windows upgrade or exchanging the laptop. Here is my experience:*
***
** **
First of all, all the major characteristics are the same, which is to say,
very well implemented. They both use strong encryption, to encrypt the
whole drive, decrypt it just an instant before booting the OS... Truecrypt
supports multiboot bootloader, and they both prompt you to save a backup
encryption key for recovery. They both perform a test boot before
encrypting the whole drive, they both allow you to continue doing stuff
while the application applies encryption as a background process. You can
pause the encryption process, reboot if you want, and later resume. They
both use the AES-NI instruction set when available.****
** **
So all in all, it's quite good. But there are a couple of differences
that I felt were significant:****
** **
Truecrypt definitely uses a 256bit key, but that's enormously irrelevant
because it's using a password key derivation process, and there's no
conceivable way a user is going to type a password with 256 bits of
entropy. A typical PC can brute force approx 10m keys per second, while a
government super computer is approx a few million times that. Other
techniques such as GPU and FPGA cracking can increase the attack rate by
another factor of 1,000 to 1,000,000. So the world's most powerful FPGA
cracking array might be able to attack 10^12 or 10^13 keys per second. And
then of course, some clever people have identified smarter attack
techniques rather than naive brute force. I have no knowledge how much
they gain with improved technique. So the strength of your encryption very
much depends on the strength of your key.****
** **
Bitlocker has conflicting reports on the internet. Some say it's 128,
some say 256. I'm guessing it's actually 128 by default, with an option to
go stronger somehow. I recently did a calculation to see how significant
this difference is, and concluded that if somebody tries to brute force 128
bits with a normal laptop, it will take ~ 60,000 years. Which means either
key strength is good enough to keep out typical attackers. But if a
government agency wanted to brute force attack, based on info at
top500.org, the 128bit key is brute forceable in a matter of minutes,
while the 256bit key still keeps them out for like 10^12 or 10^19 years,
way longer than the life of the Sun. End result: I prefer 256 bit
whenever possible, but if it's not possible, I still consider 128
acceptable for anything less significant than national security.****
** **
In bitlocker, your "backup" key is random digits, stored in Active
Directory, or something. So when a user gets locked out of their system
(because they had motherboard replaced on warranty, or they applied a BIOS
update) they can call your support desk, who can read the key across the
phone, and get the user back into operation.****
** **
In Truecrypt - Oh, I forgot to mention - ****
** **
In Truecrypt, you have a password, which is salted & stretched, to decrypt
the Master Key, which is a random 256 bit number, which is then used to
decrypt the hard drive. So normally, there's no way to "backdoor" or
"recover" when you lose your password. But you can create a backup of your
Header (which includes the key info), and create a rescue CD. This means
I'm able to set a secret the initial truecrypt password, create rescue
media, wait for the whole disk to finish encrypting, and then together, the
user and I can change the password to whatever they like. They don't need
to know my recovery password, and I don't need to know their password. If
they're unavailable for some reason, I can boot from the recovery CD, type
in the old password, and restore the bootloader key information. So then
the system is bootable using my recovery password.****
** **
Problem is, if a user gets locked out (they forgot their password) they
need a key reset - it can't be done remotely. Recovery involves booting
from rescue media. You can only help them remotely if they have another
computer handy with internet and a CD burner, or if they're willing to wait
for a disc to arrive in the mail.****
** **
So that's thing #1.****
Here's thing #2:****
** **
In bitlocker, the TPM does a pre-boot security assessment. Checking the
BIOS, the boot device, the boot sectors... Only if it's untampered, does
the TPM release the decryption key. That's good. :-)****
** **
In Truecrypt, it seems almost trivial to implement a bootloader attack. A
malicious person could install a bootloader that puts up a fake login
prompt, get the user to type in their password. Now that I think of it,
both bitlocker and truecrypt have the same vulnerability here: If you have
physical access to the machine you're attacking, you swap out the hard
drive. The fake hard drive does nothing except put a fake login prompt on
the screen that looks the same as the one the user expects. (Put up a
video of the Windows boot screen to attack a user of bitlocker, followed by
a fake login prompt that activates when the user presses ctrl-alt-del).
But I think the tampered Truecrypt boot prompt is much more obvious and
easier to implement than the Bitlocker implementation.****
** **
And finally, thing #3.****
** **
I use whole-disk backup software too. Acronis TrueImage. I know this
works on bitlocker (although the backup itself is not encrypted.) I tried
trueimage on truecrypt a few years ago and it didn't work at that time. I
have not repeated the test in recent years, nor with different products.
So I don't know what/if any whole disk backup program works with TrueCrypt.
****
** **
Conclusion:****
** **
All in all, both solutions are very good. For general purposes,
especially in company deployments, bitlocker is better due to remote unlock
and compatibility with backup software. In an unrealistic world where a
user memorizes a key having 256 bit strength, TrueCrypt definitely has the
potential to be 256 bit strong... Whereas bitlocker, maybe can do 256
bits. I emphasize it's unrealistic for anyone to memorize such a key,
while the 256 bit bitlocker implementation might just be a simple config
change, or a simple update patch or future release. So in theory they're
just as strong as each other. In practice, bitlocker is better.****
** **
But they're both very good.****
_______________________________________________
Tech mailing list
https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
http://lopsa.org/
William J. Robbins
2013-06-28 16:32:50 UTC
Permalink
"Truecrypt definitely uses a 256bit key, but that's enormously irrelevant
because it's using a password key derivation process, and there's no
conceivable way a user is going to type a password with 256 bits of
entropy."

This ignores the option of using a keyfile instead of a password. Further,
Truecrypt does not use a password key derivation process - it uses a random
number generator process (the process that you go through by moving the
mouse).

http://www.truecrypt.org/docs/random-number-generator

Bitlocker: "Some say it's 128, some say 256. I'm guessing it's actually
128 by default, with an option to go stronger somehow."

MS article saying, "BitLocker supports two levels of cipher strength for
BitLocker: 128-bit and 256-bit. "(
http://technet.microsoft.com/en-us/library/ee706531(v=ws.10).aspx)


Bitlocker: "...if somebody tries to brute force 128 bits with a normal
laptop, it will take ~ 60,000 years."

So, we discussed lobbing GPUs and FPGA cracking from the NSA when we
discussed Truecrypt, but only people with crappy laptops are going to be
able to try to crack a Bitlocker key? And how do you come to the conclusion
that Truecrypt's 256bit key is inferior to Bitlocker's 128bit key you
surmised earlier?


"In bitlocker, your "backup" key is random digits, stored in Active
Directory, or something."

A backup key that is random digits is not a key to anything. Proper keys
are randomly generated, but they are no longer just random numbers when
they are used to encrypt things - at that point, they NEED to be very
specific and in a very particular order. BTW: Bitlocker by itself doesn't
store anything in AD, unless you are deploying using Microsoft's MBAM.

http://technet.microsoft.com/en-us/windows/hh826072.aspx

http://windows.microsoft.com/en-us/windows7/what-is-a-bitlocker-recovery-key

http://windows.microsoft.com/en-us/windows-8/bitlocker-recovery-keys-faq






- William


On Fri, Jun 28, 2013 at 6:42 AM, Edward Ned Harvey (lopser) <
Post by Edward Ned Harvey (lopser)
For the last few years, I've been a fan of deploying Bitlocker, largely
because I was so impressed with its ease of use and overall performance.
Recently, I accidentally bought Win7 Pro, which doesn't have bitlocker, and
decided to figure out Truecrypt whole disk encryption rather than paying
for the Windows upgrade or exchanging the laptop. Here is my experience:*
***
** **
First of all, all the major characteristics are the same, which is to say,
very well implemented. They both use strong encryption, to encrypt the
whole drive, decrypt it just an instant before booting the OS... Truecrypt
supports multiboot bootloader, and they both prompt you to save a backup
encryption key for recovery. They both perform a test boot before
encrypting the whole drive, they both allow you to continue doing stuff
while the application applies encryption as a background process. You can
pause the encryption process, reboot if you want, and later resume. They
both use the AES-NI instruction set when available.****
** **
So all in all, it's quite good. But there are a couple of differences
that I felt were significant:****
** **
Truecrypt definitely uses a 256bit key, but that's enormously irrelevant
because it's using a password key derivation process, and there's no
conceivable way a user is going to type a password with 256 bits of
entropy. A typical PC can brute force approx 10m keys per second, while a
government super computer is approx a few million times that. Other
techniques such as GPU and FPGA cracking can increase the attack rate by
another factor of 1,000 to 1,000,000. So the world's most powerful FPGA
cracking array might be able to attack 10^12 or 10^13 keys per second. And
then of course, some clever people have identified smarter attack
techniques rather than naive brute force. I have no knowledge how much
they gain with improved technique. So the strength of your encryption very
much depends on the strength of your key.****
** **
Bitlocker has conflicting reports on the internet. Some say it's 128,
some say 256. I'm guessing it's actually 128 by default, with an option to
go stronger somehow. I recently did a calculation to see how significant
this difference is, and concluded that if somebody tries to brute force 128
bits with a normal laptop, it will take ~ 60,000 years. Which means either
key strength is good enough to keep out typical attackers. But if a
government agency wanted to brute force attack, based on info at
top500.org, the 128bit key is brute forceable in a matter of minutes,
while the 256bit key still keeps them out for like 10^12 or 10^19 years,
way longer than the life of the Sun. End result: I prefer 256 bit
whenever possible, but if it's not possible, I still consider 128
acceptable for anything less significant than national security.****
** **
In bitlocker, your "backup" key is random digits, stored in Active
Directory, or something. So when a user gets locked out of their system
(because they had motherboard replaced on warranty, or they applied a BIOS
update) they can call your support desk, who can read the key across the
phone, and get the user back into operation.****
** **
In Truecrypt - Oh, I forgot to mention - ****
** **
In Truecrypt, you have a password, which is salted & stretched, to decrypt
the Master Key, which is a random 256 bit number, which is then used to
decrypt the hard drive. So normally, there's no way to "backdoor" or
"recover" when you lose your password. But you can create a backup of your
Header (which includes the key info), and create a rescue CD. This means
I'm able to set a secret the initial truecrypt password, create rescue
media, wait for the whole disk to finish encrypting, and then together, the
user and I can change the password to whatever they like. They don't need
to know my recovery password, and I don't need to know their password. If
they're unavailable for some reason, I can boot from the recovery CD, type
in the old password, and restore the bootloader key information. So then
the system is bootable using my recovery password.****
** **
Problem is, if a user gets locked out (they forgot their password) they
need a key reset - it can't be done remotely. Recovery involves booting
from rescue media. You can only help them remotely if they have another
computer handy with internet and a CD burner, or if they're willing to wait
for a disc to arrive in the mail.****
** **
So that's thing #1.****
Here's thing #2:****
** **
In bitlocker, the TPM does a pre-boot security assessment. Checking the
BIOS, the boot device, the boot sectors... Only if it's untampered, does
the TPM release the decryption key. That's good. :-)****
** **
In Truecrypt, it seems almost trivial to implement a bootloader attack. A
malicious person could install a bootloader that puts up a fake login
prompt, get the user to type in their password. Now that I think of it,
both bitlocker and truecrypt have the same vulnerability here: If you have
physical access to the machine you're attacking, you swap out the hard
drive. The fake hard drive does nothing except put a fake login prompt on
the screen that looks the same as the one the user expects. (Put up a
video of the Windows boot screen to attack a user of bitlocker, followed by
a fake login prompt that activates when the user presses ctrl-alt-del).
But I think the tampered Truecrypt boot prompt is much more obvious and
easier to implement than the Bitlocker implementation.****
** **
And finally, thing #3.****
** **
I use whole-disk backup software too. Acronis TrueImage. I know this
works on bitlocker (although the backup itself is not encrypted.) I tried
trueimage on truecrypt a few years ago and it didn't work at that time. I
have not repeated the test in recent years, nor with different products.
So I don't know what/if any whole disk backup program works with TrueCrypt.
****
** **
Conclusion:****
** **
All in all, both solutions are very good. For general purposes,
especially in company deployments, bitlocker is better due to remote unlock
and compatibility with backup software. In an unrealistic world where a
user memorizes a key having 256 bit strength, TrueCrypt definitely has the
potential to be 256 bit strong... Whereas bitlocker, maybe can do 256
bits. I emphasize it's unrealistic for anyone to memorize such a key,
while the 256 bit bitlocker implementation might just be a simple config
change, or a simple update patch or future release. So in theory they're
just as strong as each other. In practice, bitlocker is better.****
** **
But they're both very good.****
_______________________________________________
Tech mailing list
https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
http://lopsa.org/
Edward Ned Harvey (lopser)
2013-06-29 13:57:17 UTC
Permalink
On Behalf Of William J. Robbins
This ignores the option of using a keyfile instead of a password. Further,
Truecrypt does not use a password key derivation process - it uses a random
number generator process (the process that you go through by  moving the
mouse).
When you're doing whole disk encryption, and unlocking the volume via truecrypt bootloader, I don't believe the bootloader supports keyfiles, and even if it does, there is no USB or removable storage support, so as far as I can tell, you just can't do it.

A password key derivation process is absolutely necessary whenever you have stored key encrypted by a password. The user types in a password, and the key derivation process applies salting and stretching via some hash algorithm (In this case, SHA256) to generate the key that is used for encryption/decryption.

The key itself was randomly generated, but the key itself is stored encrypted in the Truecrypt header, encrypted by the key that's generated from password via the key derivation process. This way, you can quickly easily change your volume password without needing to re-encrypt the whole volume. It just overwrites a small block at the beginning and end of the volume.
Bitlocker: "Some say it's 128, some say 256.  I'm guessing it's actually 128 by
default, with an option to go stronger somehow."
MS article saying, "BitLocker supports two levels of cipher strength for
BitLocker: 128-bit and 256-bit. "(http://technet.microsoft.com/en-
us/library/ee706531(v=ws.10).aspx)
Yeah, I saw that article. But whenever I've enabled bitlocker before, they don't prompt you for any of the optional options. You don't select a key strength, you don't get any option of enabling PIN or key media, etc. It just does the brainless one-click setup, without telling you what it's doing.

That's why I said I think it's doing 128 bits, with some potentially easy option to do 256, but I don't know how.
Bitlocker: "...if somebody tries to brute force 128 bits with a normal laptop, it
will take ~ 60,000 years."
So, we discussed lobbing GPUs and FPGA cracking from the NSA when we
discussed Truecrypt, but only people with crappy laptops are going to be able
to try to crack a Bitlocker key? And how do you come to the conclusion that
Truecrypt's 256bit  key is inferior to Bitlocker's 128bit key you surmised
earlier?
I'm afraid I don't understand the question(s).

I did say that despite 256bit encryption in truecrypt, that's irrelevant because the weakpoint is the way-less-than-256bit password a user must type in. If your system is going to be locked by a human memorizable password, then you might as well run 128bit cipher, because no attacker will ever waste their time trying to attack the key directly. They'll try to attack your password instead.

Bitlocker, via TPM, uses a full-strength randomly generated key, which is locked away and never exposed. The weakpoint is either the key itself, or some difficult and risky technique of tampering with the tamper-resistant TPM. It's all contained on a single chip. Very difficult, if not impossible, to crack apart or otherwise look inside, to read its memory.
"In bitlocker, your "backup" key is random digits, stored in Active Directory,
or something."
A backup key that is random digits is not a key to anything. Proper keys are
randomly generated, but they are no longer just random numbers when
they are used to encrypt things - at that point, they NEED to be very specific
and in a very particular order. BTW: Bitlocker by itself doesn't store anything
in AD, unless you are deploying using Microsoft's MBAM.
I'm afraid I don't get your point. The encryption key is randomly generated, and a backup copy stored somewhere of your choosing. So I guess it's no longer "random" when you copy it, because at that point you're sequentially copying data that has been predetermined, but it seems very nonsensical to say so... So unless you're just being pointlessly antagonistic, I guess I must have missed your point.
David Lang
2013-06-29 19:54:47 UTC
Permalink
Post by Edward Ned Harvey (lopser)
A password key derivation process is absolutely necessary whenever you have
stored key encrypted by a password. The user types in a password, and the key
derivation process applies salting and stretching via some hash algorithm (In
this case, SHA256) to generate the key that is used for encryption/decryption.
In any case, does it really make a difference if the encryption key is the
password stretched or just stored and 'unlocked' in some way by the password?

As long as there is a way to tell if it was the right passowrd or not, all the
attacker needs to do is to attack the password space. they don't have to attack
the stronger key space.

<soap box>
This is especially a problem with software tokens that have a very strong key,
but allow the user to put in a weak password and then can tell the user if the
password they typed was correct before providing a response. This allows an
attacker who can get a copy of the soft token info to brute force the password,
bypassing any lock-outs implemented in the token (by restoring from a backup
every time the soft token locks them out).

If the soft token works in a way that it doesn't know if the password was
correct or not, and always returns a value, requiring interaction with the
server to find out if the value (and therefor the password) was correct, it's
significantly better.

Now, if the attacker gets a keystroke logger on the box to steal the password,
none of this matters.

<soap box>

David Lang
Edward Ned Harvey (lopser)
2013-06-30 11:49:24 UTC
Permalink
Post by David Lang
In any case, does it really make a difference if the encryption key is the
password stretched or just stored and 'unlocked' in some way by the password?
As long as there is a way to tell if it was the right passowrd or not, all the
attacker needs to do is to attack the password space. they don't have to attack
the stronger key space.
William J. Robbins
2013-06-30 13:04:54 UTC
Permalink
On Sat, Jun 29, 2013 at 8:57 AM, Edward Ned Harvey (lopser) <
Post by William J. Robbins
On Behalf Of William J. Robbins
This ignores the option of using a keyfile instead of a password.
Further,
Truecrypt does not use a password key derivation process - it uses a
random
number generator process (the process that you go through by moving the
mouse).
When you're doing whole disk encryption, and unlocking the volume via
truecrypt bootloader, I don't believe the bootloader supports keyfiles, and
even if it does, there is no USB or removable storage support, so as far as
I can tell, you just can't do it.
No you are correct there, I was distracted at $work when I replied
initially.
Post by William J. Robbins
A password key derivation process is absolutely necessary whenever you
have stored key encrypted by a password. The user types in a password, and
the key derivation process applies salting and stretching via some hash
algorithm (In this case, SHA256) to generate the key that is used for
encryption/decryption.
The key itself was randomly generated, but the key itself is stored
encrypted in the Truecrypt header, encrypted by the key that's generated
from password via the key derivation process. This way, you can quickly
easily change your volume password without needing to re-encrypt the whole
volume. It just overwrites a small block at the beginning and end of the
volume.
Bitlocker: "Some say it's 128, some say 256. I'm guessing it's actually
128 by
default, with an option to go stronger somehow."
MS article saying, "BitLocker supports two levels of cipher strength for
BitLocker: 128-bit and 256-bit. "(http://technet.microsoft.com/en-
us/library/ee706531(v=ws.10).aspx)
Yeah, I saw that article. But whenever I've enabled bitlocker before,
they don't prompt you for any of the optional options. You don't select a
key strength, you don't get any option of enabling PIN or key media, etc.
It just does the brainless one-click setup, without telling you what it's
doing.
That's why I said I think it's doing 128 bits, with some potentially easy
option to do 256, but I don't know how.
Gotcha. I was mostly clarifying that with an MS article because initially
you stated some sad yea, some said nay, but you weren't certain.
Post by William J. Robbins
Bitlocker: "...if somebody tries to brute force 128 bits with a normal
laptop, it
will take ~ 60,000 years."
So, we discussed lobbing GPUs and FPGA cracking from the NSA when we
discussed Truecrypt, but only people with crappy laptops are going to be
able
to try to crack a Bitlocker key? And how do you come to the conclusion
that
Truecrypt's 256bit key is inferior to Bitlocker's 128bit key you
surmised
earlier?
I'm afraid I don't understand the question(s).
I may have misunderstood what you were attempting to do in comparing the
crack times on the Bitlocker vs. TC keys.
Post by William J. Robbins
I did say that despite 256bit encryption in truecrypt, that's irrelevant
because the weakpoint is the way-less-than-256bit password a user must type
in. If your system is going to be locked by a human memorizable password,
then you might as well run 128bit cipher, because no attacker will ever
waste their time trying to attack the key directly. They'll try to attack
your password instead.
But to get 256 bits of entropy is only around 42 characters isn't it?

(And that's based on this:
https://en.wikipedia.org/wiki/Password_strength#Entropy_as_a_measure_of_password_strength
using the Alphnumeric character value of 5.954, Would be some higher using
special characters as one should)

If I'm encrypting a drive I'd think a decent passphrase would meet/exceed
42 characters. Something like: *Dammit Jim, I'm a doctor not a bricklayer!*
Post by William J. Robbins
Bitlocker, via TPM, uses a full-strength randomly generated key, which is
locked away and never exposed. The weakpoint is either the key itself, or
some difficult and risky technique of tampering with the tamper-resistant
TPM. It's all contained on a single chip. Very difficult, if not
impossible, to crack apart or otherwise look inside, to read its memory.
"In bitlocker, your "backup" key is random digits, stored in Active
Directory,
or something."
A backup key that is random digits is not a key to anything. Proper keys
are
randomly generated, but they are no longer just random numbers when
they are used to encrypt things - at that point, they NEED to be very
specific
and in a very particular order. BTW: Bitlocker by itself doesn't store
anything
in AD, unless you are deploying using Microsoft's MBAM.
I'm afraid I don't get your point. The encryption key is randomly
generated, and a backup copy stored somewhere of your choosing. So I guess
it's no longer "random" when you copy it, because at that point you're
sequentially copying data that has been predetermined, but it seems very
nonsensical to say so... So unless you're just being pointlessly
antagonistic, I guess I must have missed your point.
Not trying to be antagonistic, certainly not needlessly. I'd accept
pedantic perhaps. :)


Point I think I was trying to make is that it's not random after
generation. And if you are doing a home PC not on a domain, the only
storage of the recovery key is where you put it on completion. I've seen
folks screen shot it, print it off, etc.

But at any rate, if I cam
e
off as antagonistic I apologize.
Edward Ned Harvey (lopser)
2013-07-01 01:29:31 UTC
Permalink
On Behalf Of William J. Robbins
(And that's based on
this: https://en.wikipedia.org/wiki/Password_strength#Entropy_as_a_meas
ure_of_password_strength
using the Alphnumeric character value of 5.954, Would be some higher using
special characters as one should)
If I'm encrypting a drive I'd think a decent passphrase would meet/exceed 42
characters. Something like: Dammit Jim, I'm a doctor not a bricklayer!
To attack your password in a situation such as you described above, an attacker only needs to learn (or guess) that you used some sort of phrase instead of random characters, and they won't need to attack random characters anymore. They'll attack patterns of words, which is a *far* smaller space to attack, considering you have only 8 words in there. 8 random words from the space including unusual words and proper nouns and stuff, gets you around 104 bits. Throw in some common substitutions such as "d0ctor" and you gain a little bit, but they're predictable, unless they're random. In fact, *all* the characters are predictable unless they're random.

I emphasize, number of characters is only a measure of entropy, if they're randomly selected by a machine, and then you memorize them without any modification. The measure of entropy in your password is measured by the number of guesses an attacker would have to work through in order to guess your pass. As soon as you start making modifications such as "Gpu7mvrDZ is too hard to type, I'm going to make it GPU7mvrDZ" the attack space becomes smaller, based on predictions of human behavior.
But to get 256 bits of entropy is only around 42 characters isn't it?
To answer this kind of stuff, I like wolframalpha.
Alphanumeric, mixed case, means 26*26*10 possibilities for each character.
log2((26*26*10)^21)
If you randomly choose 21 characters = 267 bits. (20 chars is only 254 bits). Here's an example of what the 21 char password would look like:
omEzmGpu7mvrDZbYYPM4Da
Yes, you can memorize something like that, with some effort. But you certainly cannot expect it to be common practice.

They have to be *random* characters. No acronyms, nothing that reflects the frequency of letters occurring in English, etc. If you're not selecting them randomly, you're reducing the space you select your password from.

Also, in this: https://code.google.com/p/randchars/ There is a 2264 list of words. log2(2264^23) = 256 bits. So 23 random words would give you 256 bits entropy...
suggest-pot-live-complaint-flood-mouth-bless-and-sauce-anger-mineral-discussion-point-gallon-notebook-wreck-mercy-drop-cousin-absence-other-ocean-sacred

You could use a randomly generated 256 bit password like that. It might be easier to memorize than the random characters.
And if you are doing a home PC not on a domain, the only
storage of the recovery key is where you put it on completion.  I've seen
folks screen shot it, print it off, etc.
Good point. Recovery key that was initially generated randomly is only as secure as the security around your backup copy of that key. The truecrypt recovery media is equally strong as the truecrypt volume itself - which is as strong as your password. With bitlocker, you have several options, so it's difficult to analyze the security of your backup keys. If stored in Active Directory ... Well, AD is itself very secure if well configured. But lots of people don't configure it well. And if you take a screen shot, or copy text, then it all depends on where you choose to save it...
Dave Close
2013-07-01 02:07:19 UTC
Permalink
Post by Edward Ned Harvey (lopser)
To answer this kind of stuff, I like wolframalpha.
Alphanumeric, mixed case, means 26*26*10 possibilities for each character.
Huh? I count 62 possibilities for each character, far smaller.
--
Dave Close, Compata, Irvine CA "If I seem unduly clear to you,
***@compata.com, +1 714 434 7359 you must have misunderstood
***@alumni.caltech.edu what I said." -- Alan Greenspan
Edward Ned Harvey (lopser)
2013-07-01 02:46:54 UTC
Permalink
On Behalf Of Dave Close
Post by Edward Ned Harvey (lopser)
To answer this kind of stuff, I like wolframalpha.
Alphanumeric, mixed case, means 26*26*10 possibilities for each character.
Huh? I count 62 possibilities for each character, far smaller.
Oops - sorry. I screwed that up. 26+26+10 = 62 possibilities for each character.
log62(2^256) = 43 random alphanumeric characters needed for 256 bit password strength
William J. Robbins
2013-07-01 14:00:38 UTC
Permalink
The wrench never fails. :)

For 99% of my passwords I use LastPass and the PW generator. It irks me no
end to come across a site that doesn't accept complex passwords, or ones
with stupid limitations of 12 or less characters. I had (past tense is
key) a bank site that limited to 16 and didn't allow special characters.
Discover actually requires a complex *username*...but I digress.

At the end of the day if someone knows enough to bother encrypting their
system in the first place they know to use a decent passphrase...and they
also know about the wrench. As another tangent, the wrench is why I like
TrueCrypt's "Duress password" ability. But that also doesn't work on whole
disk. :(

Which is why I typically don't do whole disk for my personal stuff. Darn
wrench.


- William


On Mon, Jul 1, 2013 at 6:35 AM, Edward Harvey <
Yeah, I like that one. :-)****
** **
Also this:****
http://xkcd.com/538/****
** **
Incidentally, this is mine, and it's what I use:****
https://clevertrove.com/randcharsweb/****
** **
** **
** **
** **
J. Robbins
*Sent:* Sunday, June 30, 2013 11:07 PM
*To:* Edward Ned Harvey (lopser)
*Subject:* Re: [lopsa-tech] Bitlocker vs Truecrypt****
** **
Reminds me almost exactly of this: http://xkcd.com/936/****
:D****
****
- William****
** **
On Sun, Jun 30, 2013 at 8:29 PM, Edward Ned Harvey (lopser) <
]
On Behalf Of William J. Robbins
****
(And that's based on
this: https://en.wikipedia.org/wiki/Password_strength#Entropy_as_a_meas
ure_of_password_strength
using the Alphnumeric character value of 5.954, Would be some higher
using
special characters as one should)
If I'm encrypting a drive I'd think a decent passphrase would
meet/exceed 42
characters. Something like: Dammit Jim, I'm a doctor not a bricklayer!*
***
To attack your password in a situation such as you described above, an
attacker only needs to learn (or guess) that you used some sort of phrase
instead of random characters, and they won't need to attack random
characters anymore. They'll attack patterns of words, which is a *far*
smaller space to attack, considering you have only 8 words in there. 8
random words from the space including unusual words and proper nouns and
stuff, gets you around 104 bits. Throw in some common substitutions such
as "d0ctor" and you gain a little bit, but they're predictable, unless
they're random. In fact, *all* the characters are predictable unless
they're random.
I emphasize, number of characters is only a measure of entropy, if they're
randomly selected by a machine, and then you memorize them without any
modification. The measure of entropy in your password is measured by the
number of guesses an attacker would have to work through in order to guess
your pass. As soon as you start making modifications such as "Gpu7mvrDZ is
too hard to type, I'm going to make it GPU7mvrDZ" the attack space becomes
smaller, based on predictions of human behavior.****
But to get 256 bits of entropy is only around 42 characters isn't it?***
*
To answer this kind of stuff, I like wolframalpha.
Alphanumeric, mixed case, means 26*26*10 possibilities for each character.
log2((26*26*10)^21)
If you randomly choose 21 characters = 267 bits. (20 chars is only 254
omEzmGpu7mvrDZbYYPM4Da
Yes, you can memorize something like that, with some effort. But you
certainly cannot expect it to be common practice.
They have to be *random* characters. No acronyms, nothing that reflects
the frequency of letters occurring in English, etc. If you're not
selecting them randomly, you're reducing the space you select your password
from.
Also, in this: https://code.google.com/p/randchars/ There is a 2264 list
of words. log2(2264^23) = 256 bits. So 23 random words would give you 256
bits entropy...
suggest-pot-live-complaint-flood-mouth-bless-and-sauce-anger-mineral-discussion-point-gallon-notebook-wreck-mercy-drop-cousin-absence-other-ocean-sacred
You could use a randomly generated 256 bit password like that. It might
be easier to memorize than the random characters.****
And if you are doing a home PC not on a domain, the only
storage of the recovery key is where you put it on completion. I've seen
folks screen shot it, print it off, etc.****
Good point. Recovery key that was initially generated randomly is only as
secure as the security around your backup copy of that key. The truecrypt
recovery media is equally strong as the truecrypt volume itself - which is
as strong as your password. With bitlocker, you have several options, so
it's difficult to analyze the security of your backup keys. If stored in
Active Directory ... Well, AD is itself very secure if well configured.
But lots of people don't configure it well. And if you take a screen
shot, or copy text, then it all depends on where you choose to save it...*
***
** **
Brandon Allbery
2013-07-01 14:07:29 UTC
Permalink
On Mon, Jul 1, 2013 at 10:00 AM, William J. Robbins
Post by William J. Robbins
For 99% of my passwords I use LastPass and the PW generator. It irks me
no end to come across a site that doesn't accept complex passwords, or ones
with stupid limitations of 12 or less characters. I had (past tense is
key) a bank site that limited to 16 and didn't allow special characters.
Discover actually requires a complex *username*...but I digress.
I don't know if their current system works the same way, but PNCBank's
system a few years ago was the same way: more (both in number and variety)
characters allowed in the username than the password. So I generated *both*
by their respective rules. :)
--
brandon s allbery kf8nh sine nomine associates
***@gmail.com ***@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
Jeremy Page
2013-07-01 14:19:25 UTC
Permalink
Also consider the "wrench" implication for biometrics. Given motivation
the unscrupulous would cut your hand (or whatever) off for it too (or
kidnap your loved ones or what have you).

In the end I think that knowing when people access stuff with decent
pattern analysis is going to be more reliable/scalable than anything else.
Post by William J. Robbins
The wrench never fails. :)
For 99% of my passwords I use LastPass and the PW generator. It irks
me no end to come across a site that doesn't accept complex passwords,
or ones with stupid limitations of 12 or less characters. I had (past
tense is key) a bank site that limited to 16 and didn't allow special
characters. Discover actually requires a complex *username*...but I
digress.
At the end of the day if someone knows enough to bother encrypting
their system in the first place they know to use a decent
passphrase...and they also know about the wrench. As another tangent,
the wrench is why I like TrueCrypt's "Duress password" ability. But
that also doesn't work on whole disk. :(
Which is why I typically don't do whole disk for my personal stuff.
Darn wrench.
- William
On Mon, Jul 1, 2013 at 6:35 AM, Edward Harvey
Yeah, I like that one. :-)
http://xkcd.com/538/
https://clevertrove.com/randcharsweb/
Behalf Of *William J. Robbins
*Sent:* Sunday, June 30, 2013 11:07 PM
*To:* Edward Ned Harvey (lopser)
*Subject:* Re: [lopsa-tech] Bitlocker vs Truecrypt
Reminds me almost exactly of this: http://xkcd.com/936/
:D
- William
On Sun, Jun 30, 2013 at 8:29 PM, Edward Ned Harvey (lopser)
On Behalf Of William J. Robbins
(And that's based on
https://en.wikipedia.org/wiki/Password_strength#Entropy_as_a_meas
ure_of_password_strength
using the Alphnumeric character value of 5.954, Would be
some higher using
special characters as one should)
If I'm encrypting a drive I'd think a decent passphrase
would meet/exceed 42
characters. Something like: Dammit Jim, I'm a doctor not a
bricklayer!
To attack your password in a situation such as you described
above, an attacker only needs to learn (or guess) that you
used some sort of phrase instead of random characters, and
they won't need to attack random characters anymore. They'll
attack patterns of words, which is a *far* smaller space to
attack, considering you have only 8 words in there. 8 random
words from the space including unusual words and proper nouns
and stuff, gets you around 104 bits. Throw in some common
substitutions such as "d0ctor" and you gain a little bit, but
they're predictable, unless they're random. In fact, *all*
the characters are predictable unless they're random.
I emphasize, number of characters is only a measure of
entropy, if they're randomly selected by a machine, and then
you memorize them without any modification. The measure of
entropy in your password is measured by the number of guesses
an attacker would have to work through in order to guess your
pass. As soon as you start making modifications such as
"Gpu7mvrDZ is too hard to type, I'm going to make it
GPU7mvrDZ" the attack space becomes smaller, based on
predictions of human behavior.
But to get 256 bits of entropy is only around 42 characters
isn't it?
To answer this kind of stuff, I like wolframalpha.
Alphanumeric, mixed case, means 26*26*10 possibilities for each character.
log2((26*26*10)^21)
If you randomly choose 21 characters = 267 bits. (20 chars is
only 254 bits). Here's an example of what the 21 char
omEzmGpu7mvrDZbYYPM4Da
Yes, you can memorize something like that, with some effort.
But you certainly cannot expect it to be common practice.
They have to be *random* characters. No acronyms, nothing
that reflects the frequency of letters occurring in English,
etc. If you're not selecting them randomly, you're reducing
the space you select your password from.
Also, in this: https://code.google.com/p/randchars/ There is a
2264 list of words. log2(2264^23) = 256 bits. So 23 random
words would give you 256 bits entropy...
suggest-pot-live-complaint-flood-mouth-bless-and-sauce-anger-mineral-discussion-point-gallon-notebook-wreck-mercy-drop-cousin-absence-other-ocean-sacred
You could use a randomly generated 256 bit password like that.
It might be easier to memorize than the random characters.
And if you are doing a home PC not on a domain, the only
storage of the recovery key is where you put it on
completion. I've seen
folks screen shot it, print it off, etc.
Good point. Recovery key that was initially generated
randomly is only as secure as the security around your backup
copy of that key. The truecrypt recovery media is equally
strong as the truecrypt volume itself - which is as strong as
your password. With bitlocker, you have several options, so
it's difficult to analyze the security of your backup keys.
If stored in Active Directory ... Well, AD is itself very
secure if well configured. But lots of people don't configure
it well. And if you take a screen shot, or copy text, then it
all depends on where you choose to save it...
_______________________________________________
Tech mailing list
https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
http://lopsa.org/
Please be advised that this email may contain confidential
information. If you are not the intended recipient, please notify us
by email by replying to the sender and delete this message. The
sender disclaims that the content of this email constitutes an offer
to enter into, or the acceptance of, any agreement; provided that the
foregoing does not invalidate the binding effect of any digital or
other electronic reproduction of a manual signature that is included
in any attachment.
William J. Robbins
2013-07-01 14:44:24 UTC
Permalink
Reminds me of *Demolition Man *where Wesley Snipes' character pulled out
the warden's eye. :)


- William
Post by Jeremy Page
Also consider the "wrench" implication for biometrics. Given motivation
the unscrupulous would cut your hand (or whatever) off for it too (or
kidnap your loved ones or what have you).
In the end I think that knowing when people access stuff with decent
pattern analysis is going to be more reliable/scalable than anything else.
The wrench never fails. :)
For 99% of my passwords I use LastPass and the PW generator. It irks me
no end to come across a site that doesn't accept complex passwords, or ones
with stupid limitations of 12 or less characters. I had (past tense is
key) a bank site that limited to 16 and didn't allow special characters.
Discover actually requires a complex *username*...but I digress.
At the end of the day if someone knows enough to bother encrypting their
system in the first place they know to use a decent passphrase...and they
also know about the wrench. As another tangent, the wrench is why I like
TrueCrypt's "Duress password" ability. But that also doesn't work on whole
disk. :(
Which is why I typically don't do whole disk for my personal stuff.
Darn wrench.
- William
On Mon, Jul 1, 2013 at 6:35 AM, Edward Harvey <
Yeah, I like that one. :-)
http://xkcd.com/538/
https://clevertrove.com/randcharsweb/
*William J. Robbins
*Sent:* Sunday, June 30, 2013 11:07 PM
*To:* Edward Ned Harvey (lopser)
*Subject:* Re: [lopsa-tech] Bitlocker vs Truecrypt
Reminds me almost exactly of this: http://xkcd.com/936/
:D
- William
On Sun, Jun 30, 2013 at 8:29 PM, Edward Ned Harvey (lopser) <
On Behalf Of William J. Robbins
(And that's based on
https://en.wikipedia.org/wiki/Password_strength#Entropy_as_a_meas
ure_of_password_strength
using the Alphnumeric character value of 5.954, Would be some higher
using
special characters as one should)
If I'm encrypting a drive I'd think a decent passphrase would
meet/exceed 42
characters. Something like: Dammit Jim, I'm a doctor not a bricklayer!
To attack your password in a situation such as you described above, an
attacker only needs to learn (or guess) that you used some sort of phrase
instead of random characters, and they won't need to attack random
characters anymore. They'll attack patterns of words, which is a *far*
smaller space to attack, considering you have only 8 words in there. 8
random words from the space including unusual words and proper nouns and
stuff, gets you around 104 bits. Throw in some common substitutions such
as "d0ctor" and you gain a little bit, but they're predictable, unless
they're random. In fact, *all* the characters are predictable unless
they're random.
I emphasize, number of characters is only a measure of entropy, if
they're randomly selected by a machine, and then you memorize them without
any modification. The measure of entropy in your password is measured by
the number of guesses an attacker would have to work through in order to
guess your pass. As soon as you start making modifications such as
"Gpu7mvrDZ is too hard to type, I'm going to make it GPU7mvrDZ" the attack
space becomes smaller, based on predictions of human behavior.
But to get 256 bits of entropy is only around 42 characters isn't it?
To answer this kind of stuff, I like wolframalpha.
Alphanumeric, mixed case, means 26*26*10 possibilities for each character.
log2((26*26*10)^21)
If you randomly choose 21 characters = 267 bits. (20 chars is only 254
omEzmGpu7mvrDZbYYPM4Da
Yes, you can memorize something like that, with some effort. But you
certainly cannot expect it to be common practice.
They have to be *random* characters. No acronyms, nothing that reflects
the frequency of letters occurring in English, etc. If you're not
selecting them randomly, you're reducing the space you select your password
from.
Also, in this: https://code.google.com/p/randchars/ There is a 2264 list
of words. log2(2264^23) = 256 bits. So 23 random words would give you 256
bits entropy...
suggest-pot-live-complaint-flood-mouth-bless-and-sauce-anger-mineral-discussion-point-gallon-notebook-wreck-mercy-drop-cousin-absence-other-ocean-sacred
You could use a randomly generated 256 bit password like that. It might
be easier to memorize than the random characters.
And if you are doing a home PC not on a domain, the only
storage of the recovery key is where you put it on completion. I've
seen
folks screen shot it, print it off, etc.
Good point. Recovery key that was initially generated randomly is only
as secure as the security around your backup copy of that key. The
truecrypt recovery media is equally strong as the truecrypt volume itself -
which is as strong as your password. With bitlocker, you have several
options, so it's difficult to analyze the security of your backup keys. If
stored in Active Directory ... Well, AD is itself very secure if well
configured. But lots of people don't configure it well. And if you take a
screen shot, or copy text, then it all depends on where you choose to save
it...
_______________________________________________
This list provided by the League of Professional System Administrators
http://lopsa.org/
Please be advised that this email may contain confidential information. If
you are not the intended recipient, please notify us by email by replying
to the sender and delete this message. The sender disclaims that the
content of this email constitutes an offer to enter into, or the acceptance
of, any agreement; provided that the foregoing does not invalidate the
binding effect of any digital or other electronic reproduction of a manual
signature that is included in any attachment.
_______________________________________________
Tech mailing list
https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
http://lopsa.org/
William J. Robbins
2013-07-01 14:44:46 UTC
Permalink
" So the decision is not being made by informed end-users"

Same here, better that the users aren't involved IMHO.


- William
Post by William J. Robbins
For 99% of my passwords I use LastPass and the PW generator. It irks
me no end to come across a site that doesn't accept complex passwords,
or ones with stupid limitations of 12 or less characters. I had (past
tense is key) a bank site that limited to 16 and didn't allow special
characters. Discover actually requires a complex username...but I
digress.
I too hate sites like that. Usually, if I can, I use a competitor. I
also hate sites that won't accept "plussed" email addresses...
Post by William J. Robbins
At the end of the day if someone knows enough to bother encrypting
their system in the first place they know to use a decent
passphrase...
Encryption in mandated by our campus policies, and whole disk encryption
is being strongly encouraged by the security office. So the decision is
not being made by informed end-uses, it is being made by (at best) the
local sysadmins. Which doesn't mean the end user understands the
security implications at all.
--david
Edward Ned Harvey (lopser)
2013-07-01 14:56:41 UTC
Permalink
On Behalf Of William J. Robbins
At the end of the day if someone knows enough to bother encrypting their
system in the first place they know to use a decent passphrase...
I must disagree. :-) I mean, :-(

Without any wrench, using a typical home PC and completely unintelligent brute force, you can get through ~ 2^43 password guesses in ~ a week. Users often times disclose their passwords voluntarily, just based on trust. And as described in http://xkcd.com/936/ most users choose "strong" passwords that they keep secret, that are guessable within the first ~ 2^28 guesses.

Equally bad, I've seen companies where IT deployed TrueCrypt whole-disk protection to all their users, with the same password. 6 characters.

Users often choose 6 or 8 char passwords ... Heck, I've systems that *don't accept* passwords longer than 8 chars. (They let you type in more than 8, but it gets truncated at 8, so "ObamaAreEvil" == "ObamaAreGreat")

Even if a 7 char password was completely random and memorized (it never is; because it's got the kid's name or dog's name or something) then it would still be 41 bits.
William J. Robbins
2013-07-01 15:17:34 UTC
Permalink
As the saying goes, there's no fixing stupid. :)


- William


On Mon, Jul 1, 2013 at 9:56 AM, Edward Ned Harvey (lopser) <
Post by Edward Ned Harvey (lopser)
On Behalf Of William J. Robbins
At the end of the day if someone knows enough to bother encrypting their
system in the first place they know to use a decent passphrase...
I must disagree. :-) I mean, :-(
Without any wrench, using a typical home PC and completely unintelligent
brute force, you can get through ~ 2^43 password guesses in ~ a week.
Users often times disclose their passwords voluntarily, just based on
trust. And as described in http://xkcd.com/936/ most users choose
"strong" passwords that they keep secret, that are guessable within the
first ~ 2^28 guesses.
Equally bad, I've seen companies where IT deployed TrueCrypt whole-disk
protection to all their users, with the same password. 6 characters.
Users often choose 6 or 8 char passwords ... Heck, I've systems that
*don't accept* passwords longer than 8 chars. (They let you type in more
than 8, but it gets truncated at 8, so "ObamaAreEvil" == "ObamaAreGreat")
Even if a 7 char password was completely random and memorized (it never
is; because it's got the kid's name or dog's name or something) then it
would still be 41 bits.
David Parter
2013-07-01 14:25:50 UTC
Permalink
Post by William J. Robbins
For 99% of my passwords I use LastPass and the PW generator. It irks
me no end to come across a site that doesn't accept complex passwords,
or ones with stupid limitations of 12 or less characters. I had (past
tense is key) a bank site that limited to 16 and didn't allow special
characters. Discover actually requires a complex username...but I
digress.
I too hate sites like that. Usually, if I can, I use a competitor. I
also hate sites that won't accept "plussed" email addresses...
Post by William J. Robbins
At the end of the day if someone knows enough to bother encrypting
their system in the first place they know to use a decent
passphrase...
Encryption in mandated by our campus policies, and whole disk encryption
is being strongly encouraged by the security office. So the decision is
not being made by informed end-uses, it is being made by (at best) the
local sysadmins. Which doesn't mean the end user understands the
security implications at all.

--david
Loading...