Does anyone know of a *fast* cryptographically secure psuedo random number generator? /dev/urandom is indeed too slow. There is a Linux module called frandom available, which uses RC4 to generate a keystream, but the author has no intention of modifying it to be suitable for cryptography. Wouldn't take much to write a little command line tool if none exists, AES-128 in CTR, using /dev/random for the key. On Mon, May 19, 2008 at 12:21 AM, Arno Wagner <arno@xxxxxxxxxxx> wrote: > I should add that hiding does not work very well if the other side > has the power to make you give them the key, e.g. at a US border > crossing. Personally I have been using cryptographically strong > randomness to wipe diskss and empty space, something I will not do > in the aforementioned situation. There is a good chance the "refusal" > to divulge the keys for the "encrypted data" will get you sent > back or worse. > > The basic problem is that encrypted areas (or areas wiped with > cryptographically strong randomness) are easy to identify: > They do no have any recognizable patterns in them, which can be > identified, e.g., by high entropy or incompressibility. A quick > test is significantly faster than a disk read. Avoiding false > positives from compressed data is by hard-coding the patterns > all popular compressors generate. > > These analysis techniques also work against the "open one, have > one other hidden in it" technique some people advise to use > with TrueCrypt. It is not hard to see that some stuff is still > encrypted in these cases. Incidentially, entropy analysis also > works against steganography, if you hide a lot of data. > > My Advice would be to use encryption only when you have a > defensible position in case the attacker suspects you have > encrypted data. In that case hiding the data may not be necessary > in the first place. > > Incidentially, actually proving some data is encrypted is not possible > from the encrypted data itself, e.g. when using dm-crypt. (With LUKS > there is the header, which may be enough to convince a court.) As long > as you have the protection of due process and there is no other proof > that the "random data" is encrypted data, the "this was overwritten by > cryptographic randomness" defense works. Remember that at a border > crossing and in some countries you may not have the protection of due > process. It will also be fascinating to observe what the british > authorities will do in case somebody uses this defense, as any > competent cryptographer will confirm its validity. > > Bottom line: Hiding encrypted volumes is far less useful than > commonly assumed. The legal situation is far more important. > > Arno > > > P.S.: Procedure I use to wipe a disk is as below. I developed > this as I had to wipe 50 disks in the 100-250GB range > in a secure fashion and it is the fastest option under > Linux, unless a zero-wipe (which may or may not be insecure) > is enough. > > 1. Setup the whole device with dm-crypt and a long random key > 2. dd_rescue -w /dev/zero /dev/mapper/<device> > (Use "cat /dev/zero > /dev/mapper/device" for batch operation.) > > Using /dev/(u)random as input is far slower. Incidentlially, > a disk wiped this way is indistinguishable from a disk > that is encrypted, unless you have the key. As long as > there is no legal obligation avoid any suspicion, this > procedure is also fine legally. > > > On Sun, May 18, 2008 at 12:45:31PM +0930, Roscoe wrote: >> Woops, if you do try to hide things with an offset, just use dm-crypt, >> LUKS has an identified header. >> >> On Sun, May 18, 2008 at 12:30 PM, Roscoe <eocsor@xxxxxxxxx> wrote: >> > No. >> > >> > You could try to superficially hide things by setting up the mapping >> > with some offset if you really wanted. >> > >> > >> > >> > On Sun, May 18, 2008 at 12:11 PM, Lurkos <lurkos.usenet@xxxxxxxxx> wrote: >> >> Does LUKS format support hidden volumes (using dm-crypt on Linux and >> >> FreeOTFE on Windows) such as Truecrypt? >> >> >> >> P.S.: Where can I find the archive of the mailing list? >> >> >> >> --------------------------------------------------------------------- >> >> dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/ >> >> To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx >> >> For additional commands, e-mail: dm-crypt-help@xxxxxxxx >> >> >> >> >> > >> >> --------------------------------------------------------------------- >> dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/ >> To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx >> For additional commands, e-mail: dm-crypt-help@xxxxxxxx >> > > -- > Arno Wagner, Dipl. Inform., CISSP --- Email: arno@xxxxxxxxxxx > GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F > ---- > Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans > > If it's in the news, don't worry about it. The very definition of > "news" is "something that hardly ever happens." -- Bruce Schneier > > --------------------------------------------------------------------- > dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/ > To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx > For additional commands, e-mail: dm-crypt-help@xxxxxxxx > > --------------------------------------------------------------------- dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/ To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx For additional commands, e-mail: dm-crypt-help@xxxxxxxx