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

[Arno Wagner <arno@wagner.name>]

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