On 04/15/2015 05:17 AM, Frédéric Marchal wrote:
I understand that filling the encrypted partition (/dev/mapper/backup2) with
zeros is equivalent to filling the unencrypted partition (/dev/sdb1) with
random data as explained by other procedures.
I've found 'shred' to be the fastest way to fill a drive or partition
with random data.
Filling a dm-crypt mapped device file with all zeros gives an attacker
lots of predictable plain text for cracking your password.
(Formatting a dm-crypt mapped device file also provides a certain amount
of predictable plain text, but is unavoidable.)
It use /dev/urandom instead of the default /dev/random to generate the master
key. The documentation says it is better to use urandom as random may block if
the computer entropy is low.
/dev/random is for cryptographically secure random numbers, such as for
cryptographic keys. It requires a source of entropy to operate, and
will block until entropy is available. Thus, on most desktop computers,
it is only suitable for small amounts of random numbers.
On Linux, /proc/sys/kernel/random/entropy_avail contains the kernel's
estimate of available entropy (in bits):
https://en.wikipedia.org/wiki/Entropy_%28computing%29
2015-04-15 07:37:24 dpchrist@t2250 ~
$ cat /proc/sys/kernel/random/entropy_avail
2364
If /dev/random blocks, wiggle your mouse to create entropy.
/dev/urandom is for non-cryptographic/ low-security random numbers, such
as for games. It will use entropy as available, otherwise it will
mathematically generate pseudo-random numbers. It does not block and
can generate large amounts of random data quickly, but is vulnerable to
attack.
ISAAC seems to be a respected PRNG algorithm:
http://burtleburtle.net/bob/rand/isaacafa.html
Hardware random number generators promise the best of both worlds --
security and speed. For example, Intel SecureKey technology provides a
5 Gb/s stream of cryptographically secure random numbers:
https://software.intel.com/en-us/blogs/2012/05/14/what-is-intelr-secure-key-technology
Intel AES-NI technology accelerates software encryption/ decryption. My
3.2 GHz HT P4 machine without AES-NI is CPU bound around ~70 MB/s on one
HDD. My quad HT Core i7-2600S (1.6~3.8 GHz) with AES-NI has no problem
keeping up with 400+ MB/s RAID.
https://software.intel.com/en-us/articles/intel-advanced-encryption-standard-instructions-aes-ni
Error-correcting code (ECC) memory has higher reliability than non-ECC
memory.
https://en.wikipedia.org/wiki/ECC_memory
ECC memory is strongly advised for ZFS, as ZFS can destroy your data on
disk if you have memory problems:
https://www.google.com/?gws_rd=ssl#q=zfs+ecc
David
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/552e83fc.4090...@holgerdanske.com
