4 ms·

It's great that there is such a strong interest in secure communication, but all of the solutions that keep getting placed in the limelight in recent years are

It's great that there is such a strong interest in secure communication, but all of the solutions that keep getting placed in the limelight in recent years are either centralised or exclusively available for use with a smartphone (because of the phone number requirement), often both! I'm sure that these solutions are a lot more secure than completely unprotected alternatives, but am I wrong in assuming that if you want secure and private communications, the following principles must be met at the least? * The protocol used must be open, standardized and implementable by others * Widely endorsed by cryptography experts * An implementation must be available and developed as free and open source software * End-to-end encryption is used for the contents of the conversations, private keys do not leave the user's computing device * The protocol must not have any technological barriers that prevent an implementation from working on any modern operating system (i.e., a phone number is not required) * The protocol must allow for a complete communications network (clients and servers) to be implemented without the need for centralised third-party services (The last point probably implies federation.) For e-mail, OpenPGP meets these requirements. For chat, XMPP has Off-The-Record messaging. Some of the above points are hostile towards any party that creates secure communications tools with the intent of growing a large user base for economic purposes. Call me a sceptic, but this is probably why use of these protocols and principals is limited to security experts and software developers who understand these principles — for anyone betting on creating the next WhatsApp in one of the mobile walled gardens embracing the whole list means risking losing your potential advertising eyeballs to alternatives. Of course, there is also the matter of infrastructure. A lot of people expect to be able to use these tools for free, but that implies that someone is paying for the hosting of (relay) servers.

DanBC 11y ago
> Call me a sceptic, but this is probably why use of these protocols and principals is limited to security experts and software developers who understand these principals OpenPGP is impossible for most email users to get working correctly. Remember that most people don't even know the difference between CC and BCC. Here's an example of de-anonymising anonymous messages, supossedly from clueful users: https://ritter.vg/blog-deanonymizing_amm.html https://ritter.vg/blog-deanonymizing_amm.html
- Freak_NL 11y ago
  > impossible Difficult perhaps, certainly not impossible, and quite feasible if someone helps you. But I am not suggesting OpenPGP as an alternative for chat-apps for everyone; only for those who understand how to use the technology properly. I mention OpenPGP and XMPP OTR because they are examples of open standards that do fulfil the principles outlined above. That is, to illustrate that it is certainly not impossible or infeasible to create such a technology. What is missing is a technology that does that, and allows anyone (regardless of technological prowess) to use them safely. It is a tough problem though.
  - zanny 11y ago
    From a UX perspective, can we do better? I'll base both off my personal experience - Kmail and KDE Telepathy - since those are my email and IM client. In kmail, to use GPG keys, I need to go to Settings -> Configure -> Identity -> Modify -> Cryptography, change my signing and encryption keys (and it supports PGP or MIME) and then, since I don't already have keys, need to open Kleopatra, the KDE GPG client. Kleopatra uses keys.gpupg.net as its default keyserver, and you can do file -> new certificate to make one. Its a wizard, so you go step by step, setting up a password for the cert along the way. You also make a revoke cert you save somewhere. Once you made the key, you need to export it to the server. And you probably want to make a signing and encryption key, since if you got this far you are already a super techy nerd and that is what makes my point right there. If you want normal people to be able to use gpg in kmail, there needs to be a wizard just like the "add account wizard" called "Setup GPG" that searches for keys that match your email address first in case you already have them and if there are none generates you new ones and just asks you for the password. It handles the propagation and importing of keys itself because thats not something a user should be dealing with unless they need to. And even that is unlikely to happen - you want the GPG setup to really be a part of the first-start of Kmail process. Like the first time you open the program and get the "add account" button you should also get "setup security". But even if you can get people making keys, the UX sucks because it makes them enter a password every time you send an email. You should be able to do what kwallet recently did, and bind the unlock key to your GPG keys to your user session so that when you enter the desktop via SDDM it unlocks your GPG keys just like it unlocks your wallet. Then people can use secure email whenever they want without any bullshit. There are even more UX nightmares - getting your keys across different computers, easily revoking them if they get compromised, even knowing what that means. By comparison OTR in Telepathy is almost usable. In KTP you just hit the "use OTR" button and if your chat partner does the same it automagically generates and shares the keys, no user interaction required. The only downside is that you don't get local logging of your OTR conversations - that should definitely be an option, maybe even encrypt them with your kwallet keys! Eh, eh? But these kind of UX nightmares keep secure communications from being a thing. Mumble is literally the best security solution I have, because I can get a letsencrypt cert, run my own server, put on a password, and anyone chatting on it has perfect security in voice and text - the whole thing is encrypted, I can do my own trust network based off my x509 cert, and it even supports pinned users so nobody can impersonate anyone else. But I say that its the best because for anyone I invite, they literally just need to enter the password I give them to my server. Sure, its problematic to give them the password if you don't have a secure communication link beforehand, but I guess thats what OTR is for! Oh drat...
