lkml.org 
[lkml]   [2000]   [Sep]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH/KERNELI] Util-linux 3des update
Gisle S{lensminde wrote:

> On Fri, 22 Sep 2000, Alexander S A Kjeldaas wrote:
>
> > On Fri, Sep 22, 2000 at 11:46:02AM +0200, Gisle Sælensminde wrote:
> > >
> > > Since des_ede3(3des) now is added to the international kernel, it will
> > > probably be a good idea to add support for it in losetup, so here is
> > > a patch to the kerneli version of util-linux-2.10m / kerneli 2.2.17.3
> > >
> > > Since this is crypto-related the patch is found at the URL:
> > >
> > > ftp://ftp.ii.uib.no/pub/gisle/kerneli/patch.util-linux.3des
> > >
> > >
> > > DES_EDE3 needs bytes of key data, but ripemd160 used as hash the
> > > passphrase only provides 20 bytes of key data. To get 24 bytes of key
> > > data, the an uppercase 'A' is concatenated with the passphrase, and this
> > > string is hashed to get another 20 bytes of key data. Similar methods is
> > > used in SSL and SSH to get the session keys from the key exchange.
> > >
> > Just curious. Do you know whether this strengthens security at all?

No. Adding data the attacker knows cannot make the attack harder to any
significant extent. At best, it might increase attack overheads by some
small factor. What you need for security are things that cost little or
nothing for legitmate users but increase attack difficulty exponentially.

> > I
> > would guess that the security can not be better than if we used
> > RIPE-MD320 to hash the passphrase, and that hash is considered to have
> > the same security as RIPE-MD160.

A nice match for 3DES might be the Tiger hash. 192-bit output, faster
than SHA or MD5 on 64-bit machines, about the same on 32-bit.

http://www.cs.technion.ac.il/~biham/Reports/Tiger/

> The scheme don't limit the entropy of the key to 160 bits if the
> passpharse has more entropy than that,

Yes it does. If the passphrase entropy is 100 bits, the best brute
force attack is to try all 2^100 possibilities. If it is 200 bits,
or 500, the best brute force attack is to ignore the passphrase
and try the 2^160 possible outputs from the first hash. There is
no case where you have to try all 2^192 possible 3DES keys against
this scheme.

Of course, this likely does not matter provided the passphrase has
adequate entropy, say 90 bits based on:

http://www.counterpane.com/keylength.html

or perhaps 100 today, given Moore's law. As long as you have enough
entropy to frustrate brute force attacks, the exact amount is not
important.

> so the scheme should be suitable.
> Keylength of 160 bit is anyway a large margin for this kind of use.

Yes, but short or weak passphrases are a serious danger.

> A drawback by changing hash is that people will no longer be able to mount
> their encrypted disks with the new version of losetup. This version is a
> pure extensions to be able to use algorithms with more than 160 bit
> keysize. It will probably be a bad idea to break compatibility when no
> significant security improvment can be archieved.
>
> I'm almost certain that nobody have passphrases with more than 160 bits of
> real entropy.

My guess would be that most passphrases have far less than that. Estimates
I've seen for normal English text are not much over 1 bit/character. You
might use nonsense in a passphrase, so perhaps 2 to 4 bits? At that rate,
you need a 40 to 80 character passphrase to get 160-bit entropy.

Also, if people are constructing pass phrases in some predictable way, there
are attacks based on that. e.g try a dictionary of quotations, and write
programs to do standard substitutions, both at character level:

"n0w is the time f0r all good men to come to the aid 0f the c0untry"

and, following some grammatical rules, at word level:

"now is the time for all good wombats to come to the aid of the motorcycle"

I'm not certain how expensive or how effective such attacks would be, but
they are certainly possible and, given several decades of experience with
users choosing bad passwords, I'd be willing to wager they would work in
at least some cases.

> I don't think that the overall security for the system will
> increse, neither with this patch nor with a change to ripemd-320. Of that
> reason I prefere compatibility unless ripemd-160 should be broken some
> time in the future.
>
I agree there.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:45    [W:0.045 / U:0.368 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site