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@xxxxxxxxxx> 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@xxxxxxxxxxx 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 _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
