[dm-crypt] Key-Slot Checker Tool
arno at wagner.name
Sun Sep 9 15:35:12 CEST 2012
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.
> 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
> (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
> (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
> 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 Wagner, Dr. sc. techn., Dipl. Inform., Email: arno at wagner.name
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
More information about the dm-crypt