# random numbers before HD encryption?

## LoTeK

Hi,

Finally I have cleaned up my HD's and now I want to set up everything new with a clean backup strategy, encryption and synchronizing my data on different HD's.

I have 2 60GB, 1 1TB and 1 2TB HD and I'm not sure if I should overwrite them with random numbers before encryption. All 4 HD were encrypted with dm-crypt before I cleaned up.

Does it make sense to overwrite them with /dev/random ? if yes I would move one computer away from my sleeping room and let him work for 2 weeks (or even longer?).

[edit]:

from wikipedia:

 *Quote:*   

> ..It (/dev/random) allows access to environmental noise collected from device drivers and other sources.

 

so it's a real random number generator and not a pseudo-random-generator, isn't it?

when the computer just works without user input, is there enough noise for /dev/random? otherwise it would block, until there is enough entropy, so it could run for a year or so?

----------

## broken_chaos

If they were all always encrypted, then there is little point to overwriting them with random data. The only point in that case would be to, if some portions of the drive had never been used (i.e., never were written to in previous usage) hide that certain areas are empty -- which doesn't really provide much extra security in most use cases.

If you do decide to overwrite them with random data, use /dev/urandom. /dev/random does not have much entropy -- nowhere near enough needed for >3TB of space, as it would likely take years to finish and make the computer unusable for some normal tasks while doing so. /dev/urandom is more than enough security for drives which will be encrypted and have never held sensitive unencrypted data. (If they have held sensitive, unencrypted data in the past, then I'd suggest looking into doing an ATA security erase, as well as a couple passes with /dev/zero or /dev/urandom if you want to beextremely paranoid -- one pass with any of those options should be enough on its own, though.)

----------

## NeddySeagoon

/dev/urandom is very slow.

----------

## LoTeK

 *Quote:*   

> If they were all always encrypted, then there is little point to overwriting them with random data. The only point in that case would be to, if some portions of the drive had never been used (i.e., never were written to in previous usage) hide that certain areas are empty -- which doesn't really provide much extra security in most use cases. 

 

I received some of them from friends and I don't know what was on them. 

 *Quote:*   

> If you do decide to overwrite them with random data, use /dev/urandom. /dev/random does not have much entropy -- nowhere near enough needed for >3TB of space, as it would likely take years to finish and make the computer unusable for some normal tasks while doing so. 

 

I've decided to overwrite them with /dev/urandom. since I have two computers it doesn't matter if one is unusable, but years are too long   :Smile: 

I overwrite them at the same time (which is probably not good for the randomness, since I guess they "share" it?)

 *Quote:*   

> /dev/urandom is very slow.

 

yes, but there isn't any alternative, or is there any? 1-2 weeks are acceptable for me.

 *Quote:*   

> /dev/urandom is more than enough security for drives which will be encrypted and have never held sensitive unencrypted data. (If they have held sensitive, unencrypted data in the past, then I'd suggest looking into doing an ATA security erase, as well as a couple passes with /dev/zero or /dev/urandom if you want to beextremely paranoid -- one pass with any of those options should be enough on its own, though.)

 

I've read that there may be keyloggers in all closed BIOS's, so this whole encryption stuff doesn't make any sense when the attacker has access to them.

Lets define some attacker levels:

level 0: NSA and equivalent organizations 

level 1: FBI, higher police organizations and highly organized and equipped crime organizations

level 2: regular police 

level 3: burglar with some IT skills and equippment

level 4: regular burglar

so with encryption you can protect yourself against level 2 to level 4, which is good because the only thing that could happen to me is that my HD's get stolen, but on the other hand I would like to be able to say: not even the NSA could steel my informations   :Smile: 

So it's impossible to protect your data against something like the NSA ?

----------

## Apheus

You can overwrite with something which looks like random data by creating an encrypted mapping:

```
cryptsetup -c aes-xts-plain -h ripemd160 -s 256 -d /dev/urandom wipe /dev/sdb
```

There you have a plaintext-view at /dev/mapper/wipe which corresponds to encrypted /dev/sdb, using a pseudo-random 256-bit key derived from urandom.

Then you write zero's to the plaintext view, wiping your /dev/sdb with junk data in the process:

```
dd if=/dev/zero of=/dev/mapper/wipe
```

Limiting factor should be the disk's write speed, since zero's are cheap and AES is implemented with good perfomance (at least on HDD's, don't know about SSD's).

You need crypt target support in your kernel, and I think also AES and XTS kernel support. See man cryptsetup for possible ciphers and hashes.

----------

## NeddySeagoon

LoTeK,

All you ever wanted to know about randomness

You used to be able to get 1Mbit of random bits/day for free.

----------

## John R. Graham

 *NeddySeagoon wrote:*   

> /dev/urandom is very slow.

 Well, it's not all that slow. On my modest Celeron work box,

```
 $ dd bs=1M if=/dev/urandom of=/dev/null count=1024

1024+0 records in

1024+0 records out

1073741824 bytes (1.1 GB) copied, 140.907 s, 7.6 MB/s
```

- John

----------

## NeddySeagoon

John R. Graham,

Your HDD will probably do 120Mb/sec, so 7.6 MB/s is very slow.

----------

## kernelOfTruth

https://wiki.archlinux.org/index.php/Frandom anyone ?

that should be good enough, right ?

it's widely used on custom Android ROMs / mods and speeds up things a lot

----------

## John R. Graham

That actually looks really interesting, but the elephant in the room is, if you're only going to make a single pass, you might as well use /dev/zero. When I truly care, what I use is app-misc/wipe, which has some built-in expertise on the number of passes needed to sufficiently randomize the magnetic fringe.

For speed, wipe contains an internal implementation of the Mersenne Twister PRNG, which is seeded from /dev/urandom, which is itself seeded from /dev/random. A good PRNG is just fine for this purpose; actually, a good PRNG, properly seeded, is just fine for the vast majority of needs for randomness.

- John

----------

## NeddySeagoon

John R. Graham,

 *Quote:*   

> ... which has some built-in expertise on the number of passes needed to sufficiently randomize the magnetic fringe.

 

Have you upset the NSA sometime?

----------

## John R. Graham

Heh. No, but physical and logical security architecture is my day job.   :Wink: 

"Unrecoverable" doesn't mean, "Recoverable only with special tools."

- John

----------

## NeddySeagoon

John R. Graham,

I'm aware of the difference :)

What do you do about remapped sectors on a HDD then, since you can't get to the old physical sectors from the drives normal interface ?

----------

## John R. Graham

Yes, I'm aware of that, too. The answer is twofold:First, the enhanced mode SECURITY ERASE UNIT ATA command writes to all sectors on the device, relocated or not. (I had to go back to look at what we did for this case.)

Second, anything that's really sensitive shouldn't go onto external media in the clear in the first place. If it was never there, then it can't be a security risk, right?We have some handling procedures for especially sensitive material that requires used magnetic media to be degaussed and subsequently smashed with a sledgehammer. Of course, it's a little hard to reuse it afterwards.

- John

----------

