daniele.athome at gmail.com
Tue Feb 3 12:11:02 UTC 2015
Of course, I was just talking about a deterministic way of describing the
encrypted data - and to save bandwidth.
Anyway the point of metadata leakage is valid. We (as in XMPP) do what we
can and we encrypt what we can. Anonymity was never the scope of XMPP.
On 3 Feb 2015 12:59, "Bartosz Małkowski" <bmalkowski at tigase.pl> wrote:
> > Wiadomość napisana przez Daniele Ricci <daniele.athome at gmail.com> w
> dniu 3 lut 2015, o godz. 12:20:
> > The only problem here is how to recognise the encrypted data? Is it a
> > text body or a stanza? Maybe we can use a "type" attribute to <otr/>,
> > revealing more metadata? Or maybe we could add a header to the
> > encrypted data:
> I don’t understand.
> If client receives <message><otr>…
> then it will decrypt data and expect that result of decryption is stanza
> (or maybe other element allowed in XMPP Stream), then client will process
> received and decrypted element like any other received elements.
> Look at https://tools.ietf.org/html/draft-miller-xmpp-e2e-02 (4.3.
> Example - Securing a Message). The same idea.
> Bartosz Małkowski
> Tigase Polska
> xmpp:bmalkow at malkowscy.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards