[dm-crypt] Entropy available for luksFormat during GNU/Linux installs

[dm-crypt] Entropy available for luksFormat during GNU/Linux installs

[Roscoe]

Hey folks,

A while ago the following paper regarding the Linux RNG was in the news:
http://www.pinkas.net/PAPERS/gpr06.pdf

It describes issues with environments utilizing read only storage
[KNOPPIX and WRT are named].

At the time I thought "Hey, just like installing from CD!".
Since then, I've always been a bit suspicious of the security factor
of partitions created within an installer.

Has there been much consideration as to this matter within OS
installers? Does anyone suspect any latent issues?

If we take a Debian text installs with no network, that removes NIC
generated interrupts and the mouse as sources of entropy, and
considering setting up partitions [and consequently LUKS/LVM/RAID] is
one of the first things you do within the installer, I start to become
a bit suspicious of the quality of the 512 MK bits pulled for
AES-256-XTS.


Regards,

-- Roscoe

PS [Confession]: Crypto/Maths/CS aren't my fields so I only skimmed the paper!

Re: [dm-crypt] Entropy available for luksFormat during GNU/Linux installs

[Milan Broz]

On 01/24/2010 07:17 AM, Roscoe wrote:
> Has there been much consideration as to this matter within OS
> installers? Does anyone suspect any latent issues?
> 
> If we take a Debian text installs with no network, that removes NIC
> generated interrupts and the mouse as sources of entropy, and
> considering setting up partitions [and consequently LUKS/LVM/RAID] is
> one of the first things you do within the installer, I start to become
> a bit suspicious of the quality of the 512 MK bits pulled for
> AES-256-XTS.

Yes, this is interesting problem, just adding some notes:
(please correct me if I am wrong in some points)

- cryptsetup uses /dev/urandom, so volume key quality really depends on RNG here,
exactly the same like all other key generation during install

- cryptsetup/libcryptsetup supports now  --master-key-file, you can use your own
pre-generated volume (master) key if you wish.
(Another reason was ability to reformat LUKS header with only MK knowledge)

(Side note about plain (non-LUKS) mode with random key: if initscripts forgot
to re-seed RNG, various low-entropy attacks are possible during system boot.
Encrypted swap is usually initialised before network and other source of entropy are started!
Initscript must initialise plain encrypted device in two steps - first fs where is
the RNG seed stored, reseed RNG, and then format encrypted devices using random key.)

(and in fact, cryptsetup cannot do any statistical tests for RNG, input is too small,
so it must trust kernel here IMHO)

- maybe someone should also describe RNG when system is in FIPS140 mode then
(RNG initialisation and approved RNG are exactly defined, IIRC RNG must not
produce any output if not properly seeded etc.)

- maybe distribution can run some RNG tests also in installer before generating key?
(I mean e.g. rngtest from rng-tools,
or http://csrc.nist.gov/groups/ST/toolkit/rng/documentation_software.html
or http://www.phy.duke.edu/~rgb/General/dieharder.php
and from this "verified" source pre-generate MK for cryptsetup luksFormat...)

Milan

Re: [dm-crypt] Entropy available for luksFormat during GNU/Linux installs

[Arno Wagner]

On Sun, Jan 24, 2010 at 11:50:26AM +0100, Milan Broz wrote:
> On 01/24/2010 07:17 AM, Roscoe wrote:
> > Has there been much consideration as to this matter within OS
> > installers? Does anyone suspect any latent issues?
> > 
> > If we take a Debian text installs with no network, that removes NIC
> > generated interrupts and the mouse as sources of entropy, and
> > considering setting up partitions [and consequently LUKS/LVM/RAID] is
> > one of the first things you do within the installer, I start to become
> > a bit suspicious of the quality of the 512 MK bits pulled for
> > AES-256-XTS.
> 
> Yes, this is interesting problem, just adding some notes:
> (please correct me if I am wrong in some points)

