4 ms·

I'm a Silent Circle employee, but I'm not speaking in any official capacity... The issue with email is that we _had_ to touch plaintext at times. People expect

I'm a Silent Circle employee, but I'm not speaking in any official capacity... The issue with email is that we _had_ to touch plaintext at times. People expect email to work universally, so we had to accept unencrypted mail from outside clients, which we then encrypted for our users. That is a major departure from our other services. It's something we disclosed quite clearly, but we've decided that even with the disclosure, it's simply not worth the risk. We don't even like the idea of storing ciphertext (and obviously, running a mail server means you end up storing a fair amount if it). You can't be compelled to give up what you don't have. This isn't a 'retreat.' Silent Mail was used by a relatively small percentage of our users. Silent Phone and Silent Text are services that we can provide 'responsibly' (in that we don't ever see plaintext, and hold ciphertext in extremely limited situations). They are our core services, and provide our users with the some of tools necessary to communicate securely and privately. We aren't giving up the fight by any means. EDIT: llamataboot summed things up very nicely in another comment thread. https://news.ycombinator.com/item?id=6183394 https://news.ycombinator.com/item?id=6183394

zurn 13y ago
This sounds sensible. However isn't the same problem present with "out-circle access" in voice calls? "Silent Phone subscribers can place and receive calls 'outside the circle' from wherever they are in the world, to or from conventional phone numbers*" -https://silentcircle.com/web/out-circle-access/ https://silentcircle.com/web/out-circle-access/
- JshWright 13y ago
  There are a few key differences though... OCA is a little more 'obvious' in its shortcomings. We still disclose this as clearly and responsibly as we can, but to the average, non-technical user, it seems intuitive that calling a phone that is "outside the circle" is less secure. Our choice for the brand name "Out-Circle" was very intentional. The key difference though is in the data that we have to hold on to. With email, we had to hold on to all sorts of metadata in the email headers (no matter how it's stored, we would obviously have to be able to read it, in order to provide 'email' service). OCA has no such issue. We don't have to log any metadata. Obviously you need to assume that information is being logged _somewhere_ (again, the 'outside' part), but we're not ending up with anything that we could be compelled to hand over. OCA is designed for a different threat model. If you're concerned about the NSA (or the USG (or more broadly the 5 Eyes) in general), then OCA isn't for you. By and large, OCA is for people that need to get their communication securely out of some 'hostile' environment, and aren't especially concerned about western governments (e.g. someone living under an oppressive regime who wants to talk to their ex-pat family in Canada, or a US business man traveling in a country known for stealing trade secrets who needs to talk to his home office about product designs).
  - zurn 13y ago
    Ok, sounds like you have considered this carefully. Best of luck to our crypto heroes!
    - JshWright 13y ago
      Which isn't to say there isn't always room for improvement... Your comment got me thinking about ways we could do a better job pointing out the limitations of OCA, and had an interesting idea for a simple way to remind folks. So thanks for making us think about it again.
mtgx 13y ago
Can't you offer PGP-only e-mails, and just tie everyone's public key to their "profile" on the service? Then, even if they don't specifically have that person's public key, they can still send them e-mails through PGP as long as that other person also has a Silent Circle e-mail account (because you already have that person's public key, so you can connect the two). And of course you should not offer e-mail outside of Silent Circle in any way. I actually can't believe you did that. Silent Circle was supposed to be all about security, not "convenience". If some customers didn't like that, then they shouldn't use it. Now look at the mess you created because you thought it's good to have the convenience of sending anyone an e-mail. You shouldn't have offered that to begin with. So see if you can come back with a PGP-only e-mail in a way that you couldn't add some kind of spyware to get people's private keys if NSA asked you to do it. It might also be a good idea to offer the maximum encryption level (RSA 4096 bit?) if you can afford it (or ask them more money for it), since PGP is more vulnerable to cracking than say OTR, especially if they target some of your customers. And use forward secrecy for the TLS channel. Is there any way you could use the Bitmessage protocol? Or whatever Retroshare is using for e-mails?
- StavrosK 13y ago
  The offering was PGP-only email. The server encrypts the message when it's sent so the user doesn't have to install PGP. That's why plaintext was visible.
  - deleted 13y ago
    [deleted]
monkeynotes 13y ago
> You can't be compelled to give up what you don't have. You are a man in the middle though, could you not be compelled to funnel data in transit to govt. agencies? I mean, if the argument is that you don't want to be in a situation where you are asked to compromise privacy surely you have to remove yourself from the data handling all together.
- StavrosK 13y ago
  That's still just ciphertext. The Silent Phone session negotiation is P2P (unless I'm mistaken), so there isn't even ciphertext passing through there. Silent Text uses something like OTR, so there's still only ciphertext.
  - albeertoni 13y ago
    Session negotiation in silent phone is P2P, it's a ZRTP session with keys negotiated by DH exchange.
    - StavrosK 13y ago
      That's what I thought, thanks.
mike-cardwell 13y ago
It would be nice if there was an extension to SMTP which allowed the receiving server to inform the sending server of the recipients public key, so that the message could be encrypted at the sending servers end before being passed on. That way, the receiving server wouldn't see the plain text. Silent Circle had a feature where people could upload their public keys to their keyserver and then Silent Circle would encrypt any outgoing email to that person with their key if it wasn't already encrypted. Something like that, but more automated. As for meta-data, when I looked at Silent Circles services, they were adding Received headers to email which contain the senders IP address. I know that's common, but it's certainly not required. Even Google don't do that with GMail. There was definitely plenty of room for improvement. How about a mail service which packs the entire message including headers into the MIME body of a new message before enrypting. So the original message headers are all secured too. It wouldn't look as nice in the receivers mail client, but it would be much more secure.

zurn 13y ago

This sounds sensible. However isn't the same problem present with "out-circle access" in voice calls? "Silent Phone subscribers can place and receive calls 'outside the circle' from wherever they are in the world, to or from conventional phone numbers*" -https://silentcircle.com/web/out-circle-access/ https://silentcircle.com/web/out-circle-access/

JshWright 13y ago
There are a few key differences though... OCA is a little more 'obvious' in its shortcomings. We still disclose this as clearly and responsibly as we can, but to the average, non-technical user, it seems intuitive that calling a phone that is "outside the circle" is less secure. Our choice for the brand name "Out-Circle" was very intentional. The key difference though is in the data that we have to hold on to. With email, we had to hold on to all sorts of metadata in the email headers (no matter how it's stored, we would obviously have to be able to read it, in order to provide 'email' service). OCA has no such issue. We don't have to log any metadata. Obviously you need to assume that information is being logged _somewhere_ (again, the 'outside' part), but we're not ending up with anything that we could be compelled to hand over. OCA is designed for a different threat model. If you're concerned about the NSA (or the USG (or more broadly the 5 Eyes) in general), then OCA isn't for you. By and large, OCA is for people that need to get their communication securely out of some 'hostile' environment, and aren't especially concerned about western governments (e.g. someone living under an oppressive regime who wants to talk to their ex-pat family in Canada, or a US business man traveling in a country known for stealing trade secrets who needs to talk to his home office about product designs).
- zurn 13y ago
  Ok, sounds like you have considered this carefully. Best of luck to our crypto heroes!
  - JshWright 13y ago
    Which isn't to say there isn't always room for improvement... Your comment got me thinking about ways we could do a better job pointing out the limitations of OCA, and had an interesting idea for a simple way to remind folks. So thanks for making us think about it again.

mtgx 13y ago

Can't you offer PGP-only e-mails, and just tie everyone's public key to their "profile" on the service? Then, even if they don't specifically have that person's public key, they can still send them e-mails through PGP as long as that other person also has a Silent Circle e-mail account (because you already have that person's public key, so you can connect the two). And of course you should not offer e-mail outside of Silent Circle in any way. I actually can't believe you did that. Silent Circle was supposed to be all about security, not "convenience". If some customers didn't like that, then they shouldn't use it. Now look at the mess you created because you thought it's good to have the convenience of sending anyone an e-mail. You shouldn't have offered that to begin with. So see if you can come back with a PGP-only e-mail in a way that you couldn't add some kind of spyware to get people's private keys if NSA asked you to do it. It might also be a good idea to offer the maximum encryption level (RSA 4096 bit?) if you can afford it (or ask them more money for it), since PGP is more vulnerable to cracking than say OTR, especially if they target some of your customers. And use forward secrecy for the TLS channel. Is there any way you could use the Bitmessage protocol? Or whatever Retroshare is using for e-mails?

StavrosK 13y ago
The offering was PGP-only email. The server encrypts the message when it's sent so the user doesn't have to install PGP. That's why plaintext was visible.
- deleted 13y ago
  [deleted]

monkeynotes 13y ago

> You can't be compelled to give up what you don't have. You are a man in the middle though, could you not be compelled to funnel data in transit to govt. agencies? I mean, if the argument is that you don't want to be in a situation where you are asked to compromise privacy surely you have to remove yourself from the data handling all together.

StavrosK 13y ago
That's still just ciphertext. The Silent Phone session negotiation is P2P (unless I'm mistaken), so there isn't even ciphertext passing through there. Silent Text uses something like OTR, so there's still only ciphertext.
- albeertoni 13y ago
  Session negotiation in silent phone is P2P, it's a ZRTP session with keys negotiated by DH exchange.
  - StavrosK 13y ago
    That's what I thought, thanks.

mike-cardwell 13y ago

It would be nice if there was an extension to SMTP which allowed the receiving server to inform the sending server of the recipients public key, so that the message could be encrypted at the sending servers end before being passed on. That way, the receiving server wouldn't see the plain text. Silent Circle had a feature where people could upload their public keys to their keyserver and then Silent Circle would encrypt any outgoing email to that person with their key if it wasn't already encrypted. Something like that, but more automated. As for meta-data, when I looked at Silent Circles services, they were adding Received headers to email which contain the senders IP address. I know that's common, but it's certainly not required. Even Google don't do that with GMail. There was definitely plenty of room for improvement. How about a mail service which packs the entire message including headers into the MIME body of a new message before enrypting. So the original message headers are all secured too. It wouldn't look as nice in the receivers mail client, but it would be much more secure.