[18] in The Cryptographic File System users list
Re: Problem with cname / ccat
daemon@ATHENA.MIT.EDU (Matt Blaze)
Sun Dec 21 14:38:21 1997
From owner-cfs-users@research.att.com Sun Dec 21 14:38:20 1997
Received: from rumor.research.att.com (rumor.research.att.com [192.20.225.9]) by bloom-picayune.MIT.EDU (8.7.6/2.3JIK) with SMTP id OAA25460 for <cfs-mtg@bloom-picayune.mit.edu>; Sun, 21 Dec 1997 14:38:20 -0500
Received: from research.att.com ([135.207.30.100]) by rumor; Sun Dec 21 14:35:15 EST 1997
Received: from amontillado.research.att.com ([135.207.24.32]) by research-clone; Sun Dec 21 14:36:40 EST 1997
Received: from nsa.research.att.com (majordomo@nsa.research.att.com [135.207.24.155])
by amontillado.research.att.com (8.8.7/8.8.7) with ESMTP id OAA20526;
Sun, 21 Dec 1997 14:36:29 -0500 (EST)
Received: (from majordomo@localhost) by nsa.research.att.com (8.7.3/8.7.3) id OAA19695 for cfs-users-list; Sun, 21 Dec 1997 14:36:36 -0500 (EST)
X-Authentication-Warning: nsa.research.att.com: majordomo set sender to owner-cfs-users@nsa.research.att.com using -f
Received: from amontillado.research.att.com (amontillado.research.att.com [135.207.24.32]) by nsa.research.att.com (8.7.3/8.7.3) with ESMTP id OAA19691 for <cfs-users@nsa.research.att.com>; Sun, 21 Dec 1997 14:36:35 -0500 (EST)
Received: from nsa.research.att.com (root@nsa.research.att.com [135.207.24.155])
by amontillado.research.att.com (8.8.7/8.8.7) with ESMTP id OAA20521;
Sun, 21 Dec 1997 14:36:15 -0500 (EST)
Received: from nsa.research.att.com (mab@localhost.research.att.com [127.0.0.1]) by nsa.research.att.com (8.7.3/8.7.3) with ESMTP id OAA19684; Sun, 21 Dec 1997 14:36:32 -0500 (EST)
Message-Id: <199712211936.OAA19684@nsa.research.att.com>
To: res@colnet.cmhnet.org (Rob Stampfli)
cc: cfs-users@research.att.com
Subject: Re: Problem with cname / ccat
In-reply-to: Your message of "Sun, 21 Dec 1997 13:07:00 EST."
<m0xjpmg-0008FNC@colnet.cmhnet.org>
Date: Sun, 21 Dec 1997 14:36:31 -0500
From: Matt Blaze <mab@research.att.com>
Sender: owner-cfs-users@research.att.com
Precedence: bulk
>Although cname and ccat were purported to work again as of 1.3.3, it
>appears there are some passwords for which they still have problems:
>
> $ cmkdir -o1 t16
> Key: jkl;jkl;jkl;jkl;
> Again: jkl;jkl;jkl;jkl;
> $ cattach t16 16
> Key: jkl;jkl;jkl;jkl;
> $ cd /crypt/16
> $ echo hi >hi
> $ echo low >low
> $ cd ~/t16
> $ ls | cname -v
> WARNING: ccat works only on old format CFS files
> Key: jkl;jkl;jkl;jkl;
> 3f89024d75d9391d -> low
> ea4fc779c730d878 -> hi
> $
>
> $ cmkdir -o1 t20
> Key: jkl;jkl;jkl;jkl;jkl;
> Again: jkl;jkl;jkl;jkl;jkl;
> $ cattach t20 20
> Key: jkl;jkl;jkl;jkl;jkl;
> $ cd /crypt/20
> $ echo hi >hi
> $ echo low >low
> $ cd ~/t20
> $ ls | cname -v
> WARNING: ccat works only on old format CFS files
> Key: jkl;jkl;jkl;jkl;jkl;
> 1f863c28ca109acb -> ???
> b19a883fb5f3341d -> ???
> $
>
>It's not just the password length. I haven't delved into the code to
>any degree to figure out what is qualatatively "different" about the 2nd
>example which makes it break. Anyone have any ideas. This is on a Sun
>Sparc IPX running 4.1.4.
I just duplicated this. Figuring this out has absolutely made my
day.
This isn't a bug. The problem is that you forgot to specify -1 on
the cname command, so it's using the default cipher of 3des.
So why did it work at all in the first example, you ask? The
default cipher is 2-key 3DES, in EDE mode. The "old format" password
hash algorithm would split the passphrase in half, down the middle,
to generate DES keys k1 and k2. (Hey, it wasn't my code, what can
I say?)
In your 16 character example, these passphrase halves happen to be
exactly same! Recall that EDE mode with K1=K2 is exactly the same
as single DES, so it worked even though cname was running in 3des
mode.
In the 20 character example, the passphrase halves were (just a
little bit) different, so it didn't reduce to single DES.
Both examples will work if you add -1 to the cname arguments.
This rather broken passphrase hashing is a good reason NOT to use
old format, since (as you demonstrate), entropy may not be well
distributed among the two halves of the passphrase. Unfortunately,
cname for new format would require more extensive re-writing than
I was willing to do, since it would have to read the key file in
the root of the encrypted directory.
If people would like this functionality, I'll add it in a future
release (but not 1.4.0, which will be out by new year's, barring
any serious problems.).
-matt
