fast CSPRNG? [Was Re: Hidden volumes]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux