6 ms·

Session Protocol: Technical implementation details

ggm 6y ago
If you studied networking in computer science, "the session protocol" means something between the presentation and transport layers in the iso 7 layer model.
- arghwhat 6y ago
  Anything above level 3 in the osi model is pretty useless distinction, and even the useful levels the distinction is just a bogus description of the status quo, rather than something truly useful.
- wmf 6y ago
  Unfortunately, common nouns being reused as product names is a lost cause at this point.
  - loup-vaillant 6y ago
    (Shameless Plug™) Do not despair just yet: https://github.com/LoupVaillant/Monokex/ https://github.com/LoupVaillant/Monokex/
driminicus 6y ago
Yet another closed source, centralized ostensibly private chat client? If it actually gets a decent user base it should probably be bridged, but otherwise I don't really care.
- 5evOX5hTZ9mYa9E 6y ago
  Exact opposite, based on Monero and Signal code, decentralised by relying on service nodes that anyone can run, implementing it's own onion routing. Honestly, on paper, it looks pretty good. The core problem is that devs are Australians and can be secretly compelled to backdoor their app via Assistance and Access Act.
  - privacylol 6y ago
    HushChat protocol is superior to Session in every way, which relies on centralized servers, Javascript frameworks, and a small set of "masternode" servers to pass your encrypted chats, which is easily Eclipse Attacked. https://git.hush.is/hush/hushchat https://git.hush.is/hush/hushchat Cryptocoins which are based on Monero have no protocol-level encrypted data, HUSH is based on an improved version of Zcash Protocol, which does. HushChat does have some forms of "plausible deniability", such as: It is impossible to tell how many people you are communicating with, it could be anywhere between 0 and 8 people and look like a normal network transaction. Also, every normal network transaction looks like a HushChat, there is no way to tell which transactions are chats and which are not. They all look the same at the protocol level. HushChat is a feature inside SilentDragonLite: https://git.hush.is/hush/silentdragonlite https://git.hush.is/hush/silentdragonlite Yes, you must pay for your privacy when using HUSH. If you are not paying for your privacy, you are the product, and don't have any. 1 HUSH = 10000 encrypted messages, on average.
dunefox 6y ago
Sometime last year I tried Session and while the idea sounds great it needs a lot more attention before I can use it in anger - but I'm a fan of the idea.
upofadown 6y ago
The news here is that Session is dumping Signal Protocol in favour of something simpler. So not so much forward secrecy and denyability. They do not think such features are worth the cost in complexity.
- johnchristopher 6y ago
  Is it simpler ? I only posted because there were a lot of talks about Signal on the front page and I remember Session using Signal's UI and protocol without the phone number (+tor backbones). They say the signal protocol is hard to shoehorn into a decentralized structure, hence the change.
loup-vaillant 6y ago
> In practice, cryptographic deniability is often disregarded when it comes to court cases or media reporting. That's because implementers fail to follow through. The signal protocol enables deniability, but the signal application does not. For a communication app to deliver actual deniability it needs at least to provide the ability to add, remove, and edit messages locally, with timestamps and everything. That edit feature must be easy to use, and easy to find. Ideally, it would be advertised when you first use the app. It must be crystal clear to any judge that screenshots from this app is no better than "he said, she said". For offline protocols where messages stay online for a long period of time (file encryption, and Signal to a lesser extent), we should also have an easy way to forge messages to oneself. With protocols from the Noise framework, this is easy to implement. From a user's perspective, we just need a "forge false message to self" button, where you specify the "fake sender". Only then can encrypted files be reduced to a "he said, she said" situation. Cryptographic deniability is not enough. We need plausible deniability, and that can only be achieved when (i) forgeries are easy, and (ii) everybody knows it.
- upofadown 6y ago
  In the first case you would have to explicitly accuse your correspondent of forging a message from you for this to work. Most people would not be willing to do that to the people they chat with on IM. You would be using an excuse specifically created by the system for the purpose of saying something and then falsely denying that you had sad it. Who would believe that is not exactly what had happened? If someone actually did forge a message from you then few would believe that actually happened. Quoting myself here: forgeability uses a simple technical approach to create a much more complicated question of credibility.[1] [1] https://articles.59.ca/doku.php?id=pgpfan:repudiability https://articles.59.ca/doku.php?id=pgpfan:repudiability
  - loup-vaillant 6y ago
    Obviously, if Alice is writing to Bob, repudiability is weakened in two ways: 1. She can't convince Bob she didn't write the message: it's written right there on Bob's phone, and he'd remember if he'd tamper with it. 2. If Bob starts showing Alice's message around, she can't pretend he misremembered, as would be possible with an oral conversation. She'd have to flat out call him a liar. --- > using a system that is deliberately designed to allow you to say something then deny having said it might also cause extra suspicion. Not if everyone used such a system. There's a difference between building & using your own obscure deniable chat application, and WhatsApp and Signal themselves enabling this. > In practice [repudiability] has very little value. It is unlikely that the feature is worth the extra risk of the complexity it would take to implement it. Deniable schemes are not more complex. There's just one simple condition: use Diffie-Hellman key exchanges instead of signatures. The result will likely be simpler than a scheme that relies on signatures. I've implemented both key exchanges and signatures with elliptic curves (X25519 and Ed25519 specifically), and I'm telling you, key exchange is significantly simpler and harder to get wrong. (For the anecdote, I screwed-up once in my cryptographic work, and it was the signatures). See https://noiseprotocol.org https://noiseprotocol.org for fairly simple key exchange based protocols, with various properties one might care about (key compromise impersonation, resistance against replay-attacks, anonymity to third parties…).
