Re: [xmpp] key+data object encryption (regarding draft-miller-3923bis-01)

[Matthew Miller <[e-mail]>]

On Mar 16, 2010, at 10:57, Ben Schumacher wrote:

> On 3/16/10 10:15 AM, Matthew Miller wrote:

> This makes sense, but can you provide more detail on the contents of the
> <data/> element? Would there be some guidelines on how to generate a
> strong key in the specification? I note that it has a 'hash' attribute,
> can I assume that this is a hash of the encrypted (or decrypted?)
> message contents? Is this really a hash, or rather an HMAC that can be
> used to provide message authentication? Preferably we could provide a
> mechanism to ensure that the encrypted data hasn't been tampered with in
> transit, which would allow us to make a decision up front as to whether
> we should go forward with the decryption of the message -- this would
> help protect from a potential attack against bugs in our decryption
> engine that could be a vecotr for a DoS.

When we started on this, there was no secret appropriate to salt the HMAC.  With the above approach, we could use the session key data as that salt and use HMAC SHA256.  That would mean the contents to data would now be:

N = current timestamp
R = session cipher inputs (e.g. key + IV)
S = stanza
T = encrypt(R, hmac(R, N + UTF8-Encode(S)) + UTF8-Encode(S))

Which would result in something like the following:

<message xmlns="jabber:client" type="chat" to="[e-mail]" from="[e-mail]/balcony">
  <e2e xmlns="urn:ietf:params:xml:ns:xmpp-objec" stamp="2010-03-09T16:29:43.012Z">
    <key cipher="RSAES-OAEP-SHA-256-MFG1">
      PrGA6extyYdY6sFWk7/+YAvTglZe4GSglWeTshada6+GOKqVViK17FIvR9TQcSTB
      Ak1YcKr5Oa8ok0bf9gQzscwastKho72NaJ9NplTuDOZ4I3e3ZXhcN5iXoJYkVMHf
      scz20vYK170b5FYKorlQ/cgXw62slxb51t6jgCKZ+bUDpcalUmepU56y7Wwy+OwE
      buP2B1tr5XFVX1r0+epObTfdunCr/N1GphuVP70108lCavZhRLO1gNAC+6FEA75E
      pelvYstXaCHbXkkWT03AY02p//L4pdoyGQK+ZbJJjOfRndFTGMx1DJApkySRaQhW
      P2+5HpJMJ6jeWCyPAawK8A==
    </key>
    <data cipher="AES-256-CBC-PKCS5-WITH-IV" mac="HMACSHA256">
      lM06rZtX5YXi+jrlNOKdsydMjAcVkAcJCZ8lncIgIF1CatVVTtIoachMHFm3XV7a
      SyEjrVO1P8Sdd3MTdOn1o+ktJvI66zAVWFL/aCoJbcwO1BUKtIn4AOG76V7kSYBj
      CDzWD7Hus620TEah/h1K/9Au6RHjWB78qpVLPLiROlZSH9Pw5sg4eDOKeusffSyb
      gcHDGXlDEVduWViaNWfIl6fboHiZXVfsU4ZPlxMXW41WjXVB1wwlfIUnsjL8e0Xc
      106EkLR5XM9E6vT3MNY0UeOJO89W3t3RzKkZfFhWKn3ALPjoikRyEvdvw7baRD3O
    </data>
  </e2e>
</message>

> 
> I haven't followed the entire discussion on this specification, but is
> there a rational for using PKCS1 v1.5 (which has known weaknesses in
> some implementations) instead of using the stronger RSAES-OEAP[1]
> specification?

The only reason is that when we started, we did not have access to RSAES-OAEP implementations.  I have no problem upgrading, assuming there's no general dissent.

> 
> These are all (mostly) off-the-cuff remarks, but I will spend more time
> with the specification to make sure I'm not missing anything.
> 
> Cheers,
> Ben

Thanks for even this initial look.  The draft itself is still pretty immature, so I'm sure there's plenty we'll need to hash out still


- m&m