Multiple devices support sharing same key material

[daniele-athome]

From [email protected] on February 26, 2014 07:40:16

Due to the very simple encryption version 2.9.x had it was possible to send and receive messages from the same encrypted chat with multiple devices if all were registered for the same number. It was a very unique feature along all secured messangers. I hope you plan to continue on this.

Currently I'm usung 3.0 alpha3 and have seen the option to export keys to flash. Is there already a way to import them to a different device?

Original issue: http://code.google.com/p/kontalk/issues/detail?id=193

• replace "Import existing keys button" with "I already have another registered device" and open up a wizard to import the new keys
• replace "verification code" with "verification PIN" (?)

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[daniele-athome]

From [email protected] on February 27, 2014 01:23:34

We plan to continue on this feature of course. But it will be a little less straightforward for the user because of the personal key.
Importing keys will be available in a future alpha release and in a future version we want to implement something like bluetooth or NFC key exchange. I'll use this ticket to track changes about this.

Summary: Multiple devices support sharing same key material (was: Multiple devices support with XMPP sharing same key material)
Status: Accepted
Labels: -Priority-Low Priority-Medium Milestone-3.0 Component-XMPP-Android

[daniele-athome]

First step: export/import of the personal key into a zip file.

[daniele-athome]

Import/export via archive file is now implemented and working (roughly) on master. But we need an easier way to exchange them between devices.

[h-2]

I have tried exporting the key to a zip file, manually copying it to my tablet and importing it there, but it says that import failed. Is this still a work in progress, or can I help with logs or something like that?

[daniele-athome]

I'm sorry, key importing has been broken since beta5. I've fixed it a couple of days ago, it will be live with beta7 as soon as I fix a couple of other things.

[daniele-athome]

Related to kontalk/desktopclient-java#51.

[TheLastProject]

Just randomly reading through issues and want to leave a note that this issue will probably no longer be relevant when OMEMO support is implemented (see #132) as OMEMO can do multi-device with different keys, which has the added benefit of being able to un-trust a device.

[daniele-athome]

@TheLastProject for encryption purposes yes, but remember that authentication is done through the same key. And doing this also for authentication might be a bit more complicated.

[CrimsonFork]

I think that an interesting feature would be an option where two android devices are using their front cameras and screen to communicate via QR codes. This is helpful in that way that there's actually no way to read the communication without getting close enough to be noticed by the user.

I know that it can seem redundant at the first thought, but if there's a vulnerability in the encryption and no security update is ready, it's not very hard to read a bluetooth connection as far as I know. I don't know much about this area, so I am may wrong. Please correct me if.

[daniele-athome]

I know that it can seem redundant at the first thought, but if there's a vulnerability in the encryption and no security update is ready

I have to disagree on this concept. A security concern can arise from many attack vectors. We can't immediately give equal priority to all of them. I believe this is a security enhancement, but not a vulnerability: there are other ways to securely transmit your fingerprint in a safe manner.

[CrimsonFork]

Well, if you say that, I can't do anything but agree.

[daniele-athome]

I'm sorry I didn't mean to sound rude. It's just that priority on features is very subjective, and being practically only one doing all the work, I have to make the app appeal also to non-tech users. So, minimal-safe security first (I believe I did a fine job about that), the rest will come later, that's all :-)

[CrimsonFork]

It didn't seem rude for me. I just wanted to say that I have no coding skills or knowledge how communication protocols work (yet) and if you say that this isn't important for now, I trust you. It's your app anyway and it's yours to decide what to do with it.

But now I have a question, if your point is "minimal-safe security first" (I think either you did a good job si far) why didn't you implement Signal's group chat functionality first and only then worked on that complex system you just released?

[abika]

But now I have a question, if your point is "minimal-safe security first" (I think either you did a good job si far) why didn't you implement Signal's group chat functionality first and only then worked on that complex system you just released?

Hehe, PGP is far simpler than the Signal (aka Axolotl aka TextSecure) protocol. If you want you can read https://eprint.iacr.org/2014/904.pdf and explain it to me afterwards. Cause I don't fully understand it yet (or maybe I'm a bit stupid).

[CrimsonFork]

Sure! Why not? How about in... 2-3 years? Just kidding I'll try to find the time to read it.

[CrimsonFork]

Wait, didn't you mention that PGP is also better encrypted somewhere? If it's true, it doesen't seem ti have any logic from the side of the Signal guys.

[abika]

Wait, didn't you mention that PGP is also better encrypted somewhere?

Eh no. PGP has other advantages but from the security perspective Signals protocol is better (It supports perfect forward secrecy, https://en.wikipedia.org/wiki/Forward_secrecy)

[CrimsonFork]

Good thing to know, so you are planning to swich to better encryption later, I guess?

[abika]

Yes, see #132

[CrimsonFork]

Thanks.

[daniele-athome]

Closed by #1090.