> 
> - cryptsetup uses /dev/urandom, so volume key quality really depends on
> RNG here, exactly the same like all other key generation during install

That is probably a design mistake. It should use /dev/random and
have people wait for enough entropy. The man page for random/urandom
(Debian: just use "man urandom") explicitely suggests this:

"As  a  general rule,  /dev/urandom  should  be  used  for everything 
 except long-lived GPG/SSL/SSH keys."
 ^^^^^^ 

LUKS keys are also long-lived and should therefore not come
from /dev/urandom.

I propose to fix this by making /dev/random the default, and 
maybe have use of /dev/urandom as commandline option with a 
strong warning.

It may be necessary to ask people to enter some keystrokes
during key generation with /dev/random, otherwise key 
generation may block forever in the minimal environmental 
entropy scenario. On the other hand, entropy cannot be
generated out of thin air, so such a request is entirely
reasonable. This needs to be mentioned in the documentation
and the --help online help. 

I am convinced that it is better to block in an entropy 
starved situation than to start producing bad keys.

> - cryptsetup/libcryptsetup supports now  --master-key-file, you can use your own
> pre-generated volume (master) key if you wish.
> (Another reason was ability to reformat LUKS header with only MK knowledge)
> 
> (Side note about plain (non-LUKS) mode with random key: if initscripts forgot
> to re-seed RNG, various low-entropy attacks are possible during system boot.
> Encrypted swap is usually initialised before network and other source of entropy are started!
> Initscript must initialise plain encrypted device in two steps - first fs where is
> the RNG seed stored, reseed RNG, and then format encrypted devices using random key.)
> 
> (and in fact, cryptsetup cannot do any statistical tests for RNG, input is too small,
> so it must trust kernel here IMHO)
> 
> - maybe someone should also describe RNG when system is in FIPS140 mode then
> (RNG initialisation and approved RNG are exactly defined, IIRC RNG must not
> produce any output if not properly seeded etc.)

Use of /dev/random instead of /dev/urandom should ensure that.
 
> - maybe distribution can run some RNG tests also in installer 
>   before generating key?
> (I mean e.g. rngtest from rng-tools,
> or http://csrc.nist.gov/groups/ST/toolkit/rng/documentation_software.html
> or http://www.phy.duke.edu/~rgb/General/dieharder.php
> and from this "verified" source pre-generate MK for cryptsetup luksFormat...)

That would not work. The randomness properties of /dev/urandom are 
good with regard to these tests. The tests do not cover initialization 
quality, unless you start to compere different initializations. Even 
then you would need two times exactly the same initialization to
notice something was wrong.

The problem here is that these tests look for bad distributions
of the output, while while crypto is not so much concerned with
good distribution, but critically depends on predictability.

In order to judge the initialization data quality for a crypto
PRNG, you have to look at the initialization data directly or 
break the used crypto-hash to a degree that you can easily 
reverse it. That is typically completely infeasible and the
statistical tests for PRNGs can certainly no do it.

However /dev/random does this itself by estimatinh how much 
entropy it has gathered and not ginving you anything until it 
has a significant pool. It will then only deplete part of the 
pool before waiting for more entropy.

Here is a small test you can do to see this in action (no 
network load, or it will probably not work):

  cat /dev/random | hd

On my machine that gives me 512 bytes of randomness and 
then stops until I move the mouse or type something.

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 

Re: [dm-crypt] Entropy available for luksFormat during GNU/Linux installs

[Heinz Diehl]

On 24.01.2010, Arno Wagner wrote: 

> "As  a  general rule,  /dev/urandom  should  be  used  for everything 
>  except long-lived GPG/SSL/SSH keys."
>  ^^^^^^ 

Why?

Is the output of urandom somehow more predictable than random?

Re: [dm-crypt] Entropy available for luksFormat during GNU/Linux installs

[Rick Moritz]

On Sun, 24 Jan 2010 15:02:05 +0100 Heinz Diehl <htd@fancy-poultry.org> wrote:

> On 24.01.2010, Arno Wagner wrote: 
> 
> > "As  a  general rule,  /dev/urandom  should  be  used  for everything 
> >  except long-lived GPG/SSL/SSH keys."
> >  ^^^^^^ 
> 
> Why?
> 
> Is the output of urandom somehow more predictable than random?

Once the entropy pool is exhausted, yes. Because then the randomness is no longer actual randomness, but pseudo-randomness, and can be predicted if you have the random seed available.

Re: [dm-crypt] Entropy available for luksFormat during GNU/Linux installs

[Heinz Diehl]

On 24.01.2010, Rick Moritz wrote: 

> Once the entropy pool is exhausted, yes. Because then the randomness is no longer actual randomness, but pseudo-randomness,

Yes, urandom is a PRGN.

> and can be predicted if you have the random seed available.

Thanks for pointing this out again! So I don't have to worry, nobody will
get hands on my random seed ever. The time I generated the master key to
my partitions is long gone, and so is the random seed.

Re: [dm-crypt] Entropy available for luksFormat during GNU/Linux installs

[Si St]

Yes. Compared to /dev/random the /dev/urandom is actually a "program" with certain predictability. /dev/random collects its values from real randomness, at least better than urandom.
Look at the "man urandom":

The random number generator gathers environmental noise from device drivers and other sources into an entropy pool....

A read from the /dev/urandom device will not block waiting for more entropy.  As a result, if there is not sufficient entropy in the entropy pool, the returned values are theoretically vulnerable to a cryptographic attack  on  the  algorithms  used  by  the driver. 

But actually how weak a feature this is depends on the practical results achieved from the attacks. This may of course depend on the WILL, TIME, and SOFTWARE in use. All cryptography have weaknesses, but it takes time to get hold of them, - like it took time to crack the algoritm of simple DES. But in the end they got it.

------------------------------------------------------------------------------------------------
Heia Fedje!
------------------------------------------------------------------------------------------------

> ----- Original Message -----
> From: "Heinz Diehl" <htd@fancy-poultry.org>
> To: dm-crypt@saout.de
> Subject: Re: [dm-crypt] Entropy available for luksFormat during GNU/Linux installs
> Date: Sun, 24 Jan 2010 15:02:05 +0100
> 
> 
> On 24.01.2010, Arno Wagner wrote:
> 
> > "As  a  general rule,  /dev/urandom  should  be  used  for 
> > everything  except long-lived GPG/SSL/SSH keys."
> >  ^^^^^^
> 
> Why?
> 
> Is the output of urandom somehow more predictable than random?
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

>


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

Powered by Outblaze

Re: [dm-crypt] Entropy available for luksFormat during GNU/Linux installs

[Arno Wagner]

On Sun, Jan 24, 2010 at 03:02:05PM +0100, Heinz Diehl wrote:
> On 24.01.2010, Arno Wagner wrote: 
> 
> > "As  a  general rule,  /dev/urandom  should  be  used  for everything 
> >  except long-lived GPG/SSL/SSH keys."
> >  ^^^^^^ 
> 
> Why?
> 
> Is the output of urandom somehow more predictable than random?

In a low environmental Entropy situation for a newly installed
system, it is. For example it will give you a 512 bit key, even
if it has only gathered 32 bits of entropy. The attacker then
needs to try all 512 bit keys generated with the possible
different 32 bit initializations to find the key. It is not
an attack that really matters when there is a user at the
keyboard, and a mouse in use. Think of fully automated
installation with no user interaction on a very simple
system not connected to the network.

/dev/random will, in contrast, make you wait until it
has gathered signbificantly more entropy than the 512 bits
before giving you the key.

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 

Re: [dm-crypt] Entropy available for luksFormat during GNU/Linux installs

[Arno Wagner]

On Sun, Jan 24, 2010 at 05:56:27PM +0100, Heinz Diehl wrote:
> On 24.01.2010, Rick Moritz wrote: 
> 
> > Once the entropy pool is exhausted, yes. Because then the randomness is no longer actual randomness, but pseudo-randomness,
> 
> Yes, urandom is a PRGN.
> 
> > and can be predicted if you have the random seed available.
> 
> Thanks for pointing this out again! So I don't have to worry, nobody will
> get hands on my random seed ever. The time I generated the master key to
> my partitions is long gone, and so is the random seed.

If your system had some decent interaction (say at least 
50 keystrokes or 10 mouse moves) before you used 
/dev/urandom, then you are safe. The interaction can
have reboots in between. This really only applise in 
a special sutuation where the system was not able to
fill the entopy pool. 

An attack on the seed is only possible under similar
circumstances, i.e. /dev/urandom before the keystrokes 
and/or mouse moves happened and basically was still in 
state the seed gave it.

Do not worry with regular key generation! If you typed
"cryptsetup" manually, that will already have made you 
pretty safe. This is for a special situation only.

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 

Re: [dm-crypt] Entropy available for luksFormat during GNU/Linux installs

[Milan Broz]

On 01/25/2010 12:03 AM, Arno Wagner wrote:
> On Sun, Jan 24, 2010 at 03:02:05PM +0100, Heinz Diehl wrote:
>> On 24.01.2010, Arno Wagner wrote: 
>>
>>> "As  a  general rule,  /dev/urandom  should  be  used  for everything 
>>>  except long-lived GPG/SSL/SSH keys."


cryptsetup now depends on gcrypt, I will probably rewrite random source
to use gcrypt random generators
(its RNG can use both /dev/random and /dev/urandom for seeding)

In LUKS case, there are four places which need random data:

- volume (master) key generation
- volume key digest salt and password salt
- anti-forensic split for keyslot obfuscation
- safe wipe

we are talking only only the first (master key) case here, right?

Any known problem why not to use gcrypt RNG?
(It should internally wrap possible waiting for enugh entropy,
FIPS mode etc. No need to duplicate code in cryptsetup.)

Milan

Re: [dm-crypt] Entropy available for luksFormat during GNU/Linux installs

[Roscoe]

On Mon, Jan 25, 2010 at 10:25 PM, Milan Broz <mbroz@redhat.com> wrote:
>
> cryptsetup now depends on gcrypt, I will probably rewrite random source
> to use gcrypt random generators
> (its RNG can use both /dev/random and /dev/urandom for seeding)
> In LUKS case, there are four places which need random data:
>
> - volume (master) key generation
> - volume key digest salt and password salt
> - anti-forensic split for keyslot obfuscation
> - safe wipe
>
> we are talking only only the first (master key) case here, right?

Yes.

> Any known problem why not to use gcrypt RNG?
> (It should internally wrap possible waiting for enugh entropy,
> FIPS mode etc. No need to duplicate code in cryptsetup.)

What does using the gcrypt RNG get us? As it's a PRNG that's using
/dev/[u]random (in our case) as a source of entropy. I presume it's
security hinges on the source.

Thus we're introducing another layer and consequently more complexity
and more room for mistakes to be made, but to what benefit?


Regarding the original premise of the thread, a feature that could
relax those worried about Linux's RNG implementation, is the option to
have the master key derived from whatever source of random bits that
cryptsetup uses, XORed with user specified randomness.
The user specified random bits would be prompting the user to pound
the keyboard, then it being feed through PBKDF2 to generate a stream
of sufficient length (we won't hit dkLen).
Just a thought.

Regards,

-- Roscoe

Re: [dm-crypt] Entropy available for luksFormat during GNU/Linux installs

[Arno Wagner]

On Wed, Feb 03, 2010 at 11:45:02AM +1100, Roscoe wrote:
> On Mon, Jan 25, 2010 at 10:25 PM, Milan Broz <mbroz@redhat.com> wrote:
> >
> > cryptsetup now depends on gcrypt, I will probably rewrite random source
> > to use gcrypt random generators
> > (its RNG can use both /dev/random and /dev/urandom for seeding)
> > In LUKS case, there are four places which need random data:
> >
> > - volume (master) key generation
> > - volume key digest salt and password salt
> > - anti-forensic split for keyslot obfuscation
> > - safe wipe
> >
> > we are talking only only the first (master key) case here, right?
> 
> Yes.
> 
> > Any known problem why not to use gcrypt RNG?
> > (It should internally wrap possible waiting for enugh entropy,
> > FIPS mode etc. No need to duplicate code in cryptsetup.)
> 
> What does using the gcrypt RNG get us? As it's a PRNG that's using
> /dev/[u]random (in our case) as a source of entropy. I presume it's
> security hinges on the source.
> 
> Thus we're introducing another layer and consequently more complexity
> and more room for mistakes to be made, but to what benefit?

I think the benefit would be that we could set a quantum of
entropy to get from /dev/random and then continue with our
own (well, gcrypt's) PRNG on top. The problem with using
/dev/random diorectly is that it is only suitable for low
amounts of needed bits. The problem with /dev/urandom is that
it will give you any amount of bist even if the entopy pool
is empty and there is no old seed. The gcrypt PRNG initialized
from /dev/random would eleminate both issues, provided that 
it gets enough initial entropy from /dev/random.

 
> Regarding the original premise of the thread, a feature that could
> relax those worried about Linux's RNG implementation, is the option to
> have the master key derived from whatever source of random bits that
> cryptsetup uses, XORed with user specified randomness.

Actually that schould be hashed together with a crypto-hash. You
may lose entopy otherwise.

> The user specified random bits would be prompting the user to pound
> the keyboard, then it being feed through PBKDF2 to generate a stream
> of sufficient length (we won't hit dkLen).

You can use /dev/random directly instead, it already has this
functionality. It will take entropy from the keys and, more 
importantly, from the timing.

Arno


> Just a thought.
> 
> Regards,
> 
> -- Roscoe
> _______________________________________________
> 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] Entropy available for luksFormat during GNU/Linux installs

[Arno Wagner]

On Wed, Feb 03, 2010 at 07:21:13AM +0100, Arno Wagner wrote:
> On Wed, Feb 03, 2010 at 11:45:02AM +1100, Roscoe wrote:
> > On Mon, Jan 25, 2010 at 10:25 PM, Milan Broz <mbroz@redhat.com> wrote:
> > >
> > > cryptsetup now depends on gcrypt, I will probably rewrite random source
> > > to use gcrypt random generators
> > > (its RNG can use both /dev/random and /dev/urandom for seeding)
> > > In LUKS case, there are four places which need random data:
> > >
> > > - volume (master) key generation
> > > - volume key digest salt and password salt
> > > - anti-forensic split for keyslot obfuscation
> > > - safe wipe
> > >
> > > we are talking only only the first (master key) case here, right?
> > 
> > Yes.
> > 
> > > Any known problem why not to use gcrypt RNG?
> > > (It should internally wrap possible waiting for enugh entropy,
> > > FIPS mode etc. No need to duplicate code in cryptsetup.)

Here is my short rundown of the impact of using the gcrypt PRNG. 
Note that I have not personally used gcrypt, but I have some 
crypto and security background.

Peer review:
 - GnuPG and its components enjoy widespread use and should
   have a reasonable level of expert review. However I did
   not find any papers or architectural descriptions referring
   to the PRNG.

PRNG: 
 - Not much info in the docs.

FIPS mode:
 - Uses /dev/random, as it should.
 - No random seeds support by gcrypt. Not a problem, the kernel
   has its own.
 - X9.31 PRNG instead of a large-pool-CSPRNG. 

   The CSPRNG does not seem to be documented well. It seems to have 
   a 600 Byte entropy pool and use RIPE-MD160. Seems this one
   requires trust that the developers know what they are doing. 
   On the other hand, doing a PRNG with a crypto-hash is not 
   that difficult, as long as the hash is good and entropy gathering 
   is done right. RIPE-MD160 seems to be currently completely unbroken.
   
   The X9.31 PRNG in gcrypt uses AES and seems to be in relative
   wide use.  

Software Engineering aspects:
 - gcrypt is an active project and will very likely remain so in 
   the future. GPG is widely used and a standard tool for encryption
   and signature generation. The library (libgcrypt) is used by many 
   other projects and seems reasonably easy to use.
 - This removes one are we have to think about and makes the PRNG 
   somebody elses headache, with the somebody elses not really any 
   less qualified than we are. A big plus because it lowers effort 
   and oportunities to mess up.


Well, I would prefer to have a parameter for /dev/urandom telling 
it how much entropy to gather before delivering output, but in the
absence of that we need to do somthing ourselves. 

The two nice things about using gcrypt are that it is widely
used and already in cryptsetup and that it allows us to sidestep
the problem neatly. It even gives us the possibility to use FIPS
mode (which may or may not be more secure, basically it just
diallows a lot of things that lower security to gain speed)
by a command line switch. 

On the otehr hand, how much key material are we talking here 
with the master key? If it is less than 600 bytes, using 
/dev/random directly would be better than obtaining 600
seed bytes and thens starting the gcrypt generator to actually
get less randomness from it.

If we have a large requirement for randomness that /dev/random 
can definitely not fulfill, I am all for using the gcrypt 
generators, also because it prevents cryptsetup complexity
increases and it would make cryptsetup about as secure as GPG,
which should be pretty good.

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 

Re: [dm-crypt] Entropy available for luksFormat during GNU/Linux installs

[Milan Broz]

On 02/03/2010 01:45 AM, Roscoe wrote:
> On Mon, Jan 25, 2010 at 10:25 PM, Milan Broz <mbroz@redhat.com> wrote:

>> Any known problem why not to use gcrypt RNG?
>> (It should internally wrap possible waiting for enugh entropy,
>> FIPS mode etc. No need to duplicate code in cryptsetup.)
> 
> What does using the gcrypt RNG get us? As it's a PRNG that's using
> /dev/[u]random (in our case) as a source of entropy. I presume it's
> security hinges on the source.

Yes. But cryptsetup is already based on gcrypt crypto functions.
For RNG:
http://www.gnupg.org/documentation/manuals/gcrypt/Random_002dNumber-Subsystem-Architecture.html

> Thus we're introducing another layer and consequently more complexity
> and more room for mistakes to be made, but to what benefit?

Actually, I think the opposite:-) gcrypt is widely used in several
crypto projects, I know there were reviews etc.
(Note it is crypto library used and developed for GnuPG).
Any crypto implementation, like RNG handling inside cryptsetup
will never be so closely verified.
(And possible mistake here is catastrophic to security - imagine
it will loop because some signal received instead of waiting
for entropy and read all 0 instead of master key.)

> Regarding the original premise of the thread, a feature that could
> relax those worried about Linux's RNG implementation, is the option to
> have the master key derived from whatever source of random bits that
> cryptsetup uses, XORed with user specified randomness.
> The user specified random bits would be prompting the user to pound
> the keyboard, then it being feed through PBKDF2 to generate a stream
> of sufficient length (we won't hit dkLen).

And exactly this waiting is solved by gcrypt RNG and I do need
to reimplement it in cryptsetup.

Also if the system is in FIPS mode (and there are possible installations
which want this) long term key used for disk encryption must be
generated from RNG (resp. FIPS certified RNG only).
(IOW I want to avoid any post-RNG operation like XOR you mention,
this can bring more problems than it solves IMHO)

Gcrypt is FIPS capable and hides all that self-test machinery needed
for FIPS.

Of course I mean using GCRY_VERY_STRONG_RANDOM which is
intended for long-term key generator.
But for keyslot AF split we need also randomly generated buffer
but now the system can use more relaxed generator.
I cannot simply read /dev/random always and wait for entropy - for these
operations /dev/urandom should be used.
Gcrypt provides nice wrapper for that - gcry_random_bytes* functions.

From my point of view it is more consistent that all crypto related
functions, including secure RNG, are in one library. So cryptsetup
itself handles LUKS operations but no low-level crypto implementations
(hash, ciphers, RNG, etc)
(We have already all that complexity with gcrypt initialisation included.)

In fact, it is not complicated to implement both. But I think that
responsibility for properly initialising RNG can be moved to trusted
crypto library and not try to do it inside the code.
(Maybe quite shifting of responsibility:-)

Milan

Re: [dm-crypt] Entropy available for luksFormat during GNU/Linux installs

[Roscoe]

On Wed, Feb 3, 2010 at 6:57 PM, Arno Wagner <arno@wagner.name> wrote:
> On the otehr hand, how much key material are we talking here
> with the master key? If it is less than 600 bytes, using
> /dev/random directly would be better than obtaining 600
> seed bytes and thens starting the gcrypt generator to actually
> get less randomness from it.

For master keys we're only talking likely in the range of 16-64 bytes,
defaulting to 32 bytes currently.

Regards,

-- Roscoe

Re: [dm-crypt] Entropy available for luksFormat during GNU/Linux installs

[Roscoe]

Woops, only just noticed I had replied off list.

-- Roscoe

On Thu, Feb 4, 2010 at 7:31 AM, Roscoe <eocsor@gmail.com> wrote:
> On Thu, Feb 4, 2010 at 12:42 AM, Milan Broz <mbroz@redhat.com> wrote:
>> It is not only about master key, there are at least two other consumers
>> of RNG output - AF split and secure keyslot wipe. So both "fast" RNG
>> and long-term key quality is needed.
>
> Well, I'm not overly concerned about those. As you say, other
> consumers don't need the security margin of MK.
>
>>>> And exactly this waiting is solved by gcrypt RNG and I do need
>>>> to reimplement it in cryptsetup.
>>>
>>> I do not understand this sentence.
>>
>> I want to avoid implementing any "please wait and do some random work
>> till kernel collects some entropy" loop in cryptsetup.
>
> That doesn't relate to my suggestion of an option, but certainly does
> relate to any use of /dev/random.
>
>> At least its _implementation_ requires extensive review.
>> (If the real in-kernel encryption key is generated using approved source,
>> there is no problem. If we XOR it with another source, it is basically new RNG.)
>
> The great thing about XORing the output of two random functions is
> that you're no worse off than if you had just used either function.
> (My view of things is we already rely on the user to produce one
> unpredictable string, why not for another? If in the worst case they
> just hit enter, we're no worse off than if we had only used
> /dev/random.)
> (Now that we have the options to specify the master key, I can get
> this functionality via the use of an external tool obviously, but it
> would be slightly more convenient to have a --user-random switch.)
>
>> If the RNG source is ok for long-term key use, what additional XOR brings here?
>> If RNG is not ok, it should not be used at all.
>
> That is the big question, how good is Linux's RNG early on in an
> install environment?
> (gcrypt's RNG in FIPS mode will still as mentioned before hinge on /dev/random)
>
>
> On a similar note, I did notice the lavarnd guy commenting about /dev/random:
> "The existence of uniformity flaws indicates that the medium quality
> random number generators listed above are not cryptographically strong
> random number generators. "
> -- http://www.lavarnd.org/what/nist-test.html
>
>
> Regards,
>
> -- Roscoe
>