Re: Passphrase protected key file?

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

 



On Thu, Jul 14, 2011 at 11:10:09AM +0200, Ma Begaj wrote:
> 2011/7/12 Arno Wagner <arno@xxxxxxxxxxx>:
> > On Mon, Jul 11, 2011 at 11:17:32PM +0100, Laurence Darby wrote:
> >> Hello,
> >>
> >> My next question, what's the best way to have a passphrase
> >> protected key file?
> >
> > Whyever woyld you want one? If you already have a passphrase,
> > use that directly. The passphrase-in-file option is
> > for slaved devices and keys stored in hardware with some
> > additional protection by the hardware, e.g. keys on a chipcard.
> > Key storage on the device itself is actually a pretty much
> > unsolved problem. The onluy way to do it with a reasonable
> > level of security today is with costly HSMs (hardware
> > security modules) that have things like their own power,
> > extensive sensors, armoured consruction ans the like.
> > Expect to pay >= 50'000 EUR/USD for one that offers
> > reasonable security.
> >
> >> Should I encrypt it with GPG, and then do eg:
> >>
> >> ?gpg -d ~/pass_key ?| cryptsetup luksOpen --key-file - /dev/loop1 loop1
> >>
> >> That has the advantage of using the same passphrase I use for
> >> everything else, but is there any security risk I'm not seeing?
> >
> > Yes, you should not reuse passphrases. If you do, of it is exposed
> > in one place, everything else is exposed. That said, I do
> > realize having a good passphrase and using it _carefully_ in
> > several places is better than having several bad passphrases.
> > Just make sure you always think about who could evasdrop before
> > you enter it. For example, never use your passphrase on a
> > computer not under your control. If you need to do that
> > (e.e. external storage device), use a dedicated one that
> > you use nowhere else.
> >
> >> I read
> >> that encrypting something twice or with multiple ciphers is effectively
> >> a new unknown cipher, potentially trivially breakable - I don't think
> >> that applies here, but is there anything like that I need to watch out for?
> >
> > If you have _independent_ keys, it usually is as strong as the
> > stronger cipher/key combination. With dependent or the same keys,
> > this warning is correct. Example: Using a stream cipher twice with
> > the same key gives you the plaintext as encryption result.
> >
> >> Alternatively, I could just do this:
> >>
> >> ( cat ~/pass_key ; cat ) | cryptsetup luksOpen --key-file - /dev/loop1 loop1
> >>
> >> so I still have to provide both the key and passphrase, terminated with
> >> Ctrl-D. ?Any thoughts?
> >
> > Yes, why do you not use the passphrase entry function of cryptsetup
> > directly? Without a specific and credible risk, there is no
> > reason to do anything of what you describe here...
> 
> 
> everything you say is absolutely logical but having a key in an encrypted
> file creates under some conditions a more secure environment. you could
> keep a file on an usb stick:
> 
> a person will need usb stick AND password for decrypting a luks device

Yes. But since that USB stick does have to be connected to the
same device as the encrypted storage, that does not make it 2-factor.
Also note that an attacker that has access to the storage could
patch your GnuPG binary or other system components.

> and
> 
> loosing usb stick is not security problem

Indeed. But in the ordinary scenario it is not either,
as there is no USB stick.

My take is that you do not get higher security in most 
real scenarios.

Arno
-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@xxxxxxxxxxx 
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@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt


[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