[Standards] end to end encryption vs. usability and feature
ogoffart at kde.org
Mon Feb 26 21:22:18 UTC 2007
I heard that the XSF want to push end-to-end encryption for everyone in order
to have a "secure" network with respect the privacy.
I think this is not worth, and this is even a bad thing.
I have not read all the security XEP, because they are way too long.
Anyway, here is what i understand :
TLS is actually used to encrypt internet connection between clients and
servers, and between servers. So the servevers are the only point of
faillure. One of the assumption (that need to be proved) is that we don't
trust servers, so end-to-end encryption is required.
But a normal user don't care about privacy.
So it need to be simple, or nobody will use it. And that's why existing
extentions like PGP are used only by geeks : because generating keys and
sharing them is complex.
So to work, we need a simple, and automatic and transparent for the user way
to do e2e encryption.
But I pretend this is not possible !
Let's see some protocol like OTR :
You generate a private and public key, and you send the public key to your
contact so it can generate a session key with it.
Problem : the public key is routed thought the server, which is not trusted.
So the server can sand another key to the contact, and be the "man in the
There is no way to get this working without key certification, which can't be
user friendly. (no way to make this transparent for the user)
Also, I think the server can be trusted. The server is an entity you may
choose. You can use a server hosted in the country you wish. You may even run
the server yourself. And if the server is trusted, and if TLS is used, all
the chain is secure, without e2e encryption.
The problem with e2e encryption is that
- It make the client more complex.
- Lot of feature are not possible anymore (multicast, caching some
information (like in XEP-0115), automatic server archive, ... )
And i think than having something more complex, which isn't secure in the end,
and which make loss of features is not a good thing.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the Standards