Comments on: Randomize First, Then Encrypt Your Block Device http://pthree.org/2012/02/20/randomize-first-the-encrypt-your-block-device/ Linux. GNU. Freedom. Fri, 17 May 2013 20:46:35 +0000 hourly 1 http://wordpress.org/?v=3.6-beta2-24176 By: Jim http://pthree.org/2012/02/20/randomize-first-the-encrypt-your-block-device/#comment-116457 Jim Sun, 26 Feb 2012 18:46:27 +0000 http://pthree.org/?p=2273#comment-116457 Any reason why you are using a block size of 1 byte with dd ? (bs=1)

]]> By: Jim http://pthree.org/2012/02/20/randomize-first-the-encrypt-your-block-device/#comment-116456 Jim Sun, 26 Feb 2012 18:36:17 +0000 http://pthree.org/?p=2273#comment-116456 Regarding comments 4 and 5, I agree it is best to lay down the random data first. The data to be protected should be mingled/integrated with random data as closely as possible, so that it fills partial blocks and metadata areas as explained above. Also, if you need to ever securely wipe the disk, having random data “underneath” your secured data might give better protection against phorensic data salvage, that’s only my hunch/speculation though.

]]> By: Aaron Toponce http://pthree.org/2012/02/20/randomize-first-the-encrypt-your-block-device/#comment-116445 Aaron Toponce Thu, 23 Feb 2012 02:20:42 +0000 http://pthree.org/?p=2273#comment-116445 patrickdk- So, it’s going to depend on your hardware, how much RAM you have, and how fast you can generate pseudorandom data, as well as the PRNG you use. If you absolutely need performance, then I would recommend booting off of a Knoppix CD, encrypting your drive, mounting it, and filling it with a file from /dev/zero. Then, reboot back into your installer and go from there. On my cheap workstation here at work, I can generate data from /dev/urandom at about 15 MBps, after RAM has been flushed.

]]> By: patrickdk http://pthree.org/2012/02/20/randomize-first-the-encrypt-your-block-device/#comment-116442 patrickdk Wed, 22 Feb 2012 20:24:45 +0000 http://pthree.org/?p=2273#comment-116442 Strange, this was tested with ubuntu 10.04 installed on a internal drive, and formatting anotherdrive. Even my servers dont get a urand more tham 4mb/sec. Maybe a kernel change recently?

]]> By: Aaron Toponce http://pthree.org/2012/02/20/randomize-first-the-encrypt-your-block-device/#comment-116441 Aaron Toponce Wed, 22 Feb 2012 14:53:04 +0000 http://pthree.org/?p=2273#comment-116441 patrickdk- Your performance will depend entirely on the PRNG that is used, and the device you’ve booted from. The debian installer uses the same PRNG that is found in the Linux kernel, and when booted off the CD, will move at a pace of about 30 MBps on my laptop hard drive, which is the max speed my drive can realistically do.

]]> By: patrickdk http://pthree.org/2012/02/20/randomize-first-the-encrypt-your-block-device/#comment-116440 patrickdk Wed, 22 Feb 2012 13:39:36 +0000 http://pthree.org/?p=2273#comment-116440 Using urandom is too slow, normally 3mb/sec. Just encrypt the block device, dd something to that device, then format it with you filesystem. This takes out not having random data in filesystem metadata areas. And so much faster than urandom, going at 50mb/s or faster even for slower cpus using aes.

]]> By: Aaron Toponce http://pthree.org/2012/02/20/randomize-first-the-encrypt-your-block-device/#comment-116438 Aaron Toponce Wed, 22 Feb 2012 12:07:09 +0000 http://pthree.org/?p=2273#comment-116438 gotfeed- Yes, the alternative installer does begin randomizing the disk, if you choose to do encrypted LVM.

]]> By: gotfeed http://pthree.org/2012/02/20/randomize-first-the-encrypt-your-block-device/#comment-116435 gotfeed Wed, 22 Feb 2012 03:37:54 +0000 http://pthree.org/?p=2273#comment-116435 Does the Ubuntu alternative image installer do this when you enable LVM with encryption during the installation?

]]> By: Aaron Toponce http://pthree.org/2012/02/20/randomize-first-the-encrypt-your-block-device/#comment-116434 Aaron Toponce Wed, 22 Feb 2012 02:37:35 +0000 http://pthree.org/?p=2273#comment-116434 textshell- Sure. You could just as easy fill your filesystem with random data after the install. Then, as your data needs expand, you will be effectively writing over where that random file existed. That works, but it shouldn’t be the first thing you do. You should put the random data down first, then format and install. But, if you forget to do so, then you can make that large random file, as it is certainly better than nothing.

]]> By: textshell http://pthree.org/2012/02/20/randomize-first-the-encrypt-your-block-device/#comment-116433 textshell Tue, 21 Feb 2012 23:24:45 +0000 http://pthree.org/?p=2273#comment-116433 Comment 4 makes quite a bit of sense that files written between creating the filesystem on a encrypted volume (without randomizing before) and filling it with some kind of data (ideally random) will have worse properties. But if the data does change a bit over time it would “age” out, wouldn’t it? Maybe it would be a good addition to your serien to discuss/visualize this a bit more explicit. Although it would be harder esp. with the aging.

]]> By: Aaron Toponce http://pthree.org/2012/02/20/randomize-first-the-encrypt-your-block-device/#comment-116432 Aaron Toponce Tue, 21 Feb 2012 14:54:07 +0000 http://pthree.org/?p=2273#comment-116432 Yes and no. This can be applied after setting up the filesystem, but then you’ll notice “spaces” in the encrypted output. This is because the underlying block device is writing data at either 512-byte or 4-kbyte blocks. Where the data doesn’t fill an entire block, there will be a space between it, and the start of the new file. These spaces will reveal file size and location, which will make watermarking and snapshot attacks a breeze.

]]> By: Mathias Hasselmann http://pthree.org/2012/02/20/randomize-first-the-encrypt-your-block-device/#comment-116431 Mathias Hasselmann Tue, 21 Feb 2012 12:13:40 +0000 http://pthree.org/?p=2273#comment-116431 Trivial fix:

# cp glider.bmp /mnt
+ # dd if=/dev/zero of=/mnt/fill bs=1
# umount /mnt

This step can be applied __after__ setting up the file system, but permits you to start working already. So no need to wait for hours. Actually wondering why Linux is not initializing free space of encrypted disking after setup. Could be considered a bug.

]]> By: Aaron Toponce http://pthree.org/2012/02/20/randomize-first-the-encrypt-your-block-device/#comment-116430 Aaron Toponce Tue, 21 Feb 2012 11:35:13 +0000 http://pthree.org/?p=2273#comment-116430 Absolutely! It will be clear from my next post, WHY you want to put random data underneath. There are some fairly effective attacks you can mount, to determine what sort of data is being hidden, and what it contains.

]]> By: Philipp Kern http://pthree.org/2012/02/20/randomize-first-the-encrypt-your-block-device/#comment-116429 Philipp Kern Tue, 21 Feb 2012 08:49:34 +0000 http://pthree.org/?p=2273#comment-116429 Well, you don’t really say why you need to do that. Sure, it’s visible from the outside where/how much data is stored. (Especially if you use discard with SSDs.) And it’s visible what kind of file system you use. But it shouldn’t make access to the encrypted data any easier, given that it still resembles random data, should it?

]]>