4 ms·

They point out that existing email leaks a lot of metadata, but I do not see any proposal to fix that in the new protocol. How would you hide/encrypt/otherwise

They point out that existing email leaks a lot of metadata, but I do not see any proposal to fix that in the new protocol. How would you hide/encrypt/otherwise protect the list of recipients? Someone somewhere has to know where to deliver the message, especially if you will continue to use human readable/memorable email addresses as we currently know them today. You could have the server know the addresses to forward the message and then forget them. However, then the server knows this information at some point and it could be sniffed/recorded along the way. Does anyone know any more details about the specifics of the protocol? How would you minimize metadata leakage if you were implementing such a protocol? I am not sure it is possible to guarantee the recipient list won't be leaked.

conroy 13y ago
I've read over the SCIMP protocol. From their white paper, a sample message looks like this: <message type="chat"from='velma@silentcircle.com' to='daphne@silentcircle.com' id="0FF6CF98-32FE-4EED-9DEF-D66A0E50EA8F"><body/><x xmlns="http:// silentcircle.com">? SCIMP:ewogICAgImRhdGEiOiB7CiAgICAgICAgInNlcSI6IDE1MDcyLAogICAgICAgICJtYWMiOiAiZlp YYURlQ1ljVTA9IiwKICAgICAgICAibXNnIjogIkloT051Sm9kK0Fjb09KQ1prZ0xHQXliSmJjbC9WNzhl cmMrSFY4K1FHcUJ2cEdlb2RaSWZwNTRKVWluU2g0N0lZTjFORkJOaXBjTVdubWlsMXVtbi9pcG5rVk8rd VJZdUJuQjdpZXZEK1pZQzBYV0hHQWQ3WWJtOWRsYkpSd0oyIgogICAgfQp9Cg==.</x></message> which worries me. Yes, the connection between the server and client will be encrypted, but my message still has metadata that isn't encrypted. I'd just like an answer from Silent Circle / Lavabit.
- xanth 13y ago
  why dont they address the server and encrypt the user address at the server level, so a network eavesdropper would only see traffic too and from servers but not the particular addresses being addressed. The user puts in an address e.g. yaName@yaDomain.com the sender and receiver address (maName & yaName) are then stripped on sending the D-mail and encrypted with the D-mail servers private key the receiving server (maDomain) then goes through the public private key exchange with the sender (yaDomain) thus securely passing the user address between the two servers without the eavesdropper knowing from what user the D-mail originated and to what user the D-mail was addressed to. This system would become more secure the the greater the number of users on each domain. To add extra security batch sending by the server would make it even more secure e.g. every 3min || when unsent messages to domain x > 999 --> send D-mails. this would add latency and create bandwidth spikes but would negate time based inference attacks. edit: relevant xkcd; http://xkcd.com/927/ http://xkcd.com/927/
- hershel 13y ago
  I believe that the SCIMP whitepaper is from 2012. They haven't released their current protocol , and they said they don't want to talk too much about it because there could be changes.
hershel 13y ago
>> guarantee the recipient list won't be leaked. Basically , if you A. Put a chain of servers between the sender and the recipient, each with a unique encryption key(which lets you reveal unique info for each server privately) B. Make sure to hide traffic patterns: don't let your enemy know when sender is sending a message or when recipient is receiving a message. This can be done by creating false traffic at fixed times to hide true traffic. you can design protocols that make sure that: 1. The first server in the chain only knows the sender. 2. The last server on the chain only the recipient. 3. Assuming you enemy hasn't cracked all the chain, he can't link sender and recipient I don't know alot about the XMPP protocol(whichthey are using) , so i'm not sure how it fits all this though.

conroy 13y ago

I've read over the SCIMP protocol. From their white paper, a sample message looks like this: <message type="chat"from='velma@silentcircle.com' to='daphne@silentcircle.com' id="0FF6CF98-32FE-4EED-9DEF-D66A0E50EA8F"><body/><x xmlns="http:// silentcircle.com">? SCIMP:ewogICAgImRhdGEiOiB7CiAgICAgICAgInNlcSI6IDE1MDcyLAogICAgICAgICJtYWMiOiAiZlp YYURlQ1ljVTA9IiwKICAgICAgICAibXNnIjogIkloT051Sm9kK0Fjb09KQ1prZ0xHQXliSmJjbC9WNzhl cmMrSFY4K1FHcUJ2cEdlb2RaSWZwNTRKVWluU2g0N0lZTjFORkJOaXBjTVdubWlsMXVtbi9pcG5rVk8rd VJZdUJuQjdpZXZEK1pZQzBYV0hHQWQ3WWJtOWRsYkpSd0oyIgogICAgfQp9Cg==.</x></message> which worries me. Yes, the connection between the server and client will be encrypted, but my message still has metadata that isn't encrypted. I'd just like an answer from Silent Circle / Lavabit.

xanth 13y ago
why dont they address the server and encrypt the user address at the server level, so a network eavesdropper would only see traffic too and from servers but not the particular addresses being addressed. The user puts in an address e.g. yaName@yaDomain.com the sender and receiver address (maName & yaName) are then stripped on sending the D-mail and encrypted with the D-mail servers private key the receiving server (maDomain) then goes through the public private key exchange with the sender (yaDomain) thus securely passing the user address between the two servers without the eavesdropper knowing from what user the D-mail originated and to what user the D-mail was addressed to. This system would become more secure the the greater the number of users on each domain. To add extra security batch sending by the server would make it even more secure e.g. every 3min || when unsent messages to domain x > 999 --> send D-mails. this would add latency and create bandwidth spikes but would negate time based inference attacks. edit: relevant xkcd; http://xkcd.com/927/ http://xkcd.com/927/
hershel 13y ago
I believe that the SCIMP whitepaper is from 2012. They haven't released their current protocol , and they said they don't want to talk too much about it because there could be changes.

hershel 13y ago

>> guarantee the recipient list won't be leaked. Basically , if you A. Put a chain of servers between the sender and the recipient, each with a unique encryption key(which lets you reveal unique info for each server privately) B. Make sure to hide traffic patterns: don't let your enemy know when sender is sending a message or when recipient is receiving a message. This can be done by creating false traffic at fixed times to hide true traffic. you can design protocols that make sure that: 1. The first server in the chain only knows the sender. 2. The last server on the chain only the recipient. 3. Assuming you enemy hasn't cracked all the chain, he can't link sender and recipient I don't know alot about the XMPP protocol(whichthey are using) , so i'm not sure how it fits all this though.