[dm-crypt] Forgot dm-crypt password; suggestions on steps to undertake

[dm-crypt] Forgot dm-crypt password; suggestions on steps to undertake

[John Thoe]

[-- Attachment #1: Type: text/plain, Size: 994 bytes --]




Hi

I forgot the passphrase of my laptop which was encrypted using dm-crypt (without LUKS). I use Debian so just used the default settings that were suggested.

I understand that passwords cannot be recovered but please hear me out. In my case, I am sure that I am forgetting the last four digits I set because the rest of the password is clear in my memory.

A couple of questions I could really use help with:

1. Is it possible to brute force the disk since even though my password is fairly long, I am sure about all of it except the last 4-6 digits.

2. If (1) is not possible, is there any way I can make it easy to type in passwords? Right now, initramfs does not show me the password I am typing. Is there anyway I can have feedback from it so that I know that I am at least typing in stuff correctly? Or even better, is there any way I load a text file with a list of the probable passwords?

Any help would be much appreciated. 

Thank you.

John

 		 	   		  

[-- Attachment #2: Type: text/html, Size: 1266 bytes --]

Re: [dm-crypt] Forgot dm-crypt password; suggestions on steps to undertake

[Arno Wagner]

On Sat, Nov 09, 2013 at 22:48:25 CET, John Thoe wrote:
> 
> 
> 
> Hi
> 
> I forgot the passphrase of my laptop which was encrypted using dm-crypt
> (without LUKS).  I use Debian so just used the default settings that were
> suggested.
> 
> I understand that passwords cannot be recovered but please hear me out. In
> my case, I am sure that I am forgetting the last four digits I set because
> the rest of the password is clear in my memory.
> 
> A couple of questions I could really use help with:
> 
> 1. Is it possible to brute force the disk since even though my password is
> fairly long, I am sure about all of it except the last 4-6 digits.

It actually does not matter at all how long your password is
(unless it goes into the kB range), just how many characters
are unknown.

If you are missing 6 characters, with a standard alphabeth of, say,
2x26 chars + 10 digits and 20 special symbols, that would take
about 300'000'000 tries. As this is plain dm-crypt, a try does
not take about 1 second but signigicantly less (no iterated 
hashing). No idea how fast this really is, but if programmed right,
it may be doable in a few days of trying. Of course, you also have 
to recognize when you have the right password, which depends on
what is in there. "blkid" may help to recognize a filesystem,
but again I have no idea how fast it is.

Anyway, this is a case for using libcryptsetup directly and it
will require some real programming work.

> 2. If (1) is not possible, is there any way I can make it easy to type in
> passwords?  Right now, initramfs does not show me the password I am
> typing.  Is there anyway I can have feedback from it so that I know that I
> am at least typing in stuff correctly?  Or even better, is there any way I
> load a text file with a list of the probable passwords?

You need to do that yourself or find a distribution that does
it for you. Initramfs usage is out of scope of the cryptsetup
tool. A list of "probable passwords" would be exceedingly insecure.
And while researchers have been tryong for a couple of decades,
there still is no easy way to input passwords and remain secure,
and there probably will never be one.

Arno

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.  --Tony Hoare

Re: [dm-crypt] Forgot dm-crypt password; suggestions on steps to undertake

[John Thoe]

> If you are missing 6 characters, with a standard alphabeth of, say,
> 2x26 chars + 10 digits and 20 special symbols, that would take
> about 300'000'000 tries. As this is plain dm-crypt, a try does
> not take about 1 second but signigicantly less (no iterated
> hashing). No idea how fast this really is, but if programmed right,
> it may be doable in a few days of trying. Of course, you also have
> to recognize when you have the right password, which depends on
> what is in there. "blkid" may help to recognize a filesystem,
> but again I have no idea how fast it is.

Sorry it was actually dm-crypt with LUKS. I just checked and had no idea before.

I have generated the possible permutation list. Wouldn't it make sense to just brute force LUKS with the 100,000 possible combinations or is that a bad idea?

Sorry, I am trying to understand if it is possible to do this or I should just give up hope. 		 	   		  

Re: [dm-crypt] Forgot dm-crypt password; suggestions on steps to undertake

[Milan Broz]

On 11/10/2013 01:15 AM, John Thoe wrote:
> I have generated the possible permutation list. Wouldn't it make
> sense to just brute force LUKS with the 100,000 possible combinations
> or is that a bad idea?

You can try it with some parallel runs...

There is an example in cryptsetup source which tries passphrases from file
and also supports parallel search on multi core CPUs.
You can also split generated file and start part of search on another machine
(you need to copy LUKS header - first 4MB of the disk shoud be enough
or better you can use luksBackup).

Download source or see
http://code.google.com/p/cryptsetup/source/browse/#git%2Fmisc%2Fdict_search
(try it on some example first if it works for you, it was just quick example,
of libcryptsetup use and not much tested ... and read README)

Milan

Re: [dm-crypt] Forgot dm-crypt password; suggestions on steps to undertake

[Arno Wagner]

On Sun, Nov 10, 2013 at 01:15:25 CET, John Thoe wrote:
> > If you are missing 6 characters, with a standard alphabeth of, say,
> > 2x26 chars + 10 digits and 20 special symbols, that would take
> > about 300'000'000 tries. As this is plain dm-crypt, a try does
> > not take about 1 second but signigicantly less (no iterated
> > hashing). No idea how fast this really is, but if programmed right,
> > it may be doable in a few days of trying. Of course, you also have
> > to recognize when you have the right password, which depends on
> > what is in there. "blkid" may help to recognize a filesystem,
> > but again I have no idea how fast it is.
> 

> Sorry it was actually dm-crypt with LUKS. I just checked and had no idea
> before.

That makes it both easier and harder. Easier because the
check whether a password matches is now trivial. Harder because
LUKS uses iterated hashing. Milan has an example for doing this
somewhere in the source package, best use that. Doing it manually
with the commandline cryptsetup is possible, but not recommended.
It is likely harder than using the example dictionary search tool,
and it can use multiple CPUs.
 
> I have generated the possible permutation list. Wouldn't it make sense to
> just brute force LUKS with the 100,000 possible combinations or is that a
> bad idea?

That is actually the only thing you can do. With 100'000 
combinations, you can expect this to take something like 100'000 CPU 
seconds, or roughly 28h on a single CPU. If you do this on an image 
file of your LUKS container, just copying the first 100MB or so 
should work fine.  

> Sorry, I am trying to understand if it is possible to do this or I should
> just give up hope.

If your 100'000 combinations have the right one in there, then
it is not even very hard to do.

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.  --Tony Hoare

Re: [dm-crypt] Forgot dm-crypt password; suggestions on steps to undertake

[John Thoe]

[-- Attachment #1: Type: text/plain, Size: 537 bytes --]

Hello Arno and Milan
Thanks very much for your replies. I was not successful in retrieving the passphrase but it was a good learning experience.
A question about LUKS I have is that I travel a lot and sometimes have to leave my laptop unattended and I put it to sleep or lock it. Is it possible for an attacker to retrieve the keys while the laptop is in that state. My question is that should I always shutdown the laptop to be safe or is it fine to leave it locked or in sleep mode? Can the keys be recovered from memory? 		 	   		  

[-- Attachment #2: Type: text/html, Size: 791 bytes --]

Re: [dm-crypt] Forgot dm-crypt password; suggestions on steps to undertake

[Arno Wagner]

On Mon, Nov 11, 2013 at 03:25:30 CET, John Thoe wrote:
> Hello Arno and Milan

> Thanks very much for your replies. I was not successful in retrieving the
> passphrase but it was a good learning experience.  

> A question about LUKS I have is that I travel a lot and sometimes have to
> leave my laptop unattended and I put it to sleep or lock it.  Is it
> possible for an attacker to retrieve the keys while the laptop is in that
> state.  My question is that should I always shutdown the laptop to be safe
> or is it fine to leave it locked or in sleep mode?  Can the keys be
> recovered from memory?

The keys can be recovered from memory. Also, an attacker could
boot your machine and install malware or could install a physical
key-logger. The usual consent is that if an attacker has 
repeated unnoticed physical access to a machine, no security 
measure will help. Even encryption (shut-down state) will really
only help against an attacker that gets access only once and
steals the machine.

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.  --Tony Hoare

Re: [dm-crypt] Forgot dm-crypt password; suggestions on steps to undertake

[Milan Broz]

On 11.11.2013 4:13, Arno Wagner wrote:
> On Mon, Nov 11, 2013 at 03:25:30 CET, John Thoe wrote:
>> Hello Arno and Milan
>
>> Thanks very much for your replies. I was not successful in retrieving the
>> passphrase but it was a good learning experience.
>
>> A question about LUKS I have is that I travel a lot and sometimes have to
>> leave my laptop unattended and I put it to sleep or lock it.  Is it
>> possible for an attacker to retrieve the keys while the laptop is in that
>> state.  My question is that should I always shutdown the laptop to be safe
>> or is it fine to leave it locked or in sleep mode?  Can the keys be
>> recovered from memory?
>
> The keys can be recovered from memory. Also, an attacker could
> boot your machine and install malware or could install a physical
> key-logger. The usual consent is that if an attacker has
> repeated unnoticed physical access to a machine, no security
> measure will help. Even encryption (shut-down state) will really
> only help against an attacker that gets access only once and
> steals the machine.

This is obviously true. But if ignoring hw tampering, if you use hibernate
(to encrypted swap - should be default for distros with encrypted install)
it is safe - key is not in memory, RAM content is stored encrypted,
and you have to provide password on resume.

For suspend to RAM ("sleep") the key is still in memory so it can be quite
easily extracted.
(dmcrypt provides way how to temporarily wipe key from memory but distributions
do not use yet this because it requires quite complex handling)

Milan

Re: [dm-crypt] Forgot dm-crypt password; suggestions on steps to undertake

[Matthew Monaco]

On 11/10/2013 07:25 PM, John Thoe wrote:
> Hello Arno and Milan
> 
> Thanks very much for your replies. I was not successful in retrieving the
> passphrase but it was a good learning experience.
>

I'm not sure if this means that you couldn't find a good way to brute-force or
if your assumptions about the missing parts were wrong. I've done something
similar before, although the forgotten pieces were somewhat different and only
had ~32 possibilities. In any event, I used a script like this:

--------8<--------------------------------------------------------------
#!/bin/bash

dev="$1"
dictionary=( mypass-{0000..2000} )

for pass in "${dictionary[@]}"; do
	printf "Trying: %s..." "$pass"
	if echo -n "$pass" | cryptsetup luksOpen --test-passphrase \
	                         --key-file=- "$dev" lostdev &> /dev/null; then
		printf " SUCCESS!\n"
		break
	else
		printf "\n"
	fi
done
--------8<--------------------------------------------------------------

It didn't make sense to me to do it using libcryptsetup because the bottleneck
was the actual decryption attempt.

If this is for your root drive, you'd have to do it from a boot disk. If you're
data is important, and you really do need ~5000 attempts, I think the wait time
is manageable.

Re: [dm-crypt] Forgot dm-crypt password; suggestions on steps to undertake

[Milan Broz]

On 11/12/2013 03:58 PM, Matthew Monaco wrote:
> It didn't make sense to me to do it using libcryptsetup because the bottleneck
> was the actual decryption attempt.

The example I posted link to is using common context and arbitrary number
of processes (default is number of CPU cores) which run in parallel
(hash iterations can easily run in parallel on different CPUs)
So every process tries n-th line in candidate password file.

This is the advantage (plus save some negligible initialization time),
otherwise script is fine of course.

Milan

Re: [dm-crypt] Forgot dm-crypt password; suggestions on steps to undertake

[Matthew Monaco]

On 11/12/2013 08:10 AM, Milan Broz wrote:
> On 11/12/2013 03:58 PM, Matthew Monaco wrote:
>> It didn't make sense to me to do it using libcryptsetup because the bottleneck
>> was the actual decryption attempt.
> 
> The example I posted link to is using common context and arbitrary number
> of processes (default is number of CPU cores) which run in parallel
> (hash iterations can easily run in parallel on different CPUs)
> So every process tries n-th line in candidate password file.
> 
> This is the advantage (plus save some negligible initialization time),
> otherwise script is fine of course.
> 

I read up from his message and missed your link. I'll keep that handy =) It's
not that I have a horrible memory, I just occasionally don't use a volume for
many months or even years at a time.