[dm-crypt] request for zulucrypt to be mentioned in cryptsetup main page.

[dm-crypt] request for zulucrypt to be mentioned in cryptsetup main page.

[.. ink ..]

[-- Attachment #1: Type: text/plain, Size: 583 bytes --]

just committed support for opening both mass storage devices and files using
 either a pass phrase or a key-file both in the command line and GUI. Both
will be officially supported when i make a new release sometime before the
wee is over.

What feature(s) must the project gain to be mentioned in cryptsetup main
page?
Who must i contant to request the project be mentioned like
"FreeOTFE<http://freeotfe.org/>
"?

Is there a limit of how small or big a key-file is supposed to be? what
about passphrases?

The project i am talking about is att: http://code.google.com/p/zulucrypt/

[-- Attachment #2: Type: text/html, Size: 1561 bytes --]

Re: [dm-crypt] request for zulucrypt to be mentioned in cryptsetup main page.

[Sven Eschenberg]

Well, it would not make to much sense to have more entropy in your keyfile
than your MK is long. As such, as little as MK-bits of entropy in the
keyfile are sufficient. On the other hand there are no contraints of
minimum key length, that's all up to the user, afaik.

You should consider though increasing the iteration time, when the
passphrase is short. The shorter the phrase (the less entropy) the more
iterations in Key Stretching should be done, otherwise you could aswell
save the computational power wasted in the encryption.

On a sidenote: As far as I know cryptsetup will read no more than MK-Bits
from keyfiles, but Milan should be able to tell you for sure. This would
mean though, that a keyfile is expected to have good entropy.

Best approach of course would be to determine the entropy of the
keyfile/passphrase, compare it to the requested keylength (and mode) and
then decide what to do: Reject, compensate by key stretching, Accept.

Regards

-Sven

On Thu, September 15, 2011 02:41, .. ink .. wrote:
> just committed support for opening both mass storage devices and files
> using
>  either a pass phrase or a key-file both in the command line and GUI. Both
> will be officially supported when i make a new release sometime before the
> wee is over.
>
> What feature(s) must the project gain to be mentioned in cryptsetup main
> page?
> Who must i contant to request the project be mentioned like
> "FreeOTFE<http://freeotfe.org/>
> "?
>
> Is there a limit of how small or big a key-file is supposed to be? what
> about passphrases?
>
> The project i am talking about is att: http://code.google.com/p/zulucrypt/
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

Re: [dm-crypt] request for zulucrypt to be mentioned in cryptsetup main page.

[Arno Wagner]

On Thu, Sep 15, 2011 at 08:20:38AM +0200, Sven Eschenberg wrote:
> Well, it would not make to much sense to have more entropy in your keyfile
> than your MK is long. As such, as little as MK-bits of entropy in the
> keyfile are sufficient. 

True, but keep in mind that you do not necessarily have 1 bit/bit
of entropy in the input. In fact you basically never have that.
So what you do is read more to create a safety margin.

> On the other hand there are no contraints of
> minimum key length, that's all up to the user, afaik.
> 
> You should consider though increasing the iteration time, when the
> passphrase is short. The shorter the phrase (the less entropy) the more
> iterations in Key Stretching should be done, otherwise you could aswell
> save the computational power wasted in the encryption.

Unfortunately, passphrase length is only very weakly connected to
entropy contents. This approach would tehrefore be dangerous.
What you do is to always iterate like you have a low-entropy
passphrase, no matter what the passphrase looks like.

Example:

"Researcher Builds Life-Like Cells Made of Metal"

would typically be seen as having about 120 bits of entropy
(2/char). However this is a slashdot headline ans has more
realistically abouy 15 bits of entropy (my WAG) as a realistic
measure...

> On a sidenote: As far as I know cryptsetup will read no more than MK-Bits
> from keyfiles, but Milan should be able to tell you for sure. This would
> mean though, that a keyfile is expected to have good entropy.

THe keyfile for a master key is the master key verbatim, i.e.
no hasing, iteration, salting. A keyfile containing a passphrase
is different and goes though the normal process. As such it
can have arbtrary length. Ther is a aprameter to constrain
maximum lenght read. This is useful when reading, e.g. from
/dev/urandom and to cut off a lne end.


> Best approach of course would be to determine the entropy of the
> keyfile/passphrase, compare it to the requested keylength (and mode) and

In practice this is infeasible, see example above.

> then decide what to do: Reject, compensate by key stretching, Accept.

You basically can only accept and hope the user knows what they do.

Arno

> Regards
> 
> -Sven
> 
> On Thu, September 15, 2011 02:41, .. ink .. wrote:
> > just committed support for opening both mass storage devices and files
> > using
> >  either a pass phrase or a key-file both in the command line and GUI. Both
> > will be officially supported when i make a new release sometime before the
> > wee is over.
> >
> > What feature(s) must the project gain to be mentioned in cryptsetup main
> > page?
> > Who must i contant to request the project be mentioned like
> > "FreeOTFE<http://freeotfe.org/>
> > "?
> >
> > Is there a limit of how small or big a key-file is supposed to be? what
> > about passphrases?
> >
> > The project i am talking about is att: http://code.google.com/p/zulucrypt/
> > _______________________________________________
> > dm-crypt mailing list
> > dm-crypt@saout.de
> > http://www.saout.de/mailman/listinfo/dm-crypt
> >
> 
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
> 

-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
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 

Re: [dm-crypt] request for zulucrypt to be mentioned in cryptsetup main page.

[Sven Eschenberg]

Hi Arno,

On Thu, September 15, 2011 11:00, Arno Wagner wrote:
> On Thu, Sep 15, 2011 at 08:20:38AM +0200, Sven Eschenberg wrote:
>> Well, it would not make to much sense to have more entropy in your
>> keyfile
>> than your MK is long. As such, as little as MK-bits of entropy in the
>> keyfile are sufficient.
>
> True, but keep in mind that you do not necessarily have 1 bit/bit
> of entropy in the input. In fact you basically never have that.
> So what you do is read more to create a safety margin.

That's true, if you have access to a good HW-RNG that does provide a good
quality, you should be save though (If you can trust that Entropy source
of course). I personally tend to use 64 bytes from /dev/random for
passphrases when MK is 256 bit, hoping the safety margin is big enough.

>
>> On the other hand there are no contraints of
>> minimum key length, that's all up to the user, afaik.
>>
>> You should consider though increasing the iteration time, when the
>> passphrase is short. The shorter the phrase (the less entropy) the more
>> iterations in Key Stretching should be done, otherwise you could aswell
>> save the computational power wasted in the encryption.
>
> Unfortunately, passphrase length is only very weakly connected to
> entropy contents. This approach would tehrefore be dangerous.
> What you do is to always iterate like you have a low-entropy
> passphrase, no matter what the passphrase looks like.
>
> Example:
>
> "Researcher Builds Life-Like Cells Made of Metal"

That is true, I had something in mind like: Passphrase should be at least
128 chars (or maybe 256) and add to the iteration time for every char
less, if you add 100ms for every char missing to fulfill 256 chars as
passphrase length ...

But then again, the usability worsens, imagine users using 8-10 chars for
their passphrase only *g*.

>
> would typically be seen as having about 120 bits of entropy
> (2/char). However this is a slashdot headline ans has more
> realistically abouy 15 bits of entropy (my WAG) as a realistic
> measure...
>
>> On a sidenote: As far as I know cryptsetup will read no more than
>> MK-Bits
>> from keyfiles, but Milan should be able to tell you for sure. This would
>> mean though, that a keyfile is expected to have good entropy.
>
> THe keyfile for a master key is the master key verbatim, i.e.
> no hasing, iteration, salting. A keyfile containing a passphrase
> is different and goes though the normal process. As such it
> can have arbtrary length. Ther is a aprameter to constrain
> maximum lenght read. This is useful when reading, e.g. from
> /dev/urandom and to cut off a lne end.
>

Thanks for clarifying this.

>
>> Best approach of course would be to determine the entropy of the
>> keyfile/passphrase, compare it to the requested keylength (and mode) and
>
> In practice this is infeasible, see example above.

Coming back to the example, I suggested *calculating* the entropy instead
of a char count. I was thinking of good old Mr. Shannon there. That should
give a feasible measurement of the passphrase quality. Of course this
cannot take into account attacks based on dictionaries...

>
>> then decide what to do: Reject, compensate by key stretching, Accept.
>
> You basically can only accept and hope the user knows what they do.

Of course in a perfect world, we could hope for users knowing what they
are doing ;-).

>
> Arno
>

-Sven

>> Regards
>>
>> -Sven
>>
>> On Thu, September 15, 2011 02:41, .. ink .. wrote:
>> > just committed support for opening both mass storage devices and files
>> > using
>> >  either a pass phrase or a key-file both in the command line and GUI.
>> Both
>> > will be officially supported when i make a new release sometime before
>> the
>> > wee is over.
>> >
>> > What feature(s) must the project gain to be mentioned in cryptsetup
>> main
>> > page?
>> > Who must i contant to request the project be mentioned like
>> > "FreeOTFE<http://freeotfe.org/>
>> > "?
>> >
>> > Is there a limit of how small or big a key-file is supposed to be?
>> what
>> > about passphrases?
>> >
>> > The project i am talking about is att:
>> http://code.google.com/p/zulucrypt/
>> > _______________________________________________
>> > dm-crypt mailing list
>> > dm-crypt@saout.de
>> > http://www.saout.de/mailman/listinfo/dm-crypt
>> >
>>
>>
>> _______________________________________________
>> dm-crypt mailing list
>> dm-crypt@saout.de
>> http://www.saout.de/mailman/listinfo/dm-crypt
>>
>
> --
> Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email:
> arno@wagner.name
> 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@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

Re: [dm-crypt] request for zulucrypt to be mentioned in cryptsetup main page.

[Arno Wagner]

On Thu, Sep 15, 2011 at 06:08:46PM +0200, Sven Eschenberg wrote:
> Hi Arno,
[...]
> >> Best approach of course would be to determine the entropy of the
> >> keyfile/passphrase, compare it to the requested keylength (and mode) and
> >
> > In practice this is infeasible, see example above.
> 
> Coming back to the example, I suggested *calculating* the entropy instead
> of a char count. I was thinking of good old Mr. Shannon there. That should
> give a feasible measurement of the passphrase quality. Of course this
> cannot take into account attacks based on dictionaries...

Does not work, as you cannot have a good source model. Shannon 
entropy assumes a source without memory, i.e. emitted symbols
are independent. In practice you combine not independent symbols 
(bits) into symbols large enough to get a reasonable approximation 
of that. The approximation quality is very much dependent on 
the application however. (Trust me, I did a PhD on entropy 
estimation ;-)

In my example, I give you two source models: 

1. single-character (byte) model for emglish, with 1.5...2.5 bit/char 
   of entropy. This model is easy to implement but potentially hugely  
   inaccurate, see examnple.
2. Whole passprase as 1 symbol model. This one is accurate, but
   cannot be implemented as a table that can neiter be generated
   nor stored would be needed. The best approximation I can
   come up with for this is to google the passphrase (with outer 
   quotes). That would still be pretty bad and tell google 
   and your web-browser and potential proxies your passphrase.

There are more models, but all that are implementable have
rather bad failure possibilities or are hugely expensive in
terms of time and space. Many are both.

See also FAQ entry on selecting Passphrases, especally the
Harry Potter example.

> >
> >> then decide what to do: Reject, compensate by key stretching, Accept.
> >
> > You basically can only accept and hope the user knows what they do.
> 
> Of course in a perfect world, we could hope for users knowing what they
> are doing ;-).

Salting helps. Iteraton helps. But testing passphrase quality
is only possible in an one-sided way, i.e. you can recognize
some bad ones, but you can not recognize good ones. 

Sorry, for burting this bubble. Your apporach is intuitive and
if it could be implemented it would be the way to go, but it cannot
be implemented well. The only two safe approaches are

1. Assume the passphrase may be low-entropy. Offer the best possible
   security for that. This is what LUKS does. If the user messes
   up, there is still some securit level.

2. Assme the passphrase is high-entropy and warn the user accordingly.
   This is the plain dm-crypt approach. If the user messes up,
   security is gone. n the plus side this is easy to implement,
   does not need any metadata and is fast.

Both approaches have their place. LUKS does a pretty good
job for novices. Still, understanding passphrases is required
for a secure selection. 

I have described both approaches in the cryptsetup FAQ in detail.
Anybody that wanst to can find out how to do it right. Those
that do not care will never have real security anyways.

See also http://xkcd.com/936/ Probably will add that to the FAQ
as well. Note that the second example uses a word-entropy model
and requires the words to be random. 

Arno
-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
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