[Security] Gajim 0.12's E2E encryption UI

Dirk Meyer dmeyer at tzi.de
Thu Aug 21 16:32:21 CDT 2008

Peter Saint-Andre wrote:
> Dirk Meyer wrote:
>> Simon Josefsson wrote:
>>> Each client generate an OpenPGP key for the user when she creates an
>>> account.  Instead of verifying a SAS in your example above, the users
>>> needs to verify the OpenPGP fingerprint.  If a SHA-1 hash is too
>>> techno-babbly, a human-readable transformation of the fingerprint could
>>> be used. 
>> Or we use TLS-RSP the first time and use that password to gain the
>> trust. After that I know it is you and I know your OpenPGP key for the
>> next time. This makes it possible to use a password only once and use
>> OpenPGP after that. It could also auto-sign keys with a minimum trust
>> level once I verified you with RSP.
>>> Advanced users can configure the client to use their already
>>> existing OpenPGP key if they want to re-use it for XMPP, which
>>> allows for re-use of the existing web of trust.
>> You could also sign your new key with the old one trusting yourself.
> Would we still need user keys and client keys?

I would prefer these two kinds of keys. If I have bots acting on my
behalf I want to way to remove that trust once they gone bad,
e.g. stolen or hacked. But that may be a special use case for bots...

> One nice thing about OpenPGP is that we could re-use XEP-0027 for the
> offline messaging case:
> http://www.xmpp.org/extensions/xep-0027.html

... for offline messaging we can assume it is the user key we need and
encryt the offline messages with that key.

I have to read some more details about OpenPGP and how to have several
keys for one user. Maybe we use the "global" web of trust for the
user keys and put all signed client keys on a pubsub server so you can
look them up. Maybe we do not want our client keys to be in global
keyrings either. My bank sends me encrypted mails on changes on my
acount. For that reason my PGP key has a long password. I may care
less about XMPP. I would hate to type in a password every time. And my
bots sure need a key without password.

But maybe the c2c user talk is completly different from c2c remote
control. In my use case X.509 certificates and TLS-RSK seems to be
exactly what I need, but I need a least sign all my client keys
somehow (setting up a private CA is very complicated or can someone
send me script doing that WITHOUT user interaction?). I agree that
OpenPGP sounds better when creating a web of trust.

I have some ideas how to fit that all into a userfriendly flow. I can
write a XEP proposal about what happens on starttls tomorrow. But
before I do that I have one question: can I add additional tags inside
<starttls> and the <proceed>? Or is it a violation of the core? The
tags would be completly optional so they won't break clients not
supporting them.

Dirk, going to bed now

Work is the greatest thing in the world, so save some for tomorrow.

More information about the Security mailing list