permille42 6y ago
From FAQ: Q: Can I backup my messages? A: No. :( The killer feature set of a messaging system that will allow it to crush WhatsApp, Signal, Session, etc: * Fully open source ( app, nodes, everything ) * End-to-end encryption ( obviously ) * Rotating keys for deniability. Basically just create time valid subkeys and periodically post the private key to the subkeys. Probably once a day would be sufficient. * Full message export/import including tweaking and faking messages. It isn't really deniable if you can't show you could easily fake some past messages. * Fully capable Linux client, so that we aren't forced to use an untrusted and possibly backdoored phone to use it. * Extra secure time bucketed send/receive if you want to avoid timing attacks on location. * Hash section bucketed messages along with the bucket by time. For example, if your public key is 4BC56..., you can request all messages sent to 4BC* and get them all, so it isn't then obvious who exactly you are. * Subkey unique per communication partner. This way gaining someones subkey for a time period doesn't let you potentially capture other packets you know are encrypted and decrypt them too... * URL based identity. Post your public key to URL; tada that URL can then be used as your identity. Have a bunch of different secure countries host free identity upload sites. * Group chat which just makes it so you communicate every message to every other partner in the group chat and vice versa. Any other way wouldn't be secure. * Message size padding to private size based packet matching. * Automatic sending of periodic messages to bogus destinations. This way it is not immediately apparent if you are sending something out or not. Preferably this would include adding random people and engaging in nonsense chat sessions with them for random amounts of time. Only the client on the other end would know if it is a bogus message or not. * Message nodes completely wipe all data hourly ( for regular messages ) or daily ( for the daily grouped messages ) * Message nodes all ban any client attempting to download more than a certain threshhold of data. Publish the banned clients publicly. Expose the watchers. * No registration. Basically anyone should be able to send/receive through whichever node they wish that has available bandwidth. You send an encrypted chunk with a destination ID. Others can download chunks tagged with some hash part of the destination. * Central "saturation tracking node" that receives saturation from all registered nodes in the system and just publishes a file on a URL for whoever wants it to figure out which node they will use to communicate that isn't over-saturated. * Can post a set of nodes you listen on to your URL with public key periodically so clients know how to start communication with you. Once established; switch to unsaturated nodes... The following features are somewhat irrelevant: * Onion routing. Just connect to the service through any number of other onion routing systems. No need to put all our eggs in one basket. Use a private VPN + Tor to connect to the system. Done.
rakoo 6y ago
I'm no cryptographer but I can see that messages are signed before they are encrypted, for no obvious reason. That's failing the cryptographic doom principle (https://moxie.org/2011/12/13/the-cryptographic-doom-principle.html https://moxie.org/2011/12/13/the-cryptographic-doom-principl...) and so should be taken with care. OTOH the drop of Signal Protocol features makes sense in their appreciation of real world: as soon as an attacker has full control of the device all the protections fail. This is probably the number one source of working attack anyway

ggm 6y ago

If you studied networking in computer science, "the session protocol" means something between the presentation and transport layers in the iso 7 layer model.

arghwhat 6y ago
Anything above level 3 in the osi model is pretty useless distinction, and even the useful levels the distinction is just a bogus description of the status quo, rather than something truly useful.
wmf 6y ago
Unfortunately, common nouns being reused as product names is a lost cause at this point.
- loup-vaillant 6y ago
  (Shameless Plug™) Do not despair just yet: https://github.com/LoupVaillant/Monokex/ https://github.com/LoupVaillant/Monokex/

driminicus 6y ago

Yet another closed source, centralized ostensibly private chat client? If it actually gets a decent user base it should probably be bridged, but otherwise I don't really care.

5evOX5hTZ9mYa9E 6y ago
Exact opposite, based on Monero and Signal code, decentralised by relying on service nodes that anyone can run, implementing it's own onion routing. Honestly, on paper, it looks pretty good. The core problem is that devs are Australians and can be secretly compelled to backdoor their app via Assistance and Access Act.
- privacylol 6y ago
  HushChat protocol is superior to Session in every way, which relies on centralized servers, Javascript frameworks, and a small set of "masternode" servers to pass your encrypted chats, which is easily Eclipse Attacked. https://git.hush.is/hush/hushchat https://git.hush.is/hush/hushchat Cryptocoins which are based on Monero have no protocol-level encrypted data, HUSH is based on an improved version of Zcash Protocol, which does. HushChat does have some forms of "plausible deniability", such as: It is impossible to tell how many people you are communicating with, it could be anywhere between 0 and 8 people and look like a normal network transaction. Also, every normal network transaction looks like a HushChat, there is no way to tell which transactions are chats and which are not. They all look the same at the protocol level. HushChat is a feature inside SilentDragonLite: https://git.hush.is/hush/silentdragonlite https://git.hush.is/hush/silentdragonlite Yes, you must pay for your privacy when using HUSH. If you are not paying for your privacy, you are the product, and don't have any. 1 HUSH = 10000 encrypted messages, on average.

dunefox 6y ago

Sometime last year I tried Session and while the idea sounds great it needs a lot more attention before I can use it in anger - but I'm a fan of the idea.

upofadown 6y ago

The news here is that Session is dumping Signal Protocol in favour of something simpler. So not so much forward secrecy and denyability. They do not think such features are worth the cost in complexity.

johnchristopher 6y ago
Is it simpler ? I only posted because there were a lot of talks about Signal on the front page and I remember Session using Signal's UI and protocol without the phone number (+tor backbones). They say the signal protocol is hard to shoehorn into a decentralized structure, hence the change.

loup-vaillant 6y ago

> In practice, cryptographic deniability is often disregarded when it comes to court cases or media reporting. That's because implementers fail to follow through. The signal protocol enables deniability, but the signal application does not. For a communication app to deliver actual deniability it needs at least to provide the ability to add, remove, and edit messages locally, with timestamps and everything. That edit feature must be easy to use, and easy to find. Ideally, it would be advertised when you first use the app. It must be crystal clear to any judge that screenshots from this app is no better than "he said, she said". For offline protocols where messages stay online for a long period of time (file encryption, and Signal to a lesser extent), we should also have an easy way to forge messages to oneself. With protocols from the Noise framework, this is easy to implement. From a user's perspective, we just need a "forge false message to self" button, where you specify the "fake sender". Only then can encrypted files be reduced to a "he said, she said" situation. Cryptographic deniability is not enough. We need plausible deniability, and that can only be achieved when (i) forgeries are easy, and (ii) everybody knows it.

upofadown 6y ago
In the first case you would have to explicitly accuse your correspondent of forging a message from you for this to work. Most people would not be willing to do that to the people they chat with on IM. You would be using an excuse specifically created by the system for the purpose of saying something and then falsely denying that you had sad it. Who would believe that is not exactly what had happened? If someone actually did forge a message from you then few would believe that actually happened. Quoting myself here: forgeability uses a simple technical approach to create a much more complicated question of credibility.[1] [1] https://articles.59.ca/doku.php?id=pgpfan:repudiability https://articles.59.ca/doku.php?id=pgpfan:repudiability
- loup-vaillant 6y ago
  Obviously, if Alice is writing to Bob, repudiability is weakened in two ways: 1. She can't convince Bob she didn't write the message: it's written right there on Bob's phone, and he'd remember if he'd tamper with it. 2. If Bob starts showing Alice's message around, she can't pretend he misremembered, as would be possible with an oral conversation. She'd have to flat out call him a liar. --- > using a system that is deliberately designed to allow you to say something then deny having said it might also cause extra suspicion. Not if everyone used such a system. There's a difference between building & using your own obscure deniable chat application, and WhatsApp and Signal themselves enabling this. > In practice [repudiability] has very little value. It is unlikely that the feature is worth the extra risk of the complexity it would take to implement it. Deniable schemes are not more complex. There's just one simple condition: use Diffie-Hellman key exchanges instead of signatures. The result will likely be simpler than a scheme that relies on signatures. I've implemented both key exchanges and signatures with elliptic curves (X25519 and Ed25519 specifically), and I'm telling you, key exchange is significantly simpler and harder to get wrong. (For the anecdote, I screwed-up once in my cryptographic work, and it was the signatures). See https://noiseprotocol.org https://noiseprotocol.org for fairly simple key exchange based protocols, with various properties one might care about (key compromise impersonation, resistance against replay-attacks, anonymity to third parties…).

permille42 6y ago

From FAQ: Q: Can I backup my messages? A: No. :( The killer feature set of a messaging system that will allow it to crush WhatsApp, Signal, Session, etc: * Fully open source ( app, nodes, everything ) * End-to-end encryption ( obviously ) * Rotating keys for deniability. Basically just create time valid subkeys and periodically post the private key to the subkeys. Probably once a day would be sufficient. * Full message export/import including tweaking and faking messages. It isn't really deniable if you can't show you could easily fake some past messages. * Fully capable Linux client, so that we aren't forced to use an untrusted and possibly backdoored phone to use it. * Extra secure time bucketed send/receive if you want to avoid timing attacks on location. * Hash section bucketed messages along with the bucket by time. For example, if your public key is 4BC56..., you can request all messages sent to 4BC* and get them all, so it isn't then obvious who exactly you are. * Subkey unique per communication partner. This way gaining someones subkey for a time period doesn't let you potentially capture other packets you know are encrypted and decrypt them too... * URL based identity. Post your public key to URL; tada that URL can then be used as your identity. Have a bunch of different secure countries host free identity upload sites. * Group chat which just makes it so you communicate every message to every other partner in the group chat and vice versa. Any other way wouldn't be secure. * Message size padding to private size based packet matching. * Automatic sending of periodic messages to bogus destinations. This way it is not immediately apparent if you are sending something out or not. Preferably this would include adding random people and engaging in nonsense chat sessions with them for random amounts of time. Only the client on the other end would know if it is a bogus message or not. * Message nodes completely wipe all data hourly ( for regular messages ) or daily ( for the daily grouped messages ) * Message nodes all ban any client attempting to download more than a certain threshhold of data. Publish the banned clients publicly. Expose the watchers. * No registration. Basically anyone should be able to send/receive through whichever node they wish that has available bandwidth. You send an encrypted chunk with a destination ID. Others can download chunks tagged with some hash part of the destination. * Central "saturation tracking node" that receives saturation from all registered nodes in the system and just publishes a file on a URL for whoever wants it to figure out which node they will use to communicate that isn't over-saturated. * Can post a set of nodes you listen on to your URL with public key periodically so clients know how to start communication with you. Once established; switch to unsaturated nodes... The following features are somewhat irrelevant: * Onion routing. Just connect to the service through any number of other onion routing systems. No need to put all our eggs in one basket. Use a private VPN + Tor to connect to the system. Done.

rakoo 6y ago

I'm no cryptographer but I can see that messages are signed before they are encrypted, for no obvious reason. That's failing the cryptographic doom principle (https://moxie.org/2011/12/13/the-cryptographic-doom-principle.html https://moxie.org/2011/12/13/the-cryptographic-doom-principl...) and so should be taken with care. OTOH the drop of Signal Protocol features makes sense in their appreciation of real world: as soon as an attacker has full control of the device all the protections fail. This is probably the number one source of working attack anyway