
The Security, Usability and Multi-Device-Problem of Messaging Apps - tazjin
https://www.tazj.in/en/1450354078
======
moxie
Wait, have you actually used Signal multi-device? Your thesis is that it's not
usable because you have to scan a QR code once, as opposed to Telegram where
you have to receive an SMS on your device and manually type it in on your
desktop?

The flow you're describing in your "possible solution" is basically identical
to how Signal works now: you install Signal on a new device, approve it with
your existing device, and are done. Anything involving the word "blockchain"
here is fundamentally not going to work. It sounds like you want CONIKS, but
there are some really substantial barriers to deploying that for marginal
gains (and some clear losses).

~~~
lorenzhs
Given that the OP didn't know about Signal-Desktop 4 hours ago when I told
them (see
[https://news.ycombinator.com/item?id=10750637](https://news.ycombinator.com/item?id=10750637)
) and was bashing Signal then for not supporting it, I'd say tajzin has at
most had a cursory look at it. I'm not sure how or why they feel qualified to
blog about it.

I've been using Signal-Desktop since the first days of the Beta and so far
it's been a really pleasant experience. Big thank you to all involved!

~~~
exo762
Signal having all three qualities author is blogging about: security, multi-
device cync, and usability basically makes this post and SMU theory nil. This
looks like a case of "I have my theory, now lets bend facts to fit the
theory".

~~~
newman314
I'd argue that usability in Signal isn't that great for other reasons,
particularly around the contact list.

I responded in another thread about this. [1]

[1]
[https://news.ycombinator.com/item?id=10753881](https://news.ycombinator.com/item?id=10753881)

------
therealmarv
Missing an important part here: Telegram and co. is a cloud storage service
where as WhatsApp, Signal, Threema are not. Think about this... your messages
are stored and not delivered and deleted on the server. Telegram has the
encryption and decryption keys but claims there are in different
countries/jurisdication. So is this safer than deliver+delete? I think NO.

I wished somebody would analyze if WhatsApp protocol is using encryption also
on iOS, groups and images as this website claims:
[https://github.com/WHAnonymous/Chat-API/wiki/WhatsApp-
incomi...](https://github.com/WHAnonymous/Chat-API/wiki/WhatsApp-incoming-
updates#9-september-2015)

------
sarciszewski
After reading this post, I'm just sitting here smiling contently that you
didn't give Telegram credit for "Secure".

(I've been loudly trying to convince more people to never use Telegram.)

------
itamarwe
Do you really need a blockchain? A certificate chain from the root certificate
of the primary device to any secondary device should be enough.

~~~
tazjin
The point is to not have a primary device, every device added to the pool
should be able to sign in new devices.

~~~
zeveb
I still don't think that a blockchain is really the answer though. It's _an_
answer to Zooko's Triangle, but it also removes an element of privacy.

Do we _need_ global names? I just want to talk to my brother, my friend, my
colleague; I don't really care about talking to people I don't know. Given
that, what's wrong with identifying people as 'Billy's wife's mother'?

~~~
tazjin
> it also removes an element of privacy

What are you thinking of specifically? The chain wouldn't contain any network
of contacts (like GPG signatures) and only hashed information about the user.

Worst case is that a user's number of devices and public keys can be looked
up.

~~~
zeveb
> The chain wouldn't contain any network of contacts (like GPG signatures) and
> only hashed information about the user.

If 'hashed user information' means a function of the user's identifier (e.g.
the user's email address, or some other global user ID), then privacy is lost
because one could hash any user's ID and see what his public keys are; many
protocols include an identifier for the sender's public key in order to guide
the receiver, and vice-versa. This means that one could see what messages that
user has sent or received.

If it doesn't contain some function of the user's identifier, then what would
be stored exactly, and what would its utility be? If I can't consult the
global blockchain asking, 'what is the key for smith@example.invalid?' then
why have a global blockchain? If it's simply a record where key X says key Y
is the same as key X, then key Y says no it's not, then key X says yes it is
again … what's the value?

Blockchains are an amazing innovation for achieving global agreement. Because
of this, they can be used to bind easy-to-remember petnames (like 'bill' or
'Bill Gates') securely, such that the entire world knows that BLOCKCHAIN('Bill
Gates') is the founder of Microsoft, not his father or some random fellow. If
you're not using a blockchain for global agreement, what's the point?

~~~
tazjin
Yes, it's supposed to be a hash of the user's identifier.

The goal is of course being able to look up the keys of individual users based
on their publicly shared identifier. This system isn't trying to hide a user's
keys in any way, so I think we're simply trying to solve different things

~~~
zeveb
> Yes, it's supposed to be a hash of the user's identifier.

Which is why it's a privacy issue: given someone's public identifier, I can
see what his key is and how it changes over time. I can see _if_ he has a key,
which is interesting information. As I noted, I can probably monitor traffic
to find messages encrypted by or to his key.

Heck, I can pregenerate many potentially-valid identifiers (e.g.
[0-9az]+@[a-z][0-9az]+\\.(com|net|org|edu) and look for them in the public
blockchain, and use that to confirm whether the accounts are valid or not
(this could be used to see if an email address is valid without ever sending
email to it). I could use this to verify addresses before sending out spam or
malware.

If I _can_ see two identifiers who communicate with one another, I could use
this to, say, malware purportedly from one to the other via unsigned email,
who is likely to trust it because it appears to be from someone he knows.

You see the issues, I hope. This kind of thing really is tough.

------
ge0rg
_Alice sends a message to Bob, her device asks the messaging service for Bob
's account's identify and public keys._

This is a classic trusted third party problem. We need to trust the service
that the public key provided (and stored in the blockchain) actually belongs
to Bob.

This boils down to Zooko's triangle: if the service allows to associate the
account with a new key, there is no way to prove the new key actually belongs
to Bob. If there is no such way, Alice will have to somehow figure out the
undecipherable new ID of Bob.

The only benefit I can see of backing the keys in a blockchain is that your
own client can monitor the blockchain for new keys associated with your
account, ringing alarm bells in such a case.

~~~
tazjin
It depends on what you are establishing trust to, Bob's account, Bob's first
key or Bob as a person? The service could write a hash of Bob's account name /
phone number / whatever and the account's identity to the chain. That way it
cannot easily respond with a different set of keys for the same account.

One attack vector I can think of in terms of a malicious third-party is that
they could take your initial account creation request and key, create their
own key and use that as the initial one of your account in the chain.

In this model you have the ability to find out about that though.

------
HappyTypist
There is one incredibly simple solution to solve the 'multi-device-problem'
with security:

1\. Allow the user to copy their keys to another device themselves.

To further improve security, you'd want a transfer mechanism that cannot be
copied as text / emailed / IM'd / whatever just so the user is discouraged
from sending it in their gmail. One suitable candidate is QR codes, but
without a camera "Type 1 letter at a time" would also work.

~~~
zeveb
You never want to share keys if you can get away with it.

Your suggestion also doesn't solve the problem of lost, compromised or
destroyed devices.

If I have one phone and one computer, no algorithmic solution can determine if
the person holding my phone is me, and the person holding my laptop is a
thief, or if the person holding my phone is a thief and the person holding my
laptop is me.

Honestly, even majority vote is insufficient: is there any reason to trust the
person holding my phone and laptop over the person holding my computer? What
if my home just burned down?

What's needed is for each device to have its own keys, and for messages to
'you' to really be sent to each device. And when you lose a device, you have
to let your friends know, and they have to manually verify which of your
devices to no longer trust. This can be presented in a pleasing fashion, but
you can't eliminate the need for human judgement.

------
aluhut
Am I the only one who does not see the dot before the TLD here?

~~~
tazjin
Hey, I'm afraid I don't understand your comment. Can you explain?

~~~
aluhut
This is what a link source looks like usually for me:

[http://i.imgur.com/udKe02n.png](http://i.imgur.com/udKe02n.png)

This is what this one looks like:

[http://i.imgur.com/1JC34Dv.png](http://i.imgur.com/1JC34Dv.png)