ex3ndr 11y ago
We will release in next two weeks encrypted end-to-end version of Actor.im that will met this requirements except that is will be reviewed, important part but we will do this in nearest future.
upofadown 11y ago
I think a reasonable compromise would be to just insist on some type of federation with other systems. These days that means XMPP federation. Then the option of OTR for privacy and you are good to go. You can provide all the fancy features you want between your clients, but those clients will also have the feature of being able to communicate with people not using your app/program. Perhaps the combination of federation and OTA can be given an impressive sounding name, a nice logo and a foundation (everything needs a foundation). Then the name/logo can show up on feature lists. People love features...

DanBC 11y ago

> Call me a sceptic, but this is probably why use of these protocols and principals is limited to security experts and software developers who understand these principals OpenPGP is impossible for most email users to get working correctly. Remember that most people don't even know the difference between CC and BCC. Here's an example of de-anonymising anonymous messages, supossedly from clueful users: https://ritter.vg/blog-deanonymizing_amm.html https://ritter.vg/blog-deanonymizing_amm.html

Freak_NL 11y ago
> impossible Difficult perhaps, certainly not impossible, and quite feasible if someone helps you. But I am not suggesting OpenPGP as an alternative for chat-apps for everyone; only for those who understand how to use the technology properly. I mention OpenPGP and XMPP OTR because they are examples of open standards that do fulfil the principles outlined above. That is, to illustrate that it is certainly not impossible or infeasible to create such a technology. What is missing is a technology that does that, and allows anyone (regardless of technological prowess) to use them safely. It is a tough problem though.
- zanny 11y ago
  From a UX perspective, can we do better? I'll base both off my personal experience - Kmail and KDE Telepathy - since those are my email and IM client. In kmail, to use GPG keys, I need to go to Settings -> Configure -> Identity -> Modify -> Cryptography, change my signing and encryption keys (and it supports PGP or MIME) and then, since I don't already have keys, need to open Kleopatra, the KDE GPG client. Kleopatra uses keys.gpupg.net as its default keyserver, and you can do file -> new certificate to make one. Its a wizard, so you go step by step, setting up a password for the cert along the way. You also make a revoke cert you save somewhere. Once you made the key, you need to export it to the server. And you probably want to make a signing and encryption key, since if you got this far you are already a super techy nerd and that is what makes my point right there. If you want normal people to be able to use gpg in kmail, there needs to be a wizard just like the "add account wizard" called "Setup GPG" that searches for keys that match your email address first in case you already have them and if there are none generates you new ones and just asks you for the password. It handles the propagation and importing of keys itself because thats not something a user should be dealing with unless they need to. And even that is unlikely to happen - you want the GPG setup to really be a part of the first-start of Kmail process. Like the first time you open the program and get the "add account" button you should also get "setup security". But even if you can get people making keys, the UX sucks because it makes them enter a password every time you send an email. You should be able to do what kwallet recently did, and bind the unlock key to your GPG keys to your user session so that when you enter the desktop via SDDM it unlocks your GPG keys just like it unlocks your wallet. Then people can use secure email whenever they want without any bullshit. There are even more UX nightmares - getting your keys across different computers, easily revoking them if they get compromised, even knowing what that means. By comparison OTR in Telepathy is almost usable. In KTP you just hit the "use OTR" button and if your chat partner does the same it automagically generates and shares the keys, no user interaction required. The only downside is that you don't get local logging of your OTR conversations - that should definitely be an option, maybe even encrypt them with your kwallet keys! Eh, eh? But these kind of UX nightmares keep secure communications from being a thing. Mumble is literally the best security solution I have, because I can get a letsencrypt cert, run my own server, put on a password, and anyone chatting on it has perfect security in voice and text - the whole thing is encrypted, I can do my own trust network based off my x509 cert, and it even supports pinned users so nobody can impersonate anyone else. But I say that its the best because for anyone I invite, they literally just need to enter the password I give them to my server. Sure, its problematic to give them the password if you don't have a secure communication link beforehand, but I guess thats what OTR is for! Oh drat...

ex3ndr 11y ago

We will release in next two weeks encrypted end-to-end version of Actor.im that will met this requirements except that is will be reviewed, important part but we will do this in nearest future.

upofadown 11y ago

I think a reasonable compromise would be to just insist on some type of federation with other systems. These days that means XMPP federation. Then the option of OTR for privacy and you are good to go. You can provide all the fancy features you want between your clients, but those clients will also have the feature of being able to communicate with people not using your app/program. Perhaps the combination of federation and OTA can be given an impressive sounding name, a nice logo and a foundation (everything needs a foundation). Then the name/logo can show up on feature lists. People love features...