Session key extraction

Luke Howard lukeh at
Mon Dec 22 18:21:02 EST 2008

> 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

More information about the krbdev mailing list