Message-ID: <CAOLP8p6FUFhcfv9kfYxe4dmkiUxmdqry-iBS4jgHsarVDHvXXA@mail.gmail.com>
Date: Tue, 3 Jun 2014 12:42:19 -0400
From: Bill Cox <waywardgeek@...il.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Re: [OT] GeekCrypt: a Secure Fork of TrueCrypt

On Tue, Jun 3, 2014 at 12:15 PM, Milan Broz <gmazyland@...il.com> wrote:

> Hi Bill,
>
> just for your information, there is another independent and GPL
> implementation of TrueCrypt format, inside cryptsetup code (Zulucrypt
> uses it for opening volume while using tc-play for creating the TC volume).
>
> Cryptsetup supports even old TC containers (in CBC and LRW mode
> and all possible combinations, except some limitation caused by
> Linux kernel), tc-play can open only XTS containers (but it
> can also create them).
> The underlying dm-crypt is the same.
>
> (The inability to create containers in cryptsetup is intentional, adding
> support for it is quite easy but primary format is LUKS. I do not
> want to split resources, so focusing to own native LUKS format).
> For more info see https://code.google.com/p/cryptsetup/
>

I saw this effort.  It looks awesome!  Working with the other teams doing
FOSS encryption tools is a no-brainer, and one of the main reasons I
currently do not trust the truecrypt.ch leaders.  In response to ZuluCrypt,
their more technical guy posted that he would be interested in buying them
out!  Yikes!

I think a major priority is bringing along all the TrueCrypt users to the
new platform.  To do that, I think a near-term release with minimal changes
to TrueCrypt should be built to give users confidence in the new team.  We
should just replace the art, the name, and respond to any issues found in
the ongoing audit.  After that, I think the crypto geeks from the various
projects should get together and come up with a roadmap that reduces
duplicate effort and improves security, while moving the TrueCrypt fork
towards a truly FOSS license.  I see no reason the project could not
ultimately be merged with the likes of tc-play, LUKS, and/or ZuluCrypt,
while potentially bringing a huge number of users to these projects.


> And to not to be completely of topic, my plan for next generation
> of LUKS is to use new KDF from PHC finalist, I have already some
> favorite candidates :-)
>

I hope TwoCats is one of them :-)  Honestly, adding a memory-hard password
hashing option to TrueCrypt, and maybe making it the default, was one of
the main reasons I got involved in password hashing.  All those poor
Windows users of TrueCrypt have no idea how easily their weak passwords can
be cracked.  I want to add a generic memory-hard hashing interface, similar
to the PHS call, and integrate Scrypt to start (or maybe Bcrypt or both).
It should be simple to add support for the PHC winner down the line.

I have to admit that for this specific application, I really like my
SkinnyCat subset, for it's simplicity and what I believe is it's easily
verifiable security.  I am most likely going to integrate Scrypt instead
because it's proven, but it's several times more complex, quite a bit
slower, and subject to significant TMTOs.  My other choice would be the
full Yescrypt, with all it's various levels of defense, which I believe
adds quite a bit more security, though at even more complexity than
Scrypt.  My full TwoCats would be my third choice :-)

And yes, the cryptsetup is just for Linux (for now).
>
> Sorry for off-topic,
> Milan
>
> p.s.
> TrueCrypt fork is nice but I am afraid of license problems,
> including possible inheritance code from E4M project etc.
>

The license is problematic, which is why the existing TrueCrypt code will
likely never make it into Debian or similar distros.  That's a major reason
why the GeekCrypt (or whatever) should work closely with the other FOSS
projects.  I think most or all of the code eventually has to be replaced,
but this has to be done carefully over time to maintain security while
keeping the huge TrueCrypt user base happy.

Bill

Content of type "text/html" skipped

Powered by blists - more mailing lists