On Sun, Sep 09, 2012 at 10:27:44AM +0200, Milan Broz wrote: > On 09/09/2012 02:41 AM, Arno Wagner wrote: > > Hi all. > > > > I just wrote a very simple key-slot checker. It divides all > > active keyslots into 512 byte sectors and calculates entropy > > for each. For valid encrypted data, entropy will be close > > to 0.95 on average (would be 1, but this is sample entropy, > > calculated on a limited data set). > > Yes, this is something very useful. Thanks! > But 512 slots is quite small chunk of random data, there will be > some false warnings I guess. Very, very few. Remember that the data looks like high-quality randomness if correct. I might do a measurement how rarely, but with my test-header I had to go up to 0.93 (default is 0.85) to get a single false detection. And the entropy-threshold is tunable. > (Adding add test for the whole keyslot combined > with separate sectors? Not sure if it helps something though...) I don't think that is needed, but a sector-size option (with 0 = whole slot) is a possibility. > (Well, and it cannot obviously detect corruption with > overwriting random data :) That would be quite a trick ;-) > > No fancy output, no library usage (but verifies LUKS version), > > support for non-default key-sizes and setting your own entropy > > threshold. I put in 0.85 as default threshold, which should work > > well. > > > > Now I am not sure where to put it. Should I put it in > > misc/ in the sources? That seems to be sort of a contrib/ > > directory. Or should we add a section in the Wiki for > > tools? > > Parsing header on its own is something which should > not be even in misc section (in the worst case it should > include luks.h directly). I can do that. Just wanted to see whether it works first. > But anyway, this could be integrated into luks > format checker directly (and run in "check" cryptsetup command). That would probably be a good idea. Is that a new command? If you can point out were that is in the code, I can add these tests. > (And the same random test perhaps should be in tests for large > enough blocks - see tests/differ.c, there is nice fixme :-) Will have a look. > I am just not sure introducing floating point in libcryptsetup > is good idea. While this can be done without, it is really hard. Basically you eiher need to simulate the logarithm in fixed-point integer or build up huffman tree as direct entropy estimator. Easiest way would probably be fixed-point and a 1000-entry table for the log(). > But perhaps this can be compile time option, > if some ancient/embedded CPU/distro has problems here, > so it can be compiled-out. I like that idea much better. So, next step, make it use luks.h and put it in misc/ ? Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- One of the painful things about our time is that those who feel certainty are stupid, and those with any imagination and understanding are filled with doubt and indecision. -- Bertrand Russell _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
