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

From: Matthew Miller <[email-masked]>
Date: Tue, 16 Mar 2010 10:15:40 -0600

One of the limitations with draft-miller-3923bis is the size of the stanza before encryption.  Using asymmetric keys, the practical size is limited to the key size.  One approach we can take to overcome this would be to encrypt the stanza using a block cipher, then encrypt the block cipher input with the recipient's asymmetric key:

<message xmlns="jabber:client" type="chat" to="[email-masked]" from="[email-masked]/balcony">
  <e2e xmlns="urn:ietf:params:xml:ns:xmpp-objec" stamp="2010-03-09T16:29:43.012Z">
    <key cipher="RSAES-PKCS1-v1.5">WQcrIQki6omXfrugOUl8BqA0W7ztgT8/k79p9dqpyGZQP9NoIEwp+uJE80xa4edZadJkbDQ60I7Y
l0muQ006Ib4mx9T7+hH4JGPYtNrDhlAUzTzR2IGR/5AfpkYews6aYNX5PpAP43f9qtztSmMqTi0q
9NfdoSw2/P2e+WUTc0DqfcWMPw6PIaIbfEgNnwm14SYYYkGdtuzRjUJu0lCBaX+HNccGN+CAKWG3
7Bh29DGndbqKGD25e9HP+0jzxgt0+GOf8WGWtHvFodNhxJ5/W542EWx9O/jyyeCfbb7C2M1EfEta
0a088Vi3ysvFzYsoROoqYDy7qvR3x76DiMFR4g==</key>
    <data cipher="AES-256-CBC-PKCS5-with-iv" hash="SHA-256">MFO2gCbTu8+sHE6QNDylDkeghYxdnXvp+zZ2HDUGBNAeRxuf5oLtOqpU5FjC6NSMw8jdVXpfLG41
p8MJDRdRahJ088YoCHzimHW9EwqQyJmZHZzVTRJFYZnwxtUZMqtifi9dalQ5u5nNWIqDXK434fnU
LcAmzPzcsI/OQcBPLeu2iCEoFEwkNML+ag0Q5zP6xHDfzqXt9r391igecNZN9koqdC3l3Jwx605W
UkcxNxe3zWw9Q6wl1GLn/tNiyQCkqaQNU893gp0MHVAaPyUem5TJGa+tZo6UM/MnooTs3L+qbHcs
k7hVkNYnE8eBLJS8</data>
  </e2e>
</message>

This makes <e2e/> a container of two parts: the <key/> containing the inputs for the block cipher (encrypted using PKI), and <data/> containing the pre-encrypted stanza (encrypted using a block cipher with inputs from <key/>).

Thoughts?

- m&m

---

From: "Ben Schumacher" <[email-masked]>
Date: Tue, 16 Mar 2010 09:57:41 -0700

On 3/16/10 10:15 AM, Matthew Miller wrote:
> This makes<e2e/>  a container of two parts: the<key/>  containing the inputs for the block cipher (encrypted using PKI), and<data/>  containing the pre-encrypted stanza (encrypted using a block cipher with inputs from<key/>).
>
>
> Thoughts?
>    
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.

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?

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

[1] http://www.ietf.org/rfc/rfc3447.txt

---

From: Matthew Miller <[email-masked]>
Date: Tue, 16 Mar 2010 12:42:51 -0600

> 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="[email-masked]" from="[email-masked]/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>

> some implementations) instead of using the stronger RSAES-OEAP[1]

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.

> with the specification to make sure I'm not missing anything.

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

---

From: "Ben Schumacher" <[email-masked]>
Date: Wed, 17 Mar 2010 13:00:08 -0700

>        106EkLR5XM9E6vT3MNY0UeOJO89W3t3RzKkZfFhWKn3ALPjoikRyEvdvw7baRD3O
Have we considered using Encrypt-then-MAC, instead of the 
MAC-then-Encrypt for your message authentication? Both methods ought to 
provide a good assurance that the message hasn't been tampered with, but 
the Encrypt-then-MAC method can provide an added level of protection 
against software bugs in your decryption code [1].

Your message would them become something akin to:

N = current timestamp
R = session cipher input (e.g. key + IV)
S = stanza
a = HMAC(N || UTF8-Encode(S), R)
T = a || encrypt(R, N || UTF8-Encode(S))

Where || detonates concatenation.

You'll want to specify a fixed size for N, or including some sizing 
information in the decoded bytes. You might also consider versioning in 
your format for the decoded bytes to handle future adjustments to the 
protocol. You could do this by adding a simple message header, with than 
includes a single byte for version (apologies for my hackneyed ABNF):

plaintext    = header-part / stanza-part

header-part  = tag / version / stamp-part
tag          = "xmpp-objec"
version      = 2*HEXDIG           ; network byte order (NBO) version
stamp-part   = stamp-length / stamp-string
stamp-length = 4*HEXDIG           ; NBO length of stamp-string
stamp-string = *VCHAR             ; a known format is likely preferable 
(ISO-8601),
                                   ; but knowing the length frees you 
from making an
                                   ; assumption about precision

stanza-part  = stanza / stanza-end
stanza       = *CHAR              ; UTF-8 encoded, naturally
stanza-end   = NUL

This would all, of course, be encrypted. The ending NUL gives your XML 
parser an easily identifiable ending point to the stanza, but you could 
also include a length for the stanza in the format.

Let me know if any of that doesn't make sense.

Cheers,
Ben

[1] http://www.daemonology.net/blog/2009-06-24-encrypt-then-mac.html

---

From: Matt Miller <[email-masked]>
Date: Wed, 31 Mar 2010 08:47:49 -0600

> Where || detonates concatenation.

This makes sense to me.  I'll look at updating the draft to incorporate this unless there's strong objections.

> Let me know if any of that doesn't make sense.

I don't see a benefit of including versioning information here.  All of this is defined as the (encrypted and encoded) character content of a namespaced XML structure.  Wouldn't it be better to version this via the namespace instead?

- m&m