View previous topic :: View next topic |
Author |
Message |
LoTeK Apprentice
Joined: 26 Jul 2012 Posts: 270
|
Posted: Thu Jul 04, 2013 12:10 pm Post subject: random numbers before HD encryption? |
|
|
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? _________________ "I want to see gamma rays! I want to hear X-rays! Do you see the absurdity of what I am? I can't even express these things properly because I have to conceptualize complex ideas in this stupid limiting spoken language!" |
|
Back to top |
|
|
broken_chaos Guru
Joined: 18 Jan 2006 Posts: 370 Location: Ontario, Canada
|
Posted: Thu Jul 04, 2013 7:37 pm Post subject: |
|
|
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.) |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54099 Location: 56N 3W
|
Posted: Thu Jul 04, 2013 8:53 pm Post subject: |
|
|
/dev/urandom is very slow. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
LoTeK Apprentice
Joined: 26 Jul 2012 Posts: 270
|
Posted: Fri Jul 05, 2013 1:07 pm Post subject: |
|
|
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
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
So it's impossible to protect your data against something like the NSA ? _________________ "I want to see gamma rays! I want to hear X-rays! Do you see the absurdity of what I am? I can't even express these things properly because I have to conceptualize complex ideas in this stupid limiting spoken language!" |
|
Back to top |
|
|
Apheus Guru
Joined: 12 Jul 2008 Posts: 422
|
Posted: Fri Jul 05, 2013 1:23 pm Post subject: |
|
|
You can overwrite with something which looks like random data by creating an encrypted mapping:
Code: | 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:
Code: | 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. |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54099 Location: 56N 3W
|
Posted: Fri Jul 05, 2013 5:51 pm Post subject: |
|
|
LoTeK,
All you ever wanted to know about randomness
You used to be able to get 1Mbit of random bits/day for free. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
John R. Graham Administrator
Joined: 08 Mar 2005 Posts: 10587 Location: Somewhere over Atlanta, Georgia
|
Posted: Fri Jul 05, 2013 6:05 pm Post subject: |
|
|
NeddySeagoon wrote: | /dev/urandom is very slow. | Well, it's not all that slow. On my modest Celeron work box, Code: | $ 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 _________________ I can confirm that I have received between 0 and 499 National Security Letters. |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54099 Location: 56N 3W
|
Posted: Fri Jul 05, 2013 6:11 pm Post subject: |
|
|
John R. Graham,
Your HDD will probably do 120Mb/sec, so 7.6 MB/s is very slow. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
kernelOfTruth Watchman
Joined: 20 Dec 2005 Posts: 6111 Location: Vienna, Austria; Germany; hello world :)
|
|
Back to top |
|
|
John R. Graham Administrator
Joined: 08 Mar 2005 Posts: 10587 Location: Somewhere over Atlanta, Georgia
|
Posted: Sun Jul 07, 2013 5:07 pm Post subject: |
|
|
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 _________________ I can confirm that I have received between 0 and 499 National Security Letters. |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54099 Location: 56N 3W
|
Posted: Sun Jul 07, 2013 8:14 pm Post subject: |
|
|
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? _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
John R. Graham Administrator
Joined: 08 Mar 2005 Posts: 10587 Location: Somewhere over Atlanta, Georgia
|
Posted: Sun Jul 07, 2013 9:43 pm Post subject: |
|
|
Heh. No, but physical and logical security architecture is my day job.
"Unrecoverable" doesn't mean, "Recoverable only with special tools."
- John _________________ I can confirm that I have received between 0 and 499 National Security Letters.
Last edited by John R. Graham on Sun Jul 07, 2013 9:49 pm; edited 1 time in total |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54099 Location: 56N 3W
|
Posted: Sun Jul 07, 2013 9:48 pm Post subject: |
|
|
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 ? _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
John R. Graham Administrator
Joined: 08 Mar 2005 Posts: 10587 Location: Somewhere over Atlanta, Georgia
|
Posted: Sun Jul 07, 2013 10:03 pm Post subject: |
|
|
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 _________________ I can confirm that I have received between 0 and 499 National Security Letters. |
|
Back to top |
|
|
|