[16391] in Kerberos_V5_Development
Re: random to key from password
daemon@ATHENA.MIT.EDU (Sam Hartman)
Mon Sep 27 16:42:28 2010
From: Sam Hartman <hartmans@mit.edu>
To: Nicolas Williams <Nicolas.Williams@oracle.com>
Date: Mon, 27 Sep 2010 16:42:14 -0400
In-Reply-To: <20100927203608.GO9501@oracle.com> (Nicolas Williams's message of
"Mon, 27 Sep 2010 15:36:08 -0500")
Message-ID: <tslaan2vryx.fsf@live.suchdamage.org>
MIME-Version: 1.0
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
>>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams@oracle.com> writes:
Nicolas> 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.
Nicolas> I definitely considered that, and decided not to mention
Nicolas> 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.
Nicolas> Indeed, but note that first you'd need to recover one of
Nicolas> the keys, then pre-image the string2key. Why bother with
Nicolas> the second step if you can complete the first one?
The KDC prefers AES to DES.
So, you'll never be able to use the DES key for much, but it exists and
you can somehow get some text to attack it.
However if you want to decrypt tickets, you're going to need the AES
key.
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
