[dm-crypt] System comes up very slowly

[dm-crypt] System comes up very slowly

[Ross Boylan]

When my computer reboots it shows the grub menu and some initial messages
from the kernel loading and then waits a very long time (minutes) before
asking for the pass-phrase for the main partition.

I speculate the delay is to gather randomness for the 2 random-encrypted
swap partitions.  However, hitting keys doesn't seem to speed it up.

Is this speculation reasonable?

If not, what might be the cause of the delay?

If the delay is from the encrypted swap, is there anything I can do about
it short of eliminating the swap?  Is there any reason to avoid using a
fixed key for the swap?  Fixed keys sound as if they should eliminate the
need for randomness from the system.

[slightly off-topic]
Is it still the case that encrypted swap limits the ability to suspend or
hibernate and resume?

Thanks.
Ross Boylan

Details that might matter:
Xeon CPUs from a few years ago.
The boot and main partitions are RAID1.
The main partition is the physical volume behind an LVM volume group;
encryption is on some individual logical volumes, including the one
holding the root file system.

Re: [dm-crypt] System comes up very slowly

[Arno Wagner]

On Sat, Sep 27, 2014 at 06:01:19 CEST, Ross Boylan wrote:
> When my computer reboots it shows the grub menu and some initial messages
> from the kernel loading and then waits a very long time (minutes) before
> asking for the pass-phrase for the main partition.
> 
> I speculate the delay is to gather randomness for the 2 random-encrypted
> swap partitions.  However, hitting keys doesn't seem to speed it up.
> 
> Is this speculation reasonable?

It depends. Doing randomness gathering right is difficult. It
always is a trade-off between quelity and speed. If you look
through the mailing-list archives, you find sevveral long
discussions about this.

That said, current cryptsetup defaults to /dev/urandom, which 
gives you randomness even if entropy is low (which may be 
insecure). We decided to use the fast option and to warn 
people in the man-pages. You can check the defaults with
"cryptsetup --help", at the end it tells you the used
CPRNG. 

There is a second aspect: Any sane distribution keeps some
entropy on reboot and uses that to jump-start /dev/(u)random.
For this some entropy is stored in a file on shutdown and
then piped _into_ /dev/urandom on startup, hence avoiding
entropy starvation. "man random" gives a detailed example
on how to do that.

You should check the following things:
- is cryptsetup compiled with /dev/urandom or /dev/random ad default?
- is cryptsetup called with "--use-random"?
- is /dev/(u)random initialized during boot?

> If not, what might be the cause of the delay?

A filesystem check, a raid-check, some very slow-to-detect device,
wiping of the swap, etc.
 
> If the delay is from the encrypted swap, is there anything I can do about
> it short of eliminating the swap?  Is there any reason to avoid using a
> fixed key for the swap?  Fixed keys sound as if they should eliminate the
> need for randomness from the system.

Do not use fixed-keys! They will be available to an attacker. 
The whole point of random keys for swap is that they are
non-predictable and non-recoverable, yet you do not need 
to enter them manually. Fixed keys break that.

What you can do is to implement entropy-storage over reboot
according to the (u)random man-page and to tell cryptsetup
exolicitly to use /dev/urandom for the swap (--use-urandom).
That should elieminate the wainting if key-generationf or swap 
is the issue.


> [slightly off-topic]
> Is it still the case that encrypted swap limits the ability to suspend or
> hibernate and resume?

Depends on the distro, I guess. But using encrypted swap that
way is insecure, as an attacker can easily get access to it,
and so it is not a good idea. For standard attacks (e.g. over
firewire) a machine suspended/hibernated this way is wide open.
Encrypted swap is worthless unless a full power-off is performed,
you cannot have it easy _and_ secure in this case.

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
----
A good decision is based on knowledge and not on numbers. -- Plato

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] System comes up very slowly

[Ross Boylan]

