Subject: RE: Withdrawing concern about s2kparams and salt in encrypteddata

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Thu, 12 Feb 2004 21:15:43 -0800

I do not object to using keys directly but rather think of enabling both
approaches. The cost of converting is mostly not related to this
protocol but administrative/deployment issues associated with adding the
additional parameters to the string2key operation and associated admin
education. 

Discovery via AES_REQ does not solve everything, what if the acceptor
can not contact the KDC, perhaps because of connectivity issues such as
the presence of a firewall?

The disadvantage of sending out the s2kparameter directly is that it
does leak the fact that the key was transformed from a passphrase, but I
would argue that we can obfuscate that by always sending out the
string2key parameter. The salt/s2kparameter fields are just garbage when
a key is used directly.  This obfuscation should be turned off if such
information is either not sensitive (say using our current model) or
easily discoverable.

But perhaps the proposal looked uglier than it really is. So here is the
new "EncryptedData" I would propose.

   EncryptedData   ::= SEQUENCE {
           etype   [0] ETYPE-INFO2-ENTRY -- EtypeInfo --,
           kvno    [1] UInt32 OPTIONAL,
           cipher  [2] OCTET STRING -- ciphertext
   }

Does this look a bit cleaner?

Larry
-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Nicolas
Williams
Sent: Thursday, February 12, 2004 2:31 PM
To: Ken Raeburn
Cc: [email-masked]
Subject: Re: Withdrawing concern about s2kparams and salt in
encrypteddata

I'm starting to find this ugly again.

What alternatives does MS have?  Larry, have you explorer other
solutions?

Nico
--