Re: Result of supplying an incorrect passphrase?

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

 



Not a bad idea, and if I understand you right, you aren't trying to prevent an attacker from guessing so much as you are giving the user a quick method to render the device unrecoverable.

However; because there would be a specific password needed to tell cryptsetup to essentially "shred" the key sector, that shred password would have to be added onto the header information of the device, probably in hash, and would increase the required header size.

That might make cause issues with backwards compatibility. I don't know enough about how sensitive cryptsetup is to header size/information.

-MJ

On Wed, 15 Jul 2009 10:23:30 +0000
Matt Rosales <ttammar@xxxxxxxxx> wrote:

> On a somewhat related note, I was thinking it would be cool to build in a
> self-destruct mechanism into cryptsetup- IE if a specific password is
> entered twice, have it destroy the keyblock of the encrypted disk. Thoughts?
> 
> On Tue, Jul 14, 2009 at 3:19 PM, Robert Lummis <robert.lummis@xxxxxxxxx>wrote:
> 
> > OK I guess I need to be using LUKS. That's fine.
> >
> > I don't see what's to explore about /dev/mapper/$x. If I give the
> > wrong passphrase the expected file name still appears there with the
> > expected permissions. The only way I see to find out if the passphrase
> > was ok is to try to read it. That's not so terrible but seems kinda
> > lame.
> >
> > On Tue, Jul 14, 2009 at 4:21 AM, Roscoe<eocsor@xxxxxxxxx> wrote:
> > >> I would like a way to tell cryptsetup to fail completely (don't change
> > >> anything and return non-zero) if the passphrase is wrong. Is that
> > >> possible?
> > >
> > > Sure, start using LUKS :)
> > >
> > > Otherwise, AFAIK without LUKS there is no way for cryptsetup to tell.
> > > (The normal workaround for this being to then inspect /dev/mapper/$x
> > > for a known filesystem afterwards.)
> > >
> > > -- Roscoe
> > >
> > > ---------------------------------------------------------------------
> > > dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/
> > > To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx
> > > For additional commands, e-mail: dm-crypt-help@xxxxxxxx
> > >
> > >
> >
> >
> >
> > --
> > Robert Lummis
> >
> > ---------------------------------------------------------------------
> > dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/
> > To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx
> > For additional commands, e-mail: dm-crypt-help@xxxxxxxx
> >
> >
> 
> 

---------------------------------------------------------------------
dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/
To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx
For additional commands, e-mail: dm-crypt-help@xxxxxxxx


[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux