[dm-crypt] Entropy available for luksFormat during GNU/Linux installs
arno at wagner.name
Wed Feb 3 08:57:57 CET 2010
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 at 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.
- 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.
- Not much info in the docs.
- 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
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 Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno at 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
More information about the dm-crypt