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 padl.com> wrote:
>> I could see a protocol having its own (ill-advised) constraints on
>> encryption or checksumming is done such that it would want to pull
>> 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] 18.104.22.168.10, [MS-KILE] 22.214.171.124 and [MS-SMB]
>>> I'm very uncomfortable with this concept: using a session key
>>> knowing what kind of key it is or what structure it is seems kind of
>> I'd be interested in exploring these risks before deciding the
>> 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
>> 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 mit.edu
More information about the krbdev