On Sat, Sep 27, 2014 at 12:19:18PM +0200, Arno Wagner wrote:
> On Sat, Sep 27, 2014 at 06:01:19 CEST, Ross Boylan wrote:
> > When my computer reboots it shows the grub menu and some initial messages
> > from the kernel loading and then waits a very long time (minutes) before
> > asking for the pass-phrase for the main partition.
> > 
> > I speculate the delay is to gather randomness for the 2 random-encrypted
> > swap partitions.  However, hitting keys doesn't seem to speed it up.
> > 
> > Is this speculation reasonable?
> 
> It depends. Doing randomness gathering right is difficult. It
> always is a trade-off between quelity and speed. If you look
> through the mailing-list archives, you find sevveral long
> discussions about this.
> 
> That said, current cryptsetup defaults to /dev/urandom, which 
> gives you randomness even if entropy is low (which may be 
> insecure). We decided to use the fast option and to warn 
> people in the man-pages. You can check the defaults with
> "cryptsetup --help", at the end it tells you the used
> CPRNG. 

I'm running crypsetup 1.0.6 on Debian Lenny; neither --help nor
--version seems to give any info on the random source.

I'm asking becaue I'm about to convert the system to wheezy and have
the opportunity to change things.  I presume this will generate an
initrd with the wheezy version, 1.4.3, which uses urandom according to
its --help.

> 
> There is a second aspect: Any sane distribution keeps some
> entropy on reboot and uses that to jump-start /dev/(u)random.
> For this some entropy is stored in a file on shutdown and
> then piped _into_ /dev/urandom on startup, hence avoiding
> entropy starvation. "man random" gives a detailed example
> on how to do that.
> 
> You should check the following things:
> - is cryptsetup compiled with /dev/urandom or /dev/random ad
> default?
I can check the source code.  Where is this determined?

> - is cryptsetup called with "--use-random"?

Is this a question about how it is called from within the initrd?
Actually, it may not matter since the man page for this version does
not indicate a --use-random option.

> - is /dev/(u)random initialized during boot?
Judging from /etc/init.d/urandom, yes.

> 
> > If not, what might be the cause of the delay?
> 
> A filesystem check, a raid-check, some very slow-to-detect device,
> wiping of the swap, etc.
OK.  I take it entropy starvation for the swap is the only crypto
related possible cause of the delay, given that I have not switched to
slower processors.  There are 2 swap partitions.

Hmm, the other thing that might be relevant is that there are 7 non-swap
encrypted logical volumes.  /etc/crypttab lists root first, then the
2 swaps, and then 6 other LV's.  For most of them the relevant key is
in the 2nd slot.  The pass-phrase prompt is for the root device.

>  
> > If the delay is from the encrypted swap, is there anything I can do about
> > it short of eliminating the swap?  Is there any reason to avoid using a
> > fixed key for the swap?  Fixed keys sound as if they should eliminate the
> > need for randomness from the system.
> 
> Do not use fixed-keys! They will be available to an attacker. 
> The whole point of random keys for swap is that they are
> non-predictable and non-recoverable, yet you do not need 
> to enter them manually. Fixed keys break that.
> 
Why are the fixed keys for swap any more available than fixed keys
for other devices/partitions?

> What you can do is to implement entropy-storage over reboot
> according to the (u)random man-page and to tell cryptsetup
> exolicitly to use /dev/urandom for the swap (--use-urandom).
> That should elieminate the wainting if key-generationf or swap 
> is the issue.
> 
> 
> > [slightly off-topic]
> > Is it still the case that encrypted swap limits the ability to suspend or
> > hibernate and resume?
> 
> Depends on the distro, I guess. But using encrypted swap that
> way is insecure, as an attacker can easily get access to it,
> and so it is not a good idea. For standard attacks (e.g. over
> firewire) a machine suspended/hibernated this way is wide open.
> Encrypted swap is worthless unless a full power-off is performed,
> you cannot have it easy _and_ secure in this case.
I think this means, for random-encrypted swap:
eencrypted swap + system shutdown and power off is secure
ecnrypted swap + suspend (system alive but low power) is insecure
What does it mean for encrypted swap + hibernate (power is off but
system state is saved to disk)?

Not sure if I have the suspend/hibernate lingo right.  I think those
are MS-Windows terms.

Ross

Re: [dm-crypt] System comes up very slowly

[Arno Wagner]

