Subject: [xmpp] XMPP stanza encryption + EXI compression

From: Peter Waher <[email-masked]>
Date: Thu, 14 Mar 2013 15:25:45 +0000

Dear Matt

I just became aware of your  IETF draft for XMPP end-to-end encryption. It looks very promising.
http://tools.ietf.org/html/draft-miller-xmpp-e2e-05

We work with sensor network architecture over XMPP, and some (but not all) applications require end-to-end encryption, so we want to look at this extension.

At the same time, compression is a vital issue, since many sensors have limited memory. Therefore, we are working with an effort to include the use of EXI in XMPP. (See attached documents.) One important aspect to know, when including EXI into XMPP, is that packets cannot be binary copied when the server relays the information. The packets have to be decompressed, and re-compressed if both peers have EXI-compressed channels. This requires EXI to be applied after any message encryption transformation: Exi1(Encrypt(Xml)). Server then relays Exi2(DeExi1(Exi1(Encrypt(Xml)))) = Exi2(Encrypt(Xml)) to the second peer.

The problem with this is that EXI does not do very well with base64-encoded binary data. Size(Exi(Base64(Bin))) would approximately be equal to Size(Bin). EXI would be able to cut the added length imposed by the base64 encoding, due to its limited character set.

It would be nice with an end-to-end encryption method over XMPP that would also be able to take into account EXI compression of XML stanzas.

If you have time, any comments would be appreciated,

Sincerely,
Peter Waher

-----Original Message-----
From: Peter Saint-Andre [mailto:[email-masked]] 
Sent: den 14 mars 2013 11:57
To: Peter Waher
Cc: Joachim Lindborg ([email-masked]); Matt Miller
Subject: Re: XMPP stanza encryption

On 3/14/13 10:53 AM, Peter Waher wrote:
> Hello Peter
> 
> Do you participate in this work? 
> http://tools.ietf.org/html/draft-miller-xmpp-e2e-05

Only indirectly, by chatting once in a while with Matt Miller (cc'd).

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Richard Barnes <[email-masked]>
Date: Thu, 14 Mar 2013 13:19:19 -0400

I think you'll find that if you try to compress after encrypting, you're
going to have a bad time.  Exi1(Encrypt(Xml)) is not going to buy you
anything besides some wasted cycles.
--Richard

On Thu, Mar 14, 2013 at 11:25 AM, Peter Waher <[email-masked]>wrote:

> We work with sensor network architecture over XMPP, and some (but not all)
> applications require end-to-end encryption, so we want to look at this
> extension.
>
> At the same time, compression is a vital issue, since many sensors have
> limited memory. Therefore, we are working with an effort to include the use
> of EXI in XMPP. (See attached documents.) One important aspect to know,
> when including EXI into XMPP, is that packets cannot be binary copied when
> the server relays the information. The packets have to be decompressed, and
> re-compressed if both peers have EXI-compressed channels. This requires EXI
> to be applied after any message encryption transformation:
> Exi1(Encrypt(Xml)). Server then relays Exi2(DeExi1(Exi1(Encrypt(Xml)))) =
> Exi2(Encrypt(Xml)) to the second peer.
>
> The problem with this is that EXI does not do very well with
> base64-encoded binary data. Size(Exi(Base64(Bin))) would approximately be
> equal to Size(Bin). EXI would be able to cut the added length imposed by
> the base64 encoding, due to its limited character set.
>
> It would be nice with an end-to-end encryption method over XMPP that would
> also be able to take into account EXI compression of XML stanzas.
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJRQeU7AAoJEOoGpJErxa2p6y8P/jHGYyu4DxkpgjIlxIyP/ROF
> KfHkaOQ9kzVqEP+fWzajYK9MW8NzaGkF8w8L43o6sXbbFxtmIIZgiUpG2G9uMg8w
> 6yBrR+JbDHTSpq9bEjrA55jKjVHAQjXUpEvT71zvpqpMa8GU4mM8oLad/ETkg0QI
> YJsfGal66rSA9ZXdr78U8C7pOIFNhgV6SdLHUq1TF9jpXghXAN7bvRtGgPJk1jea
> QN45YW//Zq9NMK0KK+MmgmK+JPsb3/MM7uFSp90FTUQY7/iF1ngjoA/3tqOiaQMW
> E8Q40DIRXjzXHiiKMTwle7Q1zLP1Jm86aJp8iScsRy0OxNSH9s5NQ7AaD5ZTl/BL
> 64oiA9dLpcc/RZf/7kWDp7D7zEHli2yJG+tO0gagJHqfOt8R/WCeJR10hrBQ76rj
> JbwBqWwJRMrY1SnqlntBfhMklC7ZzkuXMn75QtqkQlflJ//6v53AcCglZBLpIurT
> xaHHO6IUvsjOvoRov1m65HTtOb9qwepPOJ4mo78bRure2HgBKBCNZRyRZPy6s8lU
> OuXqciZjDmKxMlO/A4nGMu2OP7ZcrWo58t1p7sckbC4q4YDoVBTPvA3KlcQB1kPm
> YlIGtme+MEVHVm6LvJq+Gm5C8cvXM1nB2lmHvcEWJfcSVkT03EGRKLNZm4aWchMN
> 4s30FwvW1t9EukM+RGy6
> =EN9u
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> xmpp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xmpp
>
>

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Tue, 19 Mar 2013 15:34:00 +0000

I'm not well versed enough in EXI to know if there are special considerations for purely binary data, and I'm not sure what changes I can make to a specification that is focused on what RFCs 6120 and 6121 define.

However, encrypted data is a very big blob of binary that, by its very nature of appearing to be random, is extremely unlike to compress at all.  To gain any benefit, you'd want to compress *before* encrypting.

- m&m

Matt Miller < [email-masked] >
Cisco Systems, Inc.

On Mar 14, 2013, at 9:25 AM, Peter Waher <[email-masked]> wrote:

> <xep-0000-Exi.html><xep-0000-Exi.xml><xep-0000-Exi.xsd>