[Standards] end to end encryption vs. usability and feature

[default at clientside.co.uk]

Salut Olivier,

Olivier Goffart wrote:
> The public key is routed thought the server, which is not trusted. 
> So the server can send another key to the contact, and be the
> "man in the middle"
[snip]
> the server is free to modify them.

The issue is not how the contact receives your key (it is a public key after 
all). There are many ways - all out of scope for the e2e XEPs, none of which 
are dependent on XEP-0189. (In one archiving mode XEP-0136 is dependent on XEP-
0189.)

The issue for e2e is how to verify whose key it is. This can be achieved in 
many ways, perhaps the most usable of which is the one we all use with SSH 
(i.e. our SSH client verifies it is the same key as we used every time 
before). In practice the requirement for the man in the middle to have 
interfered from the start provides significant protection to people who don't 
take care of their security. The e2e XEPs use a very similar method.

In an ideal world, we would all verify the full SSH fingerprint the very first 
time, but (almost) noone does. XEP-0116 improves on SSH by incorporating Short 
Authentication String, a technique inspired by ZRTP, that enables much easier 
verification.

> I have not read all the security XEP, because they are way too long. 

Maybe you should inform yourself better? As well as the XEPs I highly 
recommend reading the papers on SIGMA, OTR and ZRTP. You'll see the measures 
included in the XEPs are considered worthwhile by respected security experts. 
We hope a security expert will be examining the protocol for us in depth later 
this year.

Cryptography is quite complex and notoriously difficult to get right. IMHO it 
is difficult for anyone to comment usefully on security without first either 
reading the protocols carefully, or becoming a cryptographic expert. 
(Something I, despite working on these protocols for a couple of years, am 
certainly not.)

- Ian