All of lore.kernel.org
 help / color / mirror / Atom feed
* [dm-crypt] passfrase or dev_random for keyfile of a dmcrypt_swap
@ 2010-04-19 16:37 Si St
  2010-04-19 16:54 ` Arno Wagner
                   ` (2 more replies)
  0 siblings, 3 replies; 10+ messages in thread
From: Si St @ 2010-04-19 16:37 UTC (permalink / raw)
  To: dm-crypt

What should be recommended:

To apply either /dev/random or a passfrase for the establishment of a keyfile to a swap partition?
I am thinking about a potential crash and the consequences if the swap partition has to be used for rebuild of something. Then a /dev/random or if necessary /dev/urandom would not be so good.



-- 
_______________________________________________
Surf the Web in a faster, safer and easier way:
Download Opera 9 at http://www.opera.com

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dm-crypt] passfrase or dev_random for keyfile of a dmcrypt_swap
  2010-04-19 16:37 [dm-crypt] passfrase or dev_random for keyfile of a dmcrypt_swap Si St
@ 2010-04-19 16:54 ` Arno Wagner
  2010-04-19 19:01 ` Heinz Diehl
  2010-04-20  5:41 ` Luca Berra
  2 siblings, 0 replies; 10+ messages in thread
From: Arno Wagner @ 2010-04-19 16:54 UTC (permalink / raw)
  To: dm-crypt

On Mon, Apr 19, 2010 at 05:37:45PM +0100, Si St wrote:
> What should be recommended:

> 
> To apply either /dev/random or a passfrase for the establishment of a
> keyfile to a swap partition?

Allways /dev/random, unless you have a low-entropy scenario,
in which you may have to combine it with a stored and updated
seed.

> I am thinking about a potential crash and the consequences if the swap
> partition has to be used for rebuild of something. Then a /dev/random or
> if necessary /dev/urandom would not be so good.

The swap partition is not used in reconstructing things under
Linux.
 
Arno
-- 
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 

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dm-crypt] passfrase or dev_random for keyfile of a dmcrypt_swap
  2010-04-19 16:37 [dm-crypt] passfrase or dev_random for keyfile of a dmcrypt_swap Si St
  2010-04-19 16:54 ` Arno Wagner
@ 2010-04-19 19:01 ` Heinz Diehl
  2010-04-20  5:41 ` Luca Berra
  2 siblings, 0 replies; 10+ messages in thread
From: Heinz Diehl @ 2010-04-19 19:01 UTC (permalink / raw)
  To: dm-crypt

On 19.04.2010, Si St wrote: 

> I am thinking about a potential crash and the consequences if the swap partition has to be used for rebuild of something. 
> Then a /dev/random or if necessary /dev/urandom would not be so good.

In this case, the only way to go is to have a passphrase, a randomly
generated key means you're locked out after the partition is closed.

Another possibility, if this sounds acceptable for you, is to pre-generate
a keyfile which resides on the root partition (and you keep a backup of it
on a safe place somwhere outside this machine), which is then used to
automatically unlock the swap partition in the boot process.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dm-crypt] passfrase or dev_random for keyfile of a dmcrypt_swap
  2010-04-19 16:37 [dm-crypt] passfrase or dev_random for keyfile of a dmcrypt_swap Si St
  2010-04-19 16:54 ` Arno Wagner
  2010-04-19 19:01 ` Heinz Diehl
@ 2010-04-20  5:41 ` Luca Berra
  2 siblings, 0 replies; 10+ messages in thread
From: Luca Berra @ 2010-04-20  5:41 UTC (permalink / raw)
  To: dm-crypt

On Mon, Apr 19, 2010 at 05:37:45PM +0100, Si St wrote:
>What should be recommended:
>
>To apply either /dev/random or a passfrase for the establishment of a keyfile to a swap partition?
>I am thinking about a potential crash and the consequences if the swap partition has to be used for rebuild of something. Then a /dev/random or if necessary /dev/urandom would not be so good.

Unless you use swap for suspending to disk you can recreate it at boot
using /dev/random, I do not particularly like the doing that tough.
Since devices and partition have a tendency to change name under linux,
it is fairly possible that you shoot yourself in the feet for no
particular advantage.

L.

-- 
Luca Berra -- bluca@comedia.it
         Communication Media & Services S.r.l.
  /"\
  \ /     ASCII RIBBON CAMPAIGN
   X        AGAINST HTML MAIL
  / \

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dm-crypt] passfrase or dev_random for keyfile of a dmcrypt_swap
  2010-04-21  8:34 ` Heinz Diehl
@ 2010-04-21  9:06   ` Jonas Meurer
  0 siblings, 0 replies; 10+ messages in thread
From: Jonas Meurer @ 2010-04-21  9:06 UTC (permalink / raw)
  To: dm-crypt

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

On 21/04/2010 Heinz Diehl wrote:
> On 20.04.2010, Si St wrote: 
> 
> > To Heinz: Would not a pre-generated keyfile need to be opened by a passfrase?
> 
> No, the keyfile itself is the "passphrase". I'm not talking about the
> master key here, what I mean is something like
> 
>  dd if=/dev/urandom of=keyfile bs=64 count=1
>  cryptsetup luksFormat /dev/sdx /path/to/keyfile
>  
> You could now e.g. do something like
> 
>  swap /dev/sdx /path/to/keyfile swap
>  
> in your crypttab, save the keyfile somewhere on the encrypted root
> partition and open the swapspace using a bootscript after your root partition 
> has been mapped. You could then backup the keyfile in a safe place and use
> it to map the swap partition manually if desired (in the scenario you
> described).

it should be noted that this setup is unsafe without encrypted root
partition.

greetings,
 jonas

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dm-crypt] passfrase or dev_random for keyfile of a dmcrypt_swap
  2010-04-20 14:15 Si St
  2010-04-20 15:15 ` Arno Wagner
@ 2010-04-21  8:34 ` Heinz Diehl
  2010-04-21  9:06   ` Jonas Meurer
  1 sibling, 1 reply; 10+ messages in thread
From: Heinz Diehl @ 2010-04-21  8:34 UTC (permalink / raw)
  To: dm-crypt

On 20.04.2010, Si St wrote: 

> To Heinz: Would not a pre-generated keyfile need to be opened by a passfrase?

No, the keyfile itself is the "passphrase". I'm not talking about the
master key here, what I mean is something like

 dd if=/dev/urandom of=keyfile bs=64 count=1
 cryptsetup luksFormat /dev/sdx /path/to/keyfile
 
You could now e.g. do something like

 swap /dev/sdx /path/to/keyfile swap
 
in your crypttab, save the keyfile somewhere on the encrypted root
partition and open the swapspace using a bootscript after your root partition 
has been mapped. You could then backup the keyfile in a safe place and use
it to map the swap partition manually if desired (in the scenario you
described).

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dm-crypt] passfrase or dev_random for keyfile of a dmcrypt_swap
  2010-04-20 18:06 Si St
@ 2010-04-20 19:14 ` Arno Wagner
  0 siblings, 0 replies; 10+ messages in thread
From: Arno Wagner @ 2010-04-20 19:14 UTC (permalink / raw)
  To: dm-crypt

Nice find! Yes, that is the issue and a solution.

Arno

On Tue, Apr 20, 2010 at 07:06:12PM +0100, Si St wrote:
> 
> > QUESTION: But in case I would have to use a seed, how is this done?
> > Especially with an UPDATED seed? This I do not know.
> 
> Advanced practical crypto implementation. What you do is, you store
> some entropy on system shutdown to use at the next start together
> with the best you can get at the start. On first start you are
> screwed, buut for swap it is less critical. For exaple done by
> GnuPG, in the form of $HOME/gnupg/random_seed.
> 
> Arno
> 
> SiSt:
> 
> I assume that I am close to the understanding of your point here, with this
> excerpt from the urandom manual(?):
> 
> When a Linux system starts up without much operator interaction, the entropy
> pool may be in a fairly  predictable  state.   This reduces  the  actual
> amount  of  noise in the entropy pool below the estimate.  In order to
> counteract this effect, it helps to carry entropy pool information across
> shut-downs and start-ups.  To do this, add the following lines to  an
> appropriate  script which is run during the Linux system start-up sequence:
> 
>            echo "Initializing random number generator..."
>            random_seed=/var/run/random-seed
>            # Carry a random seed from start-up to start-up
>            # Load and then save the whole entropy pool
>            if [ -f $random_seed ]; then
>                cat $random_seed >/dev/urandom
>            else
>                touch $random_seed
>            fi
>            chmod 600 $random_seed
>            poolfile=/proc/sys/kernel/random/poolsize
>            [ -r $poolfile ] && bytes=`cat $poolfile` || bytes=512
>            dd if=/dev/urandom of=$random_seed count=1 bs=$bytes
> 
>        Also, add the following lines in an appropriate script which is run
> during the Linux system shutdown:
> 
>            # Carry a random seed from shut-down to start-up
>            # Save the whole entropy pool
>            echo "Saving random seed..."
>            random_seed=/var/run/random-seed
>            touch $random_seed
>            chmod 600 $random_seed
>            poolfile=/proc/sys/kernel/random/poolsize
>            [ -r $poolfile ] && bytes=`cat $poolfile` || bytes=512
>            dd if=/dev/urandom of=$random_seed count=1 bs=$bytes
> 
> 
> -- 
> _______________________________________________
> Surf the Web in a faster, safer and easier way:
> Download Opera 9 at http://www.opera.com
> 
> _______________________________________________
> 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 

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dm-crypt] passfrase or dev_random for keyfile of a dmcrypt_swap
@ 2010-04-20 18:06 Si St
  2010-04-20 19:14 ` Arno Wagner
  0 siblings, 1 reply; 10+ messages in thread
From: Si St @ 2010-04-20 18:06 UTC (permalink / raw)
  To: dm-crypt


> QUESTION: But in case I would have to use a seed, how is this done?
> Especially with an UPDATED seed? This I do not know.

Advanced practical crypto implementation. What you do is, you store
some entropy on system shutdown to use at the next start together
with the best you can get at the start. On first start you are
screwed, buut for swap it is less critical. For exaple done by
GnuPG, in the form of $HOME/gnupg/random_seed.

Arno

SiSt:

I assume that I am close to the understanding of your point here, with this
excerpt from the urandom manual(?):

When a Linux system starts up without much operator interaction, the entropy
pool may be in a fairly  predictable  state.   This reduces  the  actual
amount  of  noise in the entropy pool below the estimate.  In order to
counteract this effect, it helps to carry entropy pool information across
shut-downs and start-ups.  To do this, add the following lines to  an
appropriate  script which is run during the Linux system start-up sequence:

           echo "Initializing random number generator..."
           random_seed=/var/run/random-seed
           # Carry a random seed from start-up to start-up
           # Load and then save the whole entropy pool
           if [ -f $random_seed ]; then
               cat $random_seed >/dev/urandom
           else
               touch $random_seed
           fi
           chmod 600 $random_seed
           poolfile=/proc/sys/kernel/random/poolsize
           [ -r $poolfile ] && bytes=`cat $poolfile` || bytes=512
           dd if=/dev/urandom of=$random_seed count=1 bs=$bytes

       Also, add the following lines in an appropriate script which is run
during the Linux system shutdown:

           # Carry a random seed from shut-down to start-up
           # Save the whole entropy pool
           echo "Saving random seed..."
           random_seed=/var/run/random-seed
           touch $random_seed
           chmod 600 $random_seed
           poolfile=/proc/sys/kernel/random/poolsize
           [ -r $poolfile ] && bytes=`cat $poolfile` || bytes=512
           dd if=/dev/urandom of=$random_seed count=1 bs=$bytes


-- 
_______________________________________________
Surf the Web in a faster, safer and easier way:
Download Opera 9 at http://www.opera.com

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dm-crypt] passfrase or dev_random for keyfile of a dmcrypt_swap
  2010-04-20 14:15 Si St
@ 2010-04-20 15:15 ` Arno Wagner
  2010-04-21  8:34 ` Heinz Diehl
  1 sibling, 0 replies; 10+ messages in thread
From: Arno Wagner @ 2010-04-20 15:15 UTC (permalink / raw)
  To: dm-crypt

On Tue, Apr 20, 2010 at 03:15:06PM +0100, Si St wrote:
> To Arno: 
> 
> I tried first a regular LUKS partition as swap with passfrase. This of
> course worked. I assume that ArnoWagners comment : "Allways /dev/random,
> unless you have a low-entropy scenario" is for the general understanding
> that urandom is not random but bound to predictable math calculation. Or
> does ArnoWagner mean: opposed to a passphrase ? In the last instance it is
> of course safer with /dev/random since nobody has read the output of that
> blockfile except the machine(Rechner) itself.  So far my understanding if
> it is right.

Both ;-) I mean that /dev/urandom is problematic in a low-entropy 
scenario and that passphrase should not be used for swap. 

Incidentially, it is a "passphrase".

> To change from passfrase to dev_random I experienced that the partition
> had to be zeroed with dd. Else it seemed like the LUKS-header was read and
> asking for passfrase which did not work, and at the same time rejecting
> the none-regular-file /dev/random with a message about that matter. This
> of course is in consistency with the mechanism of LUKS-extension mentioned
> under "DESCRIPTION" at a site like:
> http://pwet.fr/man/linux/formats/crypttab
 
Hmm. You do not need (or want) LUKS for swap. Plain dm-crypt
is better.

>  But I could get hold of the swap by:
> 
> cryptsetup -d /dev/random create _swap /dev/hdc11
> mkswap /dev/mapper/_swap
> swapon -a

That would be the way to do it.
 
> But not with restart before or after this event just by 
> changing the files to:
> 
> /etc/crypttab(1):
> _swap /dev/hdc11 /dev/random swap,cipher=aes-cbc-essiv:sha256
> /etc/fstab:
> dev/mapper/_swap swap swap defaults 0 0 

I think I had this working with the following fstab line:

  /dev/mapper/_swap        none            swap sw 0 0

> But reediting the tab-files 
> /etc/crypttab(2):
> _swap /dev/hdc11 none swap
> 
> and restarting again the machine, I got hold of the swap-partition with
> the previous passfrase like before, so mkswap probably do not overwrite
> the 592 bytes luks-header and the AF splitted keys(?) Or is there another
> explanation for this like with /dev/mapper_swap or that the swap had not
> yet at that moment come into use, so I was just lucky?

mkswap writes very little.  However, cryptsetup -d /dev/random creates
a plain dm-crypt device, no LUKS header involved. 

> QUESTION: 
> Would it suffice to erase the luks-magic with 
> dd if=/dev/zero of=/dev/hdc11 bs=1 count=6
> to make the crypttab and fstab work without zeroing out the partition first?

It should work without that.

> IN ALL: The swap after zeroing with dd on the partition in question works
> with the crypttab(1) above, and as follows there ARE sufficient entropy
> available to make up a key, so far. As to the config of fstab and crypttab
> I followed the assignment from this site:
> https://www.antagonism.org/privacy/encrypted-swap-linux.shtml
>
> QUESTION: But in case I would have to use a seed, how is this done?
> Especially with an UPDATED seed? This I do not know.

Advanced practical crypto implementation. What you do is, you store
some entropy on system shutdown to use at the next start together
with the best you can get at the start. On first start you are 
screwed, buut for swap it is less critical. For exaple done by 
GnuPG, in the form of $HOME/gnupg/random_seed.

Arno 
-- 
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 

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dm-crypt] passfrase or dev_random for keyfile of a dmcrypt_swap
@ 2010-04-20 14:15 Si St
  2010-04-20 15:15 ` Arno Wagner
  2010-04-21  8:34 ` Heinz Diehl
  0 siblings, 2 replies; 10+ messages in thread
From: Si St @ 2010-04-20 14:15 UTC (permalink / raw)
  To: dm-crypt

To Arno: 

I tried first a regular LUKS partition as swap with passfrase. This of course
worked. I assume that ArnoWagners comment : "Allways /dev/random, unless you
have a low-entropy scenario" is for the general understanding that
urandom is not random but bound to predictable math calculation. Or does
ArnoWagner mean: opposed to a passphrase ? In the last instance it is of course
safer with /dev/random since nobody has read the output of that blockfile
except the machine(Rechner) itself.  So far my understanding if it is right.

