Core Apps » ChatSecure:Android

There is a more general issue - the current keystore format supports only one key per XMPP address (x@y.com). Consider switching to the Pidgin format.

devrandom wrote:

There is a more general issue - the current keystore format supports only one key per XMPP address (x@y.com). Consider switching to the Pidgin format.

wouldn't using the full address x@y.com/z where z is the resource, solve this problem?

The problem is not the XMPP Resource so much as its not storing multiple public keys for a single XMPP ID. Adding the Resource only partially helps there. I think a much better solution would be to make Gibberbot use and store multiple public keys for a given XMPP ID and entirely ignore the Resource when it comes to OTR keys. This is basically what libotr does. And libotr does not use the Resource when checking whether a account/fingerprint are in the local fingerprint store.

The Gibberbot process for matching the current remote ID with the stored fingerprints should check against all stored matches, and not just assume there is one. Gibberbot should also be able to write out multiple fingerprints/public keys for a given account ID.

The way that Pidgin uses the Resource in the unique ID in OTR key store makes it much harder to manage when doing key syncing, and provides no benefit that I can see. When syncing public key info from other apps, OTRFileConverter has to lookup the Resource info from the Pidgin config files.

Adding the Resource to the Gibberbot format will entirely break the syncing of trusted public keys because OTRFileConverter currently has no way to query Gibberbot to see which Resource it should use for a given account.

To clarify, there are two things that are not changing. The local pubkey/privkey pair is still stored with the bare JID (uppercase strings are generic placeholders below):

X@Y.pubkey=...
X@Y.privkey=...

Also, the verification status is stored keyed on the fingerprint:

X@Y.FINGERPRINT.verified=true

What is changing is the storage of remote pubkeys and unverified fingerprints (/RES was added):

X@Y/RES.pubkey=...
X@Y/RES.fingerprint=...

However, these two items do not need to be synced - they are just used internally in GB.

The Gibberbot process for matching the current remote ID with the stored
fingerprints should check against all stored matches, and not just assume
there is one. Gibberbot should also be able to write out multiple
fingerprints/public keys for a given account ID.

I think this is already the case. As discussed on IRC, the only thing that's inconvenient is that it's hard to get from the existing format whether a fingerprint has been seen, if it hasn't been verified.

So I'm going to add:

X@Y.FINGERPRINT.verified=false

for all unverified but seen fingerprints.