Introducing asymmetric encryption has a cost. Because of the decentralized nature of asymmetric keys (i.e. no passwords database), people have to manage their own keys and take responsability for their actions with those keys. This includes losing your device, for example.
If you lose your device and the key pair is inside, the key pair is said to be compromised: anyone using your device will be able to literally impersonate you and encrypt/sign with your former keys. There are a few actions you could take (or have taken):
- encrypt your keys and ask for a password every time you use Kontalk
- revoke your keys
The first options is brute-force breakable, so it's not so useful really: it just delays the inevitable.
The second option requires you having a backup copy of your key pair (actually a revocation certificate) and some server to be aware of you wanting to revoke your key pair. Since Kontalk has no concept of permanent key pair storage (it's actually just a cache erasable at any time), even if the rightful owner of the compromised key pair sends a revocation certificate to the server, the server would lose it at the first cache purge, and the "other guy" — the one who found your lost device — can restore it.
To overcome this problem, Kontalk will use this implementation logic: clients can't update their own key pair to the server unless it's the same key (e.g. just a signatures update) or the client has a valid revocation certificate for the key they are about to overwrite. This way, even if there is a cache purge on the server, your new device will be able to overwrite the impostor's key pair.
Of course there is a chance that the impostor succeeds to send a few messages in the meantime: to protect against such cases, the client software will warn users about the inconsistency of the signature on the message.