On Sat, Sep 27, 2014 at 21:39:30 CEST, Ross Boylan wrote:
> On Sat, Sep 27, 2014 at 12:19:18PM +0200, Arno Wagner wrote:
> > On Sat, Sep 27, 2014 at 06:01:19 CEST, Ross Boylan wrote:
> > > When my computer reboots it shows the grub menu and some initial messages
> > > from the kernel loading and then waits a very long time (minutes) before
> > > asking for the pass-phrase for the main partition.
> > > 
> > > I speculate the delay is to gather randomness for the 2 random-encrypted
> > > swap partitions.  However, hitting keys doesn't seem to speed it up.
> > > 
> > > Is this speculation reasonable?
> > 
> > It depends. Doing randomness gathering right is difficult. It
> > always is a trade-off between quelity and speed. If you look
> > through the mailing-list archives, you find sevveral long
> > discussions about this.
> > 
> > That said, current cryptsetup defaults to /dev/urandom, which 
> > gives you randomness even if entropy is low (which may be 
> > insecure). We decided to use the fast option and to warn 
> > people in the man-pages. You can check the defaults with
> > "cryptsetup --help", at the end it tells you the used
> > CPRNG. 
> 
> I'm running crypsetup 1.0.6 on Debian Lenny; neither --help nor
> --version seems to give any info on the random source.

Aehm, that is so incredible historic that helping you becomes 
very hard. This version is more than 7 years old.
 
> I'm asking becaue I'm about to convert the system to wheezy and have
> the opportunity to change things.  I presume this will generate an
> initrd with the wheezy version, 1.4.3, which uses urandom according to
> its --help.

Upgrade and see whether the problem goes away. If not, ask 
again, but it likely will be something else if urandom is the
default.

> > 
> > There is a second aspect: Any sane distribution keeps some
> > entropy on reboot and uses that to jump-start /dev/(u)random.
> > For this some entropy is stored in a file on shutdown and
> > then piped _into_ /dev/urandom on startup, hence avoiding
> > entropy starvation. "man random" gives a detailed example
> > on how to do that.
> > 
> > You should check the following things:
> > - is cryptsetup compiled with /dev/urandom or /dev/random ad
> > default?
> I can check the source code.  Where is this determined?

Sorry, but I am not about to even look. It is a waste of time.

> > - is cryptsetup called with "--use-random"?
> 
> Is this a question about how it is called from within the initrd?
> Actually, it may not matter since the man page for this version does
> not indicate a --use-random option.

As I said, 7 years old. 

> > - is /dev/(u)random initialized during boot?
> Judging from /etc/init.d/urandom, yes.

Ok.

> > 
> > > If not, what might be the cause of the delay?
> > 
> > A filesystem check, a raid-check, some very slow-to-detect device,
> > wiping of the swap, etc.
> OK.  I take it entropy starvation for the swap is the only crypto
> related possible cause of the delay, given that I have not switched to
> slower processors.  There are 2 swap partitions.
> 
> Hmm, the other thing that might be relevant is that there are 7 non-swap
> encrypted logical volumes.  /etc/crypttab lists root first, then the
> 2 swaps, and then 6 other LV's.  For most of them the relevant key is
> in the 2nd slot.  The pass-phrase prompt is for the root device.

Ah, that may be it. Unlocking a LUKS volume takes checking key-slots
and, due to hash-iteration, each keyslot check takes a certain time.
These days, the default is 1 second for each key-slot, and some 
additional time for the master-key. This can be increased on
creation and at compile-time though. Also, mounting can take 
quite some time depending in volume size. Your 7 volumes can
easily take the 2 Minutes you observe.

What you can do to determine iteration time is to look at 
Key-slot "iteration" parameter in the output of "luksDump"
and then do a reference test, e.g. with a loop-device as in
FAQ Item 2.6 and with explicitely specified ---uter-time 1000
(1 second). That should tell you how long a key-slot needs 
to be checked.

Unfortunately, there is no way to change iteration count.
If it is indeed too long, the simplest way is to backup the 
data and re-create the volumes woth a different --iter-time
or the current 1 sec default. Longer times do not really
add much security.
 
> >  
> > > If the delay is from the encrypted swap, is there anything I can do about
> > > it short of eliminating the swap?  Is there any reason to avoid using a
> > > fixed key for the swap?  Fixed keys sound as if they should eliminate the
> > > need for randomness from the system.
> > 
> > Do not use fixed-keys! They will be available to an attacker. 
> > The whole point of random keys for swap is that they are
> > non-predictable and non-recoverable, yet you do not need 
> > to enter them manually. Fixed keys break that.
> > 
> Why are the fixed keys for swap any more available than fixed keys
> for other devices/partitions?

