Session key extraction

Stephen C. Buckley sbuckley at MIT.EDU
Mon Dec 22 21:08:32 EST 2008

So one advantage to adopting the same vices as our friends is that we  
can all help one another outgrow them.


Sent from my mobile device.

On Dec 22, 2008, at 6:21 PM, Luke Howard <lukeh at> wrote:

>> I could see a protocol having its own (ill-advised) constraints on  
>> how
>> encryption or checksumming is done such that it would want to pull  
>> out
>> the key.
> SMB uses it for SMB signing and application-layer encryption with RC4.
> DRS uses it for encrypting directory attributes with RC4 (with derived
> keys). See [MS-DRSR], [MS-KILE] and [MS-SMB]
>>> I'm very uncomfortable with this concept: using a session key  
>>> without
>>> knowing what kind of key it is or what structure it is seems kind of
>>> dangerous.
>> I'd be interested in exploring these risks before deciding the
>> interface
>> is a bad idea.  In another medium, Sam mentioned:
> I agree it's a bad idea but it is a requirement for Windows
> interoperability. Otherwise vendors will need to fork Kerberos (as
> Novell has done with DSfW), build their own GSS implementation (as
> Samba 3 has done) or use an alternative Kerberos distribution (as
> Samba 4 has done).
>> 1. DES keys are not uniformly distributed.  This could be addressed  
>> by
>> removing the DES key "structure" (the parity bits) to yield a 56-bit
>> key.  Are there other conventional cryptosystems which have key
>> structures which are not so easy to remove?
> Windows from memory uses the parity bits.
> -- Luke
> _______________________________________________
> krbdev mailing list             krbdev at

More information about the krbdev mailing list