Session key extraction

[Stephen C. Buckley]

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

S

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  
>> 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] 4.1.10.5.10, [MS-KILE] 3.1.1.2 and [MS-SMB]
> 3.1.1.2.
>
>>> 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 mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev