From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6UhM21IbEIRN for ; Sun, 9 Sep 2012 10:27:49 +0200 (CEST) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Sun, 9 Sep 2012 10:27:49 +0200 (CEST) Received: by wibhr14 with SMTP id hr14so985098wib.1 for ; Sun, 09 Sep 2012 01:27:48 -0700 (PDT) Message-ID: <504C5300.5030102@gmail.com> Date: Sun, 09 Sep 2012 10:27:44 +0200 From: Milan Broz MIME-Version: 1.0 References: <20120909004109.GA6421@tansi.org> In-Reply-To: <20120909004109.GA6421@tansi.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dm-crypt] Key-Slot Checker Tool List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de 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. (Adding add test for the whole keyslot combined with separate sectors? Not sure if it helps something though...) (Well, and it cannot obviously detect corruption with overwriting random data :) > 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). But anyway, this could be integrated into luks format checker directly (and run in "check" cryptsetup command). (And the same random test perhaps should be in tests for large enough blocks - see tests/differ.c, there is nice fixme :-) I am just not sure introducing floating point in libcryptsetup is good idea. But perhaps this can be compile time option, if some ancient/embedded CPU/distro has problems here, so it can be compiled-out. Milan