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 uNdDExWTlG94 for ; Wed, 5 Oct 2011 17:15:07 +0200 (CEST) Received: from sout.laposte.net (sout3.laposte.net [193.253.67.237]) by mail.saout.de (Postfix) with ESMTP for ; Wed, 5 Oct 2011 17:15:07 +0200 (CEST) Message-ID: <4E8C72B6.1040302@laposte.net> Date: Wed, 05 Oct 2011 17:07:34 +0200 From: Quentin Lefebvre MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dm-crypt] zuluCrypt v3.0 released. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de Hi, This looks like a very nice project. On 05/10/2011 08:28, .. ink .. wrote : > project page: http://code.google.com/p/zulucrypt/ > > screenshots of the new release: > https://picasaweb.google.com/109794855728648275729/ZuluCryptV30?authuser=0&feat=directlink > > video showing features of the new release: > https://docs.google.com/leaf?id=0B8juRKTjN4Q9Njk0MTY4OWQtODcyMi00MGY2LTg5ODktOTg2MGYyNGRiNzI1&hl=en_US > > This release put cryptsetup/zuluCrypt at the same level as truecrypt feature > wise when used from the GUI. > > It can now (from the GUI) > 1. Create key files( 512 bytes in size composed of only the 94 printable > characters). 512 bits rather than bytes ? > 2. Create volumes both in files and partitions. > 3. Create both plain type and luks types volumes. > 4. Add keys to luks type volumes. > 5 . Delete keys from luks type volumes. > 6. Close a bunch of bugs. > > All volume management can be done through either passphrases or key files. > > The core functionality is now in place and next version(version 4) will be > for GUI user configuration options of things like font type, font size, use > of tray icon and maintaining a list of favorite volumes. > I just took a look at the screenshots and I'm a bit surprised about the fact keys are generated from /dev/urandom. Even for 512 bits, that is 64 bytes, wouldn't it be better to read key files from /dev/random ? Unless there is a setting allowing the user to explicitly choose the source ? Best, Quentin