Re: zuluCrypt v3.0 released.

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

 



On Wed, Oct 05, 2011 at 05:07:34PM +0200, Quentin Lefebvre wrote:
> 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 ?

We had this discussion here several times for the  
LUKS master key.

The potential problem we identified with /dev/random was
entropy starvation. In an interactive application, this 
should not be a problem, just tell the user to move
the mouse a bit. It still can take a few secons to 
generate even 64 random bytes when the pool was just emptied.

Generally, /dev/urandom is enough even for key-grade
material. But making it configurable (as it is for 
cryptsetup) would be definitely a good idea. And then
having cryptsetup use the same when creating a LUKS
container.

Arno
-- 
Arno Wagner, Dr. sc. techn., 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
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt


[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