2

I've created a few encrypted devices with LUKS and cryptsetup on Linux and am pretty comfortable with disk encryption in this regard.

I've seen it mentioned in many different places that when setting up a LUKS partition/disk, it is advisable to first overwrite the entire partition/disk with /dev/urandom. I've seen a few places that advise that this isn't necessary, as the disk can be overwritten using the cipher, which is much faster. (/dev/urandom max on a 4.6GHz system can get over 20MB/s, whereas I'm sure that an AES-256 CBC cipher can run at over 2GB/s, which means that my encryption of the disk could run at 100 to 102.4 times faster if I'm using the cipher as opposed to /dev/urandom, disk speed being the limiting factor here).

Is using the cipher to initialize the disk as "secure" as using /dev/urandom? I would assume so, as output data should be theoretically indistinguishable between the two.

Also, how do you do this to overwrite the entire partition/disk using the cipher? I've lost the link and can't remember how to do it.

  • You can also use shred to overwrite a disk with random data, it's often faster than dd'ing /dev/urandom to the disk. – user42178 Jan 21 '15 at 3:06
  • Why would shred be faster? It uses /dev/urandom – Naftuli Kay Jan 21 '15 at 3:45
  • 1
    Not by default – user42178 Jan 21 '15 at 4:04
  • I wouldn't use shred in this case unless I was certain that its internal RNG is cryptographically secure, since the intention seems to be to disguise the full extent of the cryptographic partition (e.g., it might be on a 1TB drive, but contain only 1MB of data). If the output isn't cryptographically random, it could be possible to distinguish between parts of the disk that have been written to by the encrypted filesystem and parts that haven't. – Stephen Touset Jan 21 '15 at 4:59
3

To use the kernel's crypto module to initialize the partition/disk do this:

cryptsetup create --key-file=/dev/urandom eraseme /dev/sde
dd if=/dev/zero bs=1M of=/dev/mapper/eraseme
cryptsetup remove eraseme

This initializes a crypto mapping named eraseme spanning the partition/disk using data from /dev/urandom as the key. Writes zeros to the mapping and then deletes the mapping. Use --cipher option to use non-default cipher if required.

It is much faster than reading from urandom. On my computer, writing to a ramdisk I get these performance figures:

  • 640 MB/s zeros (dd if=/dev/zero bs=1M of=/dev/sde)
  • 270 MB/s crypto module using default cipher aes-cbc-essiv:sha256 (commands as above)
  • 8.7 MB/s urandom (dd if=/dev/urandom bs=1M of=/dev/sde)
  • How does the kernel know when to stop reading /dev/urandom for the key? How much randomness does it read from /dev/urandom before deciding that it has enough material for a key? – Naftuli Kay Mar 8 '15 at 22:25
  • It is the cryptsetup program that is reading /dev/urandom for the key. man cryptsetup is your friend. Default key size in 256 bits (32 bytes). This is how much cryptsetup reads from /dev/urandom for the key. Confirmed by stracing cryptsetup. – Mike Fleetwood Mar 9 '15 at 8:48
  • I imagine using aes-cbc-plain would be faster than aes-cbc-essiv:sha256. When you're just wiping the whole thing, I doubt you need to use the latter. You just need an unpredictable stream of randomness, not protection from malleability, chosen ciphertext attacks, or anything of the sort. You could probably get away with using AES128 too (-s 128), as that would be faster and still completely random. – forest Apr 5 '16 at 3:17
1

/dev/urandom is basically just a stream cipher, only with periodic reseeding from its entropy sources to protect against its state or entropy sources becoming compromised.

Given that it's extremely unlikely the state of your cipher will become compromised while you initialize the disk, that if this happened an attacker has enough control over your system that you're likely screwed anyway, and the fact that the random numbers aren't actually being used for something like cryptographic key material, there is no concern I can think of with initializing the disk by writing to it the output of a cipher initialized with a random key and IV.

  • So I'm right my assumption that the output from the cipher would be indistinguishable from /dev/urandom? – Naftuli Kay Jan 21 '15 at 2:31
  • 3
    The output of any cryptographically-sound cipher should be indistinguishable from random. – Stephen Touset Jan 21 '15 at 2:32
  • /dev/urandom is not a stream cipher. Stream cipher is not a synonym for CSPRNG, you know, even if the output is indistinguishable (due to being, well, cryptographically secure when used to generate random numbers). What /dev/urandom really is is a CSPRNG based on mixing SHA-1 digests. Example stream ciphers are ChaCha20 and RC4. SHA-1, and mixing SHA-1 most certainly do not count as stream ciphers. – forest Apr 5 '16 at 3:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.