Fixed keys are an exceedingly bad idea in general. Derived keys
are acceptable, but fixed keys can end up unintentionally
in all sorts of places. Do not use them. (I gather the fixed keys
are placed on the encrypted root partition.)
 
> > What you can do is to implement entropy-storage over reboot
> > according to the (u)random man-page and to tell cryptsetup
> > exolicitly to use /dev/urandom for the swap (--use-urandom).
> > That should elieminate the wainting if key-generationf or swap 
> > is the issue.
> > 
> > 
> > > [slightly off-topic]
> > > Is it still the case that encrypted swap limits the ability to suspend or
> > > hibernate and resume?
> > 
> > Depends on the distro, I guess. But using encrypted swap that
> > way is insecure, as an attacker can easily get access to it,
> > and so it is not a good idea. For standard attacks (e.g. over
> > firewire) a machine suspended/hibernated this way is wide open.
> > Encrypted swap is worthless unless a full power-off is performed,
> > you cannot have it easy _and_ secure in this case.
> I think this means, for random-encrypted swap:
> eencrypted swap + system shutdown and power off is secure

Yes. Key gone, no way to recover anything from swap.

> ecnrypted swap + suspend (system alive but low power) is insecure

Yes. Key is in memory.

> What does it mean for encrypted swap + hibernate (power is off but
> system state is saved to disk)?

If you can wake up without giving encryption keys again, the
key is somehwere on disk.

> Not sure if I have the suspend/hibernate lingo right.  I think those
> are MS-Windows terms.

They are. If you want security, it really is better to just 
have faster boot and not suspend or hibernate. 

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
----
A good decision is based on knowledge and not on numbers. -- Plato

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] System comes up very slowly

[Ross Boylan]

On Sat, Sep 27, 2014 at 10:32:58PM +0200, Arno Wagner wrote:
> On Sat, Sep 27, 2014 at 21:39:30 CEST, Ross Boylan wrote:
> > On Sat, Sep 27, 2014 at 12:19:18PM +0200, Arno Wagner wrote:
> > > On Sat, Sep 27, 2014 at 06:01:19 CEST, Ross Boylan wrote:
> > > > When my computer reboots it shows the grub menu and some initial messages
> > > > from the kernel loading and then waits a very long time (minutes) before
> > > > asking for the pass-phrase for the main partition.
> > > > 
> > > > I speculate the delay is to gather randomness for the 2 random-encrypted
> > > > swap partitions.  However, hitting keys doesn't seem to speed it up.
> > > > 
> > > > Is this speculation reasonable?
> > > 
> > > It depends. Doing randomness gathering right is difficult. It
> > > always is a trade-off between quelity and speed. If you look
> > > through the mailing-list archives, you find sevveral long
> > > discussions about this.
> > > 
> > > That said, current cryptsetup defaults to /dev/urandom, which 
> > > gives you randomness even if entropy is low (which may be 
> > > insecure). We decided to use the fast option and to warn 
> > > people in the man-pages. You can check the defaults with
> > > "cryptsetup --help", at the end it tells you the used
> > > CPRNG. 
> > 
> > I'm running crypsetup 1.0.6 on Debian Lenny; neither --help nor
> > --version seems to give any info on the random source.
> 
> Aehm, that is so incredible historic that helping you becomes 
> very hard. This version is more than 7 years old.
>  
> > I'm asking becaue I'm about to convert the system to wheezy and have
> > the opportunity to change things.  I presume this will generate an
> > initrd with the wheezy version, 1.4.3, which uses urandom according to
> > its --help.
> 
> Upgrade and see whether the problem goes away. If not, ask 
> again, but it likely will be something else if urandom is the
> default.
Sounds good.

.....

> > Hmm, the other thing that might be relevant is that there are 7 non-swap
> > encrypted logical volumes.  /etc/crypttab lists root first, then the
> > 2 swaps, and then 6 other LV's.  For most of them the relevant key is
> > in the 2nd slot.  The pass-phrase prompt is for the root device.
> 
> Ah, that may be it. Unlocking a LUKS volume takes checking key-slots
> and, due to hash-iteration, each keyslot check takes a certain time.
> These days, the default is 1 second for each key-slot, and some 
> additional time for the master-key. This can be increased on
> creation and at compile-time though. Also, mounting can take 
> quite some time depending in volume size. Your 7 volumes can
> easily take the 2 Minutes you observe.

I don't think it's the mounting since the partitions can't be mounted
until they are decrypted, and that can't happen until after I enter
the pass-phrase.  Also, I suspect debian does all the decryption
first, and then the mounts.

The wait seems like forever, and could be 5 or 10 minutes.

> 
> What you can do to determine iteration time is to look at 
> Key-slot "iteration" parameter in the output of "luksDump"
> and then do a reference test, e.g. with a loop-device as in
> FAQ Item 2.6 and with explicitely specified ---uter-time 1000
> (1 second). That should tell you how long a key-slot needs 
> to be checked.
> 
> Unfortunately, there is no way to change iteration count.
> If it is indeed too long, the simplest way is to backup the 
> data and re-create the volumes woth a different --iter-time
> or the current 1 sec default. Longer times do not really
> add much security.

Since I'm doing a fresh install and then restore I can change
anything, since I'm building new partitions and file systems.

I was encrypting selected partitions/logical volumes, but I'm probably
going to put the crypt right on top of RAID this time.  This means
there will be only one thing to unlock.

One reason I went with the old scheme is that I thought encryption
became less secure the bigger the area encrypted.  However, I don't
see anything about that in the FAQ (except for the 2TB limit on some
encryption schemes).

> > >  
> > > > If the delay is from the encrypted swap, is there anything I can do about
> > > > it short of eliminating the swap?  Is there any reason to avoid using a
> > > > fixed key for the swap?  Fixed keys sound as if they should eliminate the
> > > > need for randomness from the system.
> > > 
> > > Do not use fixed-keys! They will be available to an attacker. 

I must be misunderstanding, because it seems to me any LUKS device
that is not random encrypted has fixed keys.

> > > The whole point of random keys for swap is that they are
> > > non-predictable and non-recoverable, yet you do not need 
> > > to enter them manually. Fixed keys break that.
> > > 
> > Why are the fixed keys for swap any more available than fixed keys
> > for other devices/partitions?
> 
> Fixed keys are an exceedingly bad idea in general. Derived keys

I don't know what a derived key is.  Like
http://en.wikipedia.org/wiki/Derived_unique_key_per_transaction,
except not  transactional?  6.6 of the FAQ?

> are acceptable, but fixed keys can end up unintentionally
> in all sorts of places. Do not use them. (I gather the fixed keys
> are placed on the encrypted root partition.)

fixed keys, in the sense of --key-file for the other partitions, are in
the encrypted root.  I am aware they are sensitive.

So is your concern about fixed keys a concern about keys that are
stored on the disk vs stored in my head?

...

> > > 
> > > > [slightly off-topic]
> > > > Is it still the case that encrypted swap limits the ability to suspend or
> > > > hibernate and resume?
> > > 
> > > Depends on the distro, I guess. But using encrypted swap that
> > > way is insecure, as an attacker can easily get access to it,
> > > and so it is not a good idea. For standard attacks (e.g. over
> > > firewire) a machine suspended/hibernated this way is wide open.
> > > Encrypted swap is worthless unless a full power-off is performed,
> > > you cannot have it easy _and_ secure in this case.
> > I think this means, for random-encrypted swap:
> > eencrypted swap + system shutdown and power off is secure
> 
> Yes. Key gone, no way to recover anything from swap.
> 
> > ecnrypted swap + suspend (system alive but low power) is insecure
> 
> Yes. Key is in memory.

I had assumed one would have to reenter the pass-phrase on wakeup.
Though now that I think of it, that's non-trivial since the code to
get the pass-phrase and cryptsetup itself would need to be in memory
that wasn't encrypted.

> 
> > What does it mean for encrypted swap + hibernate (power is off but
> > system state is saved to disk)?
> 
> If you can wake up without giving encryption keys again, the
> key is somehwere on disk.
> 
> > Not sure if I have the suspend/hibernate lingo right.  I think those
> > are MS-Windows terms.
> 
> They are. If you want security, it really is better to just 
> have faster boot and not suspend or hibernate. 

The easiest way to have faster boot is to use SSD, but the FAQ
indicates the security of SSD's is unclear.

Ross

Re: [dm-crypt] System comes up very slowly

[Arno Wagner]

On Sun, Sep 28, 2014 at 00:30:59 CEST, Ross Boylan wrote:
> On Sat, Sep 27, 2014 at 10:32:58PM +0200, Arno Wagner wrote:
[...]
> > Upgrade and see whether the problem goes away. If not, ask 
> > again, but it likely will be something else if urandom is the
> > default.
> Sounds good.
> 
> .....
> 
> > > Hmm, the other thing that might be relevant is that there are 7 non-swap
> > > encrypted logical volumes.  /etc/crypttab lists root first, then the
> > > 2 swaps, and then 6 other LV's.  For most of them the relevant key is
> > > in the 2nd slot.  The pass-phrase prompt is for the root device.
> > 
> > Ah, that may be it. Unlocking a LUKS volume takes checking key-slots
> > and, due to hash-iteration, each keyslot check takes a certain time.
> > These days, the default is 1 second for each key-slot, and some 
> > additional time for the master-key. This can be increased on
> > creation and at compile-time though. Also, mounting can take 
> > quite some time depending in volume size. Your 7 volumes can
> > easily take the 2 Minutes you observe.
> 
> I don't think it's the mounting since the partitions can't be mounted
> until they are decrypted, and that can't happen until after I enter
> the pass-phrase.  Also, I suspect debian does all the decryption
> first, and then the mounts.
> 
> The wait seems like forever, and could be 5 or 10 minutes.
> 
> > 
> > What you can do to determine iteration time is to look at 
> > Key-slot "iteration" parameter in the output of "luksDump"
> > and then do a reference test, e.g. with a loop-device as in
> > FAQ Item 2.6 and with explicitely specified ---uter-time 1000
> > (1 second). That should tell you how long a key-slot needs 
> > to be checked.
> > 
> > Unfortunately, there is no way to change iteration count.
> > If it is indeed too long, the simplest way is to backup the 
> > data and re-create the volumes woth a different --iter-time
> > or the current 1 sec default. Longer times do not really
> > add much security.
> 
> Since I'm doing a fresh install and then restore I can change
> anything, since I'm building new partitions and file systems.
> 
> I was encrypting selected partitions/logical volumes, but I'm probably
> going to put the crypt right on top of RAID this time.  This means
> there will be only one thing to unlock.
> 
> One reason I went with the old scheme is that I thought encryption
> became less secure the bigger the area encrypted.  However, I don't
> see anything about that in the FAQ (except for the 2TB limit on some
> encryption schemes).

It does become less secure, but not in any practical sense.
This is more an information-theoretical argument and even 
that is a weak one. 
 
> > > >  
> > > > > If the delay is from the encrypted swap, is there anything I can do about
> > > > > it short of eliminating the swap?  Is there any reason to avoid using a
> > > > > fixed key for the swap?  Fixed keys sound as if they should eliminate the
> > > > > need for randomness from the system.
> > > > 
> > > > Do not use fixed-keys! They will be available to an attacker. 
> 
> I must be misunderstanding, because it seems to me any LUKS device
> that is not random encrypted has fixed keys.

Yes, but what you deed into it is not the key, but a passphrase.
And that you can change if it becomes compromised without changing 
the key. A "fixed key" is what youwould use for plain dm-crypt.
Still, a fixed passphrase (keyfile on disk) is not that good
an idea either, but sometimes the ebst you can get.

> > > > The whole point of random keys for swap is that they are
> > > > non-predictable and non-recoverable, yet you do not need 
> > > > to enter them manually. Fixed keys break that.
> > > > 
> > > Why are the fixed keys for swap any more available than fixed keys
> > > for other devices/partitions?
> > 
> > Fixed keys are an exceedingly bad idea in general. Derived keys
> 
> I don't know what a derived key is.  Like
> http://en.wikipedia.org/wiki/Derived_unique_key_per_transaction,
> except not  transactional?  6.6 of the FAQ?

A dereived key reads the master-key from the mapping as in
FAQ 6.10, and uses that as basis for other plain dm-crypt
keys, usually just usng it directly as passphrase. The
advantage is that your key never ends up on disk.
 
> > are acceptable, but fixed keys can end up unintentionally
> > in all sorts of places. Do not use them. (I gather the fixed keys
> > are placed on the encrypted root partition.)
> 
> fixed keys, in the sense of --key-file for the other partitions, are in
> the encrypted root.  I am aware they are sensitive.

O.k., see above. These are not "fixed key", thse are 
"stored passprase" as what you enter is not the key.
 
> So is your concern about fixed keys a concern about keys that are
> stored on the disk vs stored in my head?

Yes. 

> ...
> 
> > > > 
> > > > > [slightly off-topic]
> > > > > Is it still the case that encrypted swap limits the ability to suspend or
> > > > > hibernate and resume?
> > > > 
> > > > Depends on the distro, I guess. But using encrypted swap that
> > > > way is insecure, as an attacker can easily get access to it,
> > > > and so it is not a good idea. For standard attacks (e.g. over
> > > > firewire) a machine suspended/hibernated this way is wide open.
> > > > Encrypted swap is worthless unless a full power-off is performed,
> > > > you cannot have it easy _and_ secure in this case.
> > > I think this means, for random-encrypted swap:
> > > eencrypted swap + system shutdown and power off is secure
> > 
> > Yes. Key gone, no way to recover anything from swap.
> > 
> > > ecnrypted swap + suspend (system alive but low power) is insecure
> > 
> > Yes. Key is in memory.
> 
> I had assumed one would have to reenter the pass-phrase on wakeup.
> Though now that I think of it, that's non-trivial since the code to
> get the pass-phrase and cryptsetup itself would need to be in memory
> that wasn't encrypted.

That is the issue, yes. Basical;ly, you need to runt rhough part 
of the boot-process here and then suspend makes not that much sense
anymore. It also becomes a lot slower.

> > 
> > > What does it mean for encrypted swap + hibernate (power is off but
> > > system state is saved to disk)?
> > 
> > If you can wake up without giving encryption keys again, the
> > key is somehwere on disk.
> > 
> > > Not sure if I have the suspend/hibernate lingo right.  I think those
> > > are MS-Windows terms.
> > 
> > They are. If you want security, it really is better to just 
> > have faster boot and not suspend or hibernate. 
> 
> The easiest way to have faster boot is to use SSD, but the FAQ
> indicates the security of SSD's is unclear.

If you never want to change your passphrase, then SSD is probably 
fine. The main risk is that if your passphrase becomes compromised
and you cnage it, the ond one can still be on disk in some internal
pool area. This is only a concern for protection against  
higher-resource attackers though. If you want to ptotect yourself
against a common laptop-thief, for example, using an SSD should be 
fine.

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
----
A good decision is based on knowledge and not on numbers. -- Plato

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] System comes up very slowly

[Heiko Rosemann]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/27/2014 10:32 PM, Arno Wagner wrote:
> On Sat, Sep 27, 2014 at 21:39:30 CEST, Ross Boylan wrote:
>> What does it mean for encrypted swap + hibernate (power is off
>> but system state is saved to disk)?
> 
> If you can wake up without giving encryption keys again, the key is
> somehwere on disk.

Let me just jump in here because this is the way I am using my system:
For hibernating to encrypted swap (more precisely, to resume from an
encrypted swap), you do need to give the encryption key/passphrase
again - to an initrd/initramfs to re-luksOpen the encrypted swap
device before trying to resume from it. (btw this implies you can not
use random keys for swap if you want hibernate/resume, as obviously
there should be no chance to regenerate a random key)

JFTR, the relevant parts of my initramfs' init file look as follows,
with $RESUMEDEV evaluating to /dev/mapper/swap and
open{swap,root,home,var} being shell wrappers for mounting a USB
storage device containing key files, opening a luks-encrypted
partition, unmounting the storage device.

# Open swap crypto device (my own addition)
/sbin/openswap

# Resume state from swap (Slackware mkinitrd)
echo "Trying to resume from $RESUMEDEV"
RESMAJMIN=$(ls -l $RESUMEDEV | tr , : | awk '{ print $5$6 }')
echo $RESMAJMIN > /sys/power/resume

# If resume failed, also open other crypto devices (my own addition)
/sbin/openroot
/sbin/openvar
/sbin/openhome

# Switch to real root partition: (Slackware mkinitrd)
/sbin/udevadm settle --timeout=10
echo 0x0100 > /proc/sys/kernel/real-root-dev
mount -o ro -t $ROOTFS $ROOTDEV /mnt

YMMV,
Heiko

- -- 
Mein PGP-Key zur Verifizierung: http://pgp.mit.edu

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlQonfUACgkQ/Vb5NagElAW9JwCgqELCNnS1gyAbfD683g1AssJF
6qwAn1PuJxtX+BBLRfkAlrahnsJtn7oe
=sqoT
-----END PGP SIGNATURE-----