Re: [dm-crypt] Password is not accepted

Re: [dm-crypt] Password is not accepted

[Arno Wagner]

Very strange indeed. Is this repeatable?

LUKS itself does not need any time to activate. LVM
should not need more than fractions of a second.

Meybe a thermal issue with RAM, CPU or PSU that has the
password iterations fail when cold and work when warmed 
up? For CPU/RAM this would be strance as cold CMOS 
circuits work better than hot ones. For the PSU, it
is possible that failing capacitors reconstiture a bit
after warm up. Anyways, sounds like a hardware issue to 
me.

Arno

On Tue, Sep 20, 2011 at 09:13:32PM +0200, Ask Me wrote:
> Hi
> 
> Now I'm having a strange problem. First I thought that I was getting old and had forgot my password but now it happens more then once.
> 
> When I reboot my computer and try to open my encrypted device with "cryptsetup luksOpen /dev/vg_home/home_private lv_encr" I get the message that my password is not accepted.
> But if I reboot it again and wait for a few minutes and try the command again it's successful. 
> Is it possible that it needs time to activate? It's a LVM array. But my /tmp and swap is encrypted at boot and they works (I hope =) )
> 
> My setup is
> sda1 -> LVM -> dm_crypt -> xfs
> 
> //Martin

> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt


-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

Re: [dm-crypt] Password is not accepted

[Karl O. Pinc]

On 09/20/2011 06:43:54 PM, Arno Wagner wrote:
> Very strange indeed. Is this repeatable?

This is strictly an FYI in case anyone's interested.

This seems like a good time to mention a similar strange
issue.  I've chalked it up to too-new hardware and have
yet to try with the latest kernel.org kernel, but running
Debian Squeeze, with either the stock 2.6.32 kernel or the
backports 2.6.39 kernel I see failure to enter the
luks password.  This is on an Acer Aspire One D255E-13647
with a manufacture date of 2011-01.

This is all driven by the initramfs.  What happens is that,
sometimes, the screen goes black for perhaps 15 or more
seconds starting about 3 or 4 seconds after the luks
password prompt.  Attempts to enter the password or portion
thereof during this time always result in failure.
I believe I've seen the same problem without the screen
going black as well.  If I wait a long time to enter the
password all is well.

In any case I've not tracked the details closely and 
am waiting until I get around to trying a newer kernel 
to see if the problem goes away.

> Meybe a thermal issue with RAM, CPU or PSU that has the
> password iterations fail when cold and work when warmed 
> up? For CPU/RAM this would be strance as cold CMOS 
> circuits work better than hot ones. For the PSU, it
> is possible that failing capacitors reconstiture a bit
> after warm up. Anyways, sounds like a hardware issue to 
> me.
> 
> Arno
> 
> On Tue, Sep 20, 2011 at 09:13:32PM +0200, Ask Me wrote:
> > Hi
> > 
> > Now I'm having a strange problem. First I thought that I was 
> getting
> old and had forgot my password but now it happens more then once.
> > 
> > When I reboot my computer and try to open my encrypted device with
> "cryptsetup luksOpen /dev/vg_home/home_private lv_encr" I get the
> message that my password is not accepted.
> > But if I reboot it again and wait for a few minutes and try the
> command again it's successful. 
> > Is it possible that it needs time to activate? It's a LVM array. 
> But
> my /tmp and swap is encrypted at boot and they works (I hope =) )
> > 
> > My setup is
> > sda1 -> LVM -> dm_crypt -> xfs
> > 
> > //Martin
> 
> > _______________________________________________
> > dm-crypt mailing list
> > dm-crypt@saout.de
> > http://www.saout.de/mailman/listinfo/dm-crypt
> 
> 
> -- 
> Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email:
> arno@wagner.name 
> GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50
> 1E25 338F
> ----
> Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans
> 
> If it's in the news, don't worry about it.  The very definition of 
> "news" is "something that hardly ever happens." -- Bruce Schneier 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
> 
> 




Karl <kop@meme.com>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein

Re: [dm-crypt] Password is not accepted

[Milan Broz]

On 09/21/2011 04:03 AM, Karl O. Pinc wrote:

> This is all driven by the initramfs.  What happens is that,
> sometimes, the screen goes black for perhaps 15 or more
> seconds starting about 3 or 4 seconds after the luks
> password prompt.  Attempts to enter the password or portion
> thereof during this time always result in failure.
> I believe I've seen the same problem without the screen
> going black as well.  If I wait a long time to enter the
> password all is well.

I had problems with late reset of usb devices
(with connected usb keyboard).

When I start to enter passphrase (in initramfs), usb kernel
module resets usb devices (perhaps just initialization)
and usually it cause lost of some entered characters.

Waiting few seconds helps - maybe this is the similar case
or just problem with another hw interfering (like gpu).

To debug such issues - boot kernel, intramfs (dracut or whatever
it is) with full debug to console, check what is logged
immediately before it happens.
(If it is too quick, just use some camera and record screen
or log it to serial console.)

With passphrase entered in late init where things run in
parallel (like systemd these days) even more magic can happen;-)

Milan

Re: [dm-crypt] Password is not accepted

[ken]

On 09/20/2011 11:05 PM Milan Broz wrote:
> On 09/21/2011 04:03 AM, Karl O. Pinc wrote:
> 
>> This is all driven by the initramfs.  What happens is that,
>> sometimes, the screen goes black for perhaps 15 or more
>> seconds starting about 3 or 4 seconds after the luks
>> password prompt.  Attempts to enter the password or portion
>> thereof during this time always result in failure.
>> I believe I've seen the same problem without the screen
>> going black as well.  If I wait a long time to enter the
>> password all is well.
> 
> I had problems with late reset of usb devices
> (with connected usb keyboard).
> 
> When I start to enter passphrase (in initramfs), usb kernel
> module resets usb devices (perhaps just initialization)
> and usually it cause lost of some entered characters.
> 
> Waiting few seconds helps - maybe this is the similar case
> or just problem with another hw interfering (like gpu).
> 
> To debug such issues - boot kernel, intramfs (dracut or whatever
> it is) with full debug to console, check what is logged
> immediately before it happens.
> (If it is too quick, just use some camera and record screen
> or log it to serial console.)
> 
> With passphrase entered in late init where things run in
> parallel (like systemd these days) even more magic can happen;-)
> 
> Milan

Is there a way to determine if the USB connection to the encrypted disk 
is good... so that it won't drop any characters in the passphrase? 
E.g., how about running an "fdisk -l" on the drive first, then running 
the "cryptsetup" command?

Better: Is there perhaps an option to cryptsetup (just for testing of 
course) which would make it echo back the passphrase it received...? 
just to ensure that it received what I intended?