On 3/08/2014 12:31 PM, David Christensen wrote:
> On 08/02/2014 12:16 PM, Joel Rees wrote:
>> As I understand it, he's asking whether any of us on the users list has
>> anaylyzed the output of both /dev/random and /dev/urandom . Not just
>> whether any of us are having issues with blocking, but with the
>> randomness
>> as well.
>
> Another metric is throughput. I recently wanted to fill a 3 TB HDD with
> random numbers prior to using it with LUKS, so I ran a test on my my
> Intel DQ67SW i7-2600S machine:
>
> # time dd if=/dev/urandom
> of=/dev/disk/by-id/ata-ST3000DM001-1CH166_W1F1R3VC bs=4M count=100
> 100+0 records in
> 100+0 records out
> 419430400 bytes (419 MB) copied, 29.2232 s, 14.4 MB/s
>
> real 0m29.225s
> user 0m0.000s
> sys 0m27.922s
>
> This is more than an order of magnitude slower than the drive's
> sequential write throughput.
I think you are going about doing LUKS poorly.
You need good random to get the key, so lots of entropy and use of
/dev/random ... not /dev/urandom. You get your key using luksFomat
options when creating your volume.
After you have formatted your volume, but before you start using it, you
use dd to write /dev/zero to the entire volume -- due to the encryption
process, those zeros will be just random data based on the key, it
should be quicker that way ... calculated data for zero for that
particular byte of the disk, rather than blocking on /dev/random or
being /less/ real random by using /dev/urandom.
Here is an example of what I do when setting up LUKS volumes.
# cryptsetup -c aes-xts-plain64 -s 512 -h sha512 -i 6000 \
-y --use-random luksFormat /dev/md3
Explanations:
-c specifies the algorithm (here AES with XTS)
aes-xts-plain64 (for +2tb volumes)
[default is aes-cbc-essiv (xts plain may be more
secure)]
-s specifies the length of the encryption key
(XTS uses two keys, each being 256 bytes)
-h specifies the hashing algorithm
-i specifies the number of milliseconds to spend with
PBKDF2 passphrase processing
-y asks for the passphrase two times (as confirmation)
--use-random
--use-urandom
For luksFormat these options define which
kernel random number generator will be used to
create the master key (which is a long-term
key).
See NOTES ON RANDOM NUMBER GENERATORS for more
information. Use cryptsetup --help to show the
compiled-in default random number generator.
WARNING: In a low-entropy situation (e.g. in
an embedded system), both selections are
problematic. Using /dev/urandom can lead to
weak keys. Using /dev/random can block a long
time, potentially forever, if not enough
entropy can be harvested by the kernel.
# cryptsetup -v status u1
/dev/mapper/u1 is active.
type: LUKS1
cipher: aes-xts-plain64
keysize: 512 bits
device: /dev/md3
offset: 4096 sectors
size: 7813766784 sectors
mode: read/write
Command successful.
Once the volume is created, it is time to write /dev/zero across the
entire volume.
pv -tpreb /dev/zero | dd of=/dev/mapper/u1 bs=16M
Hope that helps.
Cheers
A.
Attachment:
signature.asc
Description: OpenPGP digital signature