To change from passfrase to dev_random I experienced that the partition had to
be zeroed with dd. Else it seemed like the LUKS-header was read and asking for
passfrase which did not work, and at the same time rejecting the
none-regular-file /dev/random with a message about that matter. This of course
is in consistency with the mechanism of LUKS-extension mentioned under
"DESCRIPTION" at a site like: 
http://pwet.fr/man/linux/formats/crypttab

 But I could get hold of the swap by:

cryptsetup -d /dev/random create _swap /dev/hdc11
mkswap /dev/mapper/_swap
swapon -a

But not with restart before or after this event just by changing the files to:

/etc/crypttab(1):
_swap /dev/hdc11 /dev/random swap,cipher=aes-cbc-essiv:sha256
/etc/fstab:
dev/mapper/_swap swap swap defaults 0 0 

But reediting the tab-files 
/etc/crypttab(2):
_swap /dev/hdc11 none swap

and restarting again the machine, I got hold of the swap-partition with the
previous passfrase like before, so mkswap probably do not overwrite the 592
bytes luks-header and the AF splitted keys(?) Or is there another explanation
for this like with /dev/mapper_swap or that the swap had not yet at that moment
come into use, so I was just lucky?

QUESTION: 
Would it suffice to erase the luks-magic with 
dd if=/dev/zero of=/dev/hdc11 bs=1 count=6
to make the crypttab and fstab work without zeroing out the partition first?

IN ALL: The swap after zeroing with dd on the partition in question works with
the crypttab(1) above, and as follows there ARE sufficient entropy available to
make up a key, so far. As to the config of fstab and crypttab I followed the 
assignment from this site:
https://www.antagonism.org/privacy/encrypted-swap-linux.shtml

QUESTION: But in case I would have to use a seed, how is this done? Especially
with an UPDATED seed? This I do not know.

To Heinz: Would not a pre-generated keyfile need to be opened by a passfrase?

(Off the subject to HeinzDiehl: Hear you are a well reputated bestyrer at
sjukeheimen, and that you impressingly learned the language BEFORE entering the
country. Und weiter: Haben Sie Ihr Deutsch vergessen nach so vielen Jahren in
dem Lande?)

SiSt
____________________________________________________________________________
From: "Heinz Diehl" <htd@fancy-poultry.org>
On 19.04.2010, Si St wrote:

> I am thinking about a potential crash and the consequences if the 
> swap partition has to be used for rebuild of something. Then a 
> /dev/random or if necessary /dev/urandom would not be so good.

In this case, the only way to go is to have a passphrase, a randomly
generated key means you're locked out after the partition is closed.

Another possibility, if this sounds acceptable for you, is to pre-generate
a keyfile which resides on the root partition (and you keep a backup of it
on a safe place somwhere outside this machine), which is then used to
automatically unlock the swap partition in the boot process.

---------------------------------------------------------------
From: "Arno Wagner" <arno@wagner.name>  
On Mon, Apr 19, 2010 at 05:37:45PM +0100, Si St wrote:
> What should be recommended:

>
> To apply either /dev/random or a passfrase for the establishment of a
> keyfile to a swap partition?

Allways /dev/random, unless you have a low-entropy scenario,
in which you may have to combine it with a stored and updated
seed.

> I am thinking about a potential crash and the consequences if the swap
> partition has to be used for rebuild of something. Then a /dev/random or
> if necessary /dev/urandom would not be so good.

The swap partition is not used in reconstructing things under
Linux.

Arno
--
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

-- 
_______________________________________________
Surf the Web in a faster, safer and easier way:
Download Opera 9 at http://www.opera.com

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2010-04-21  9:07 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-04-19 16:37 [dm-crypt] passfrase or dev_random for keyfile of a dmcrypt_swap Si St
2010-04-19 16:54 ` Arno Wagner
2010-04-19 19:01 ` Heinz Diehl
2010-04-20  5:41 ` Luca Berra
2010-04-20 14:15 Si St
2010-04-20 15:15 ` Arno Wagner
2010-04-21  8:34 ` Heinz Diehl
2010-04-21  9:06   ` Jonas Meurer
2010-04-20 18:06 Si St
2010-04-20 19:14 ` Arno Wagner

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.