[16390] in Kerberos_V5_Development
Re: random to key from password
daemon@ATHENA.MIT.EDU (Nicolas Williams)
Mon Sep 27 16:38:17 2010
Date: Mon, 27 Sep 2010 15:36:08 -0500
From: Nicolas Williams <Nicolas.Williams@oracle.com>
To: Sam Hartman <hartmans@mit.edu>
Message-ID: <20100927203608.GO9501@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <tsllj6nuf5b.fsf_-_@live.suchdamage.org>
Cc: lha@h5l.org, Russ Allbery <rra@stanford.edu>, krbdev@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On Mon, Sep 27, 2010 at 04:04:32PM -0400, Sam Hartman wrote:
> >>>>> "Russ" == Russ Allbery <rra@stanford.edu> writes:
> Russ> If you made this change globally (rather than making it an
> Russ> option, such as in Heimdal), then it would apply to
> Russ> keytab-only principals such as host/* keys as well. Do we
> Russ> lose any security benefit from having all the enctypes have
> Russ> independent keys the way that we get now with -randkey? (Or
> Russ> at least I always assumed we got that now; maybe we don't?)
>
> Hmm.
> Possibly.
I definitely considered that, and decided not to mention the possibility
in my post for two reasons I give below.
> If one of the string2key functions is easier to preimage than another,
> then you could potentially find one of the stronger keys more easily.
Indeed, but note that first you'd need to recover one of the keys, then
pre-image the string2key. Why bother with the second step if you can
complete the first one?
A more worrisome attack would be a cryptanalysis that can recover the
password without having to recover the key first. Such an attack would
almost certainly need ciphertexts in different enctypes, of known
plaintexts, in keys derived from the same password. I'm not certain,
but I suspect very little work has been done in that sort of
cryptanalysis -- not comforting, but at the same time such techniques
seem unlikely any time soon, and they would seem likely to require
advances in cryptanalysis of the endividual ciphers, and if they surface
you can always go back to randomized keys.
> That could be an issue in a case such as encryption of server tickets
> where the KDC would not actually use the weaker enctype.
Huh? If a service principal has a key for a weak enctype then either,
a) there are no stronger enctypes in use, in which case the attacker
won't care about recovering the principal's password (the key will do),
or b) the key for the weak enctype won't be used at all, thus giving
attackers no ciphertexts to work with.
Nico
--
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
