Privacy Guides
Session(Formerly Loki) | Decentralized Messengers #296
-
|
Session Messenger is missing under Real-Time Communication - Decentralized. |
Beta Was this translation helpful? Give feedback.
Replies: 0 comments 42 replies
-
|
I disagree that Session should be included as I don't think it's been battle-tested enough. I also have concerns with both the Jurisdiction that Session is under (Australia) and the fact that the organization that Session is under (Oxen) develops Session (Messenger), Oxen (Cryptocurrency), and Lokinet (Self-contained Network), which is an insane undertaking for any organization. The fact that Signal got a lot of backlash was also because they planned on implementing Cryptocurrency into Signal which would fall under IRS jurisdiction. Although I am not fully familiar with Australian law so please inform me on whether this actually matters. The fact that Session implements all these into the application which creates questions and problems SHOULD make you hesitant on including them into PrivacyGuides. I believe that until we can get full and total confirmation on Session's implementations and laws surrounding the application should we include them into PrivacyGuides and even then I still do not see why having a Cryptocurrency and Self-contained Network that isn't Tor which has been battle-tested for years, included into a messaging platform is at all necessary. The Session application has also been buggy for both me and a lot of others that I have seen talk about Session, although it has gotten a lot better over the years and of course your mileage may vary. Currently the Android GitHub Repository has 136 open issues and 186 closed and 47 open issues and 91 closed for the iOS Repository. Something as important as a Chat application should be scrutinized this harshly and until most if not all of these issues have been ironed out will I MAYBE agree that Session should be included into PrivacyGuides, although there are still some infrastructure issues that very likely won't be changed like Lokinet over Tor and the Oxen implementation. TL;DR I think we should stay conservative and wait until Session irons out most of it's issues. Edit: Read the response comment by @KeeJef and my own response to his. |
Beta Was this translation helpful? Give feedback.
-
|
Actually, Even I agree to this on most part. 😞 Session has just been audited last year and considering the description of most of whitepaper, it looks like they are focusing on anonymity which has been clearly depicted under the section of Threat Model.
This is infact a little concerning. Seeing the past history of month for Session-Android, it looks like it still needs polishing. But on seeing the release history, it looks they are going towards right direction. I agree that it still needs polishing.
I agree on that. 👍 Since I am currently using various messengers, I (and anyone) will look into Session for a few months before recommending on PrivacyGuides. After asking certain concerns to Session Team, I'll continue the disscussion again. Sorry for bringing this issue up. |
Beta Was this translation helpful? Give feedback.
-
I definitely think Session could turn into an interesting project (Not my cup of tea as I prefer applications like Signal where simplicity and small codebase is key) and I am curious to see where it goes in the future. Hopefully the Session Team can iron out most of these issues and be can re-evaluate Session in the future.
All good, having discussions and opinions considered is the backbone of FOSS. |
Beta Was this translation helpful? Give feedback.
-
|
I think including Session at least as a honorable mention would be a good idea, I have been testing the app and while it needs some work its actually been very robust on its message synchronization now. To address a few concerns :
So please do not dismiss this project as Signal + Crypto bloat. They are providing a level of privacy that no other app is managing to provide and do not compromise on their vision. It is impossible to use the app without privacy (Unless you leak your own private keys) as it contains no features to send anything insecurely. And it has no central point of failure or government authority so even if requested they would not be able to comply with these orders. Last but not least the app is open source, so code level backdoors would be able to be audited by anyone if they were forced to implement them. |
Beta Was this translation helpful? Give feedback.
-
I have no qualms about this besides the fact that again, Lokinet has yet to receive the same amount of attention and analysis as Tor.
Again, I understand how Tor in general works and how Lokinet works in general, but this does not remove my issue that this has yet to see enough exposure to real world use cases to warrant an inclusion into Privacy Guides.
It isn't Signal + Crypto, you completely missed the point I was trying to bring up in that having Crypto included into a messaging platform puts Session in the jurisdiction of the AUSTRALIAN GOVERNMENT a more anti-privacy government than even the US and UK.
Again, I support their vision but I think it needs time to show that it is safe.
This is an insanely broad statement to make. How can you guarantee that it is "impossible"? You can guarantee that the Messenger (Session), the Cryptocurrency (Oxen), and Lokinet, are all secure? Exactly you can't.
The employees are a central point of failure. You have to remember that Australia has mandatory key disclosure laws that mandate the disclosure of encryption/unlock keys upon request. Failing to comply carries a penalty of 6 months imprisonment, i.e you lost your key. Refusing to comply carries imprisonment of 2 years.
I think you have an extremely skewed stance on what open source is. Linux is open source but they have had security flaws in the kernel that have existed for almost the entire existence of Linux itself. Can you really guarantee that there are no backdoors placed into Session, Oxen, and Lokinet? Have you looked at the code personally? Not only that but with how much Session and Lokinet are updating and changing new audits become necessary as they have already introduced 30% more code. (Hypothetically) What Session needs is time and exposure to real world use cases to solidify it's validity. What Oxen is trying to accomplish is extremely broad and tough for any organization and that raises too many questions. |
Beta Was this translation helpful? Give feedback.
-
|
After several emails with Oxen Project and reading through their docs, there are some important aspects that I would like to address, so as to drop Session Messenger from PrivacyGuides. According to their TOS, which itself is a bit concerning,
Session assumes no liability for any losses or damages resulting from any matter (such as privacy breaches?) relating to their service and any liability on behalf of the service is only limited to $10 ? I would like to have a conversation regarding these terms, especially the first point. If enough people agree to the first issue, it would be good to end this discussion. |
Beta Was this translation helpful? Give feedback.
-
|
Hey guys, I'm the CTO at Oxen and Session. I've only just noticed this thread and the archival of the privacytools.io repository, so I haven't been able to participate in this discussion until now. There's quite a bit to respond to here, but I’ll try and address each of the points being raised. Battle-Testedness Session (Originally Loki messenger) has been publicly available since late 2018, giving it 3 years of battle-testing in the public domain. We’ve got approximately 200,000 monthly active users across all platforms as of the time of this post. Session has also had its code audited by Quarkslab, the report can be here. Considering the size of our user base, the amount of time Session has been available publicly, and the fact that its code has been audited more recently than any other recommended messenger, I think it’s fair to say Session has been somewhat battle-tested. Jurisdiction concerns It’s true that Australia’s attitude towards encryption is both concerning and disheartening. Our foundation does a lot of advocacy work around this issue, and I can assure you that this attitude is in no way unique to Australia. As we’ve seen very recently via ProtonMail, authorities will apply pressure to tech companies no matter where you are, even the so-called ‘best’ or ‘safest’ jurisdictions. However our view is that Session is not affected by the Identify and disrupt nor the assistance and access bills that have been passed in Australia.This view has been formed by working with our lawyers in Australia who have analysed the relevant legislation, and via our own technical analysis of the the Session protocol and understanding of our influence. You can read more about that here https://loki.network/2018/12/10/lokis-response-to-the-assistance-and-access-bill-2018/ . The TL:DR is that both the law and decentralised technology we have built mean it would be near impossible for us to be compelled to introduce intentional backdoors or flaws into Session. Scope of work Some comments focused on the scope of the team's work being too large. It's true that we’re tackling lots of big issues at once, including a private cryptocurrency, anonymous routing network, and anonymous messaging platform. However, we are a very well funded and large organisation full of passionate people who want to improve privacy. It's hard for us just to focus on one domain, but that's actually been one of our advantages — our development projects are all interconnected. While all of our projects benefit from having their own dedicated teams, those teams are able to share knowledge and expertise with each other. and our programmers all have each other’s goals in mind. Because of that, we’re able to offer privacy in a multitude of ways: E2EE; network obfuscation; and application level pseudo-anonymity. Buggy code It’s true this is something that we have consistently struggled with. Our releases of Loki Messenger and early versions of Session had often debilitating message reliability issues (Messages failing to send, issues with receiving messages etc.). This has gotten much better over time as we’ve improved our protocols and network stability, and although we still have lots of bugs to solve, message reliability is in a good state. If you haven't used Session in 6 months, I’d encourage you to regenerate a new Session ID and have another go — I think you might be surprised about just how much we’ve progressed. Issues open vs closed and progress on issues With all due respect measuring Session's progress on fixing bugs by looking at issues open versus closed (or how many total issues we have open, for that matter) is not going to give an accurate measurement of the state of the application. For comparison, Signal has 1.3k issues open right now. The better measure is probably to look at ratings of the application over time or compared to other applications, Session currently achieves a 4.2 stars on the Google play Store and 4.4 stars on the iOS App Store compared to Signals 4.4 stars and 4.7 stars on those same platforms. This indicates that users are currently rating both apps similarly, with Signal slightly preferred. Session’s ratings are currently trending upwards, and recent feedback has been positive, so I’d expect us to close in on Signal’s store ratings over time. Cryptocurrency Session is connected with the Oxen cryptocurrency through the Oxen Service Node Network. Oxen Service Nodes are responsible for routing and storing Session messages, among other responsibilities, and they are incentivised using OXEN rewards. Regardless of your opinions on cryptocurrencies, OXEN provides Session with a decentralised, high-performing, Sybil-resistant network. However, OXEN is not included in the Session application, and we have made a conscious effort to separate the cryptocurrency from the Session messaging application. This makes Session’s on-boarding experience simple and easy. There is potential to implement OXEN payments using Session IDs in the future, but currently we’re focusing on other aspects of the application. Integrating cryptocurrency into a messenger is not a process which should be rushed, and we would exercise extreme caution if we went ahead with a wallet integration. Should we choose to implement it, it’s worth noting that OXEN does offer advantages over Signals MobileCoin, because it is a properly decentralized cryptocurrency. Oxen is based on Monero (XMR) and it does not rely on a centralized network of proprietary Intel SGX CPU's to process transactions. Terms of Service The app terms of service are largely a formality which are required by the app stores for inclusion. By design we as the Session developers have almost no ability to enforce the ToS because we have no control over the Service Node Network and we cannot identify individual users of the Session application because of the pseudonymous nature of Session IDs. I encourage you to come up with a hypothetical issue where we could actually use our ToS to do something malicious to a Session user. I'm happy to answer any further questions you have |
Beta Was this translation helpful? Give feedback.
-
|
Hey KeeJef, I just read your response now and don't really have much time to formulate a proper response so apologies if I seem all over the place. First off I would like to apologize for my previous comment, I just re-read it now and I feel it comes off as too "aggressive" and I hope you don't end up taking it too badly.
I like that you included the user count so I/we can get a better grasp on how Session has been holding up. I think most of my concerns where directed towards how the project (Session) would evolve overtime. You can audit code at a certain point in time but if say hypothetically speaking half the code would be replaced/changed then the audit would be negligible. If I didn't get my point across well then apologies. I do have a question though, does Oxen/Session plan on auditing their code as the project evolves? If so what are the plans for when to audit? After a major release or every year? Any information would be helpful.
I really like that you mention ProtonMail's situation here. Yes, I have been reconsidering judging companies/organizations simply based on where they are located in. I agree with your sentiment that privacy in general has been and will probably continue to be undermined in all countries. As always I still will probably share concerns towards Australia's attitude and the future of where they make take things, but I think basing projects off a future that may or may not come to pass comes off as a bit paranoid and a bit distasteful. I will take your word on the laws surrounding Australia and Oxen but I think bringing it up previously was distasteful of me as I didn't even have much knowledge towards the laws in/surrounding Oxen in Australia in the first place. If I we're to provide some context towards my negative outlook it would probably due to the only contact I have being hateful towards Australia in general and never wanting to be involved in companies based in such, so I guess that might've influenced my own personal opinion. P.S I include a question on Australia's laws surrounding Oxen (Cryptocurrency).
I'll be taking your word on that, although we have seem Session recently getting better so I will take that as proof that there haven't been internal issues (besides the earlier discussed issues/bugs with Session, but that can be summarized as just how things go when initially launching a product/project.). Question: Does Oxen have any plans on expanding their reach into other future projects? What are the current plans for the organization? Do they just plan on working on Session/Oxen/etc as of this moment in time? Of course I understand that you can't promise that Oxen won't branch out into projects that tries to solve issues. Personally I would prefer if Oxen continues this work on Session at this pace without plans to branch out so suddenly as of this moment. I've seen companies fall after getting their hands stuck on projects that almost seemed pointless/destined to fail and losing focus on their main goal/project (Mostly Mozilla and their random projects like Mozilla VR.).
I don't blame Oxen/Session for having a shaky launch, I think every start-up has had shaky launches for that matter. The only reservation/concern I had was the attitude Oxen/Session would have towards a shaky launch. I've seen so many projects have a shaky launch and just die out after a couple of years (Looking at you Mozilla), but since it looks like Session seems to be taking the project seriously then I do agree that perhaps those reservations we're unneeded. I do still prefer to stay conservative on things and wait a bit longer to see how projects are handled even after cases like these. I only ever did a quick look of Session (recently), but I think I might try using Session for a longer period of time once I'm available to.
No respects needed, that point I tried to bring up was part of a former point that I decided not to include into the comment. I honestly should've just dropped it but I decided last second to reuse it and try to shove it into my previous arguments and it very obviously fell flat and seemed out of place. I never bothered editing it out/changing it as I only ever login to GitHub ever so often. Again, apologies for the comment, I won't remove it as of this point I feel it would just create confusion and I don't want to hide my mistake.
As always, I will probably have some reservations about this but I do like that you are taking the issue seriously, otherwise I don't think I have any other comments to make towards Oxen the only question I would have is that I'm not sure how the laws surrounding Oxen are so I would like some information on that if possible. P.S I don't really have much negative opinions towards Cryptocurrencies (I personally like projects such as Monero) it's just that I prefer to stay conservative especially when including them into things besides their intended use case. Question unrelated to the previous points but is how is the health of Lokinet? If I'm not mistaken Lokinet runs similar to Tor with user run nodes so I'm curious how the distribution of those nodes currently are. Has there been a dip in distribution in the current pandemic? I'm asking this question as I'm wondering whether Lokinet is stable enough for changes such as these. Finishing Thoughts(?) As always, I probably will hold some reservation/hesitation towards the architectural structure of Session but from what I can see you do seem to be taking the issue seriously as previously pointed out. I do hope the project/organization the best as any competition/research does help/fill the admittedly very empty space we have now. I can probably understand the use case for a lot of the projects it's just that I'm not so sure on whether or not these projects are mature/battle-tested enough, although the points you have brought up have alleviated these concerns. |
Beta Was this translation helpful? Give feedback.
-
Yeah its something we have thought about, especially for major additions, like new onion routing protocols, or changes to the Session protocol, there is however a large cost associated with auditing software, not just financially but also logistically, so its about balancing those concerns.
No plans currently, we intend to continue our focus on Session, Lokinet and Oxen. You can read about the vision over the next 6-12 months here https://oxen.io/blog/the-oxen-ecosystem
Lokinet health is largely determined by the health of the Service Node network, as Service Nodes are the routers in Lokinet. The Service Node network is running very strong at around 1750 Service Nodes, near its all time high https://oxendashboard.com/#4 , distribution is still fairly focused around central Europe and the US where bandwidth costs are the cheapest and significant data-center infrastructure is located, but that's largely the same phenomenon experienced by the Tor network. We have been making some documentation changes to try and address this |
Beta Was this translation helpful? Give feedback.
-
|
Looking over this, and the previous thread I don't see any reason why session shouldn't be added. We were formulating a criteria, for inclusion but loosely it was going to be:
From what I can tell, Session does actually fit both of these particular points. I've used the desktop client a little but, not really used it a lot though. |
Beta Was this translation helpful? Give feedback.
-
|
Just another point here. We require that encryption be on by default for private messages. |
Beta Was this translation helpful? Give feedback.
-
|
Looking at this particular PR from our old repos privacytools/privacytools.io#2293 I think we want to make some adjustments to the page, so we can include things like this. From previous discussion, Session isn't really "federated" but it isn't really P2P either. I didn't particularly like the term "nodal" as it doesn't really fit any CS description. I think we should replace the P2P section with a decentralized section, and roll the "peer-to-peer" into it. In time it's likely that Matrix will also be included in that category. This will mean we won't really have a federated section anymore. These programs do work quite differently, so we may need to re-work the pros/cons portion for that. |
Beta Was this translation helpful? Give feedback.
-
|
this might be the cleanest way to do it. |
Beta Was this translation helpful? Give feedback.
-
|
Tagging @lrq3000 too as he was the primary person working on that PR |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for notifying me. I also wasn't aware about privacyguides, good to see the legacy of the original PTIO living on :-) I also like the idea of tagging, especially since softwares can implement multiple forms of networks (eg, Briar). But one advantage with the old approach of having subcategories is that each network model produces a different threat model, so having subsections allows to clarify this to the user. If we choose to use tags, which I think is a quite elegant solution, we could recycle the subsections into a "Threat models" top section that would be placed below the listing of apps, similarly to other pages, where additional details on threat models are explained after the listing (eg, 5 eyes page). Although this was on the old PTIO so I'm not sure this is still something that would fit the new UI? Please note that in my latest revision of my PR, I dropped the "node" classification as nonsensical after the feedback, in favor of "anonymous routing" which involves any network where two clients are connected through rendez-vu nodes in a pseudo-random circuit with layered decryption of packets along the route. Anonymous routing is an accepted terminology, and it is what matters to assess the threat model (ie, this offers pseudo-anonymity guarantees). For example, Briar would be tagged with both "P2P" and "Anonymous routing", while Session would be "Anonymous routing" only. |
Beta Was this translation helpful? Give feedback.
-
|
With anonymous routing the question becomes how you properly differentiate between randomized nodes/peers and a federated model. After all the threat model is different for each of these categories since in a federated model you have a single point that knows stores everything about you (If matrix.org ever gets compromised all unencrypted messages are then compromised, while if a randomized node gets compromised they would only have a portion of the data). Another worry i have is regarding the strength of the word anonymous on a privacy website. How anonymous does this need to be for that term to be appropriate? After all at all times at least one node would know part of your information. Onion Routing would be a well understood term in the Tor world but may not include everything since it would exclude applications that have a single intermediary and merely shield the IP address between users. Randomized Routing would be a possible alternative, since this clearly describes that the routing needs to be randomized for it to apply but says little over the methodology making this broad enough to be a tag or a category for potential applications that contain a different number of hops (1 or more) per part of the application while still clearly excluding federated applications or other applications where you connect to a single server. Because we include the term Routing in this we would need a criteria of what routing means in this context. Must messages be relayed between nodes? Or is relaying a message between two users enough if its an application which does not onion route and they happened to land on the same node? |
Beta Was this translation helpful? Give feedback.
-
|
Please excuse me, my previous description and example of what anonymous routing is were inaccurate. Or rather, too specific. What I described was onion routing indeed, perhaps the most well established and known working example of anonymous routing. But there are lots of other such systems. Anonymous routing is very vast. I just found a paper that tries to formalize the categorization of the various anonymous routing protocols. It's a great paper IMHO, it's doing much better what I clumsily tried to do:
This survey makes it clear that anonymous routing is in fact a quite general term. In fact, maybe it's too general. Given the multiplicity of methods used for this kind of networks, how can we define what is an anonymous routing network? Another academic work suggests to define an anonymous routing network by its purpose:
https://doi.org/10.1007/978-1-4419-5906-5_628 The advantage with defining anonymous routing per the intended goal(s), instead of the technical implementation, is to be arguably more future-proof, especially given how multiform is the domain as we saw above, and for sure there will be unforeseen evolutions in the future. I'd suggest, if we are to use anonymous routing as a tag/section, to accept these criteria to define what is or is not an anonymous routing protocol: that it either hides the sender, receiver or the link between them. Although randomization is in general an important tool for anonymization, it's not always the best approach. As the survey I linked above analyzes, deterministic selection of nodes by the sender/receiver can allow to safeguard against malicious nodes, because the sender/receiver can select trusted nodes. In line with this, I only found one paper on an algorithm to use randomized routing for anonymization in wireless networks. Maybe I missed data, but it seems to me that randomized routing is mostly for scheduling network flow, not to mitigate privacy issues. In any case, I think we need to favor terms that have a clear relationship to a threat model. Centralized, decentralized, federated all have pretty clear respective threat models. Anonymous routing is also a clear indication, although the technical implementation varies widely. One interesting thing to note that the survey enlightened me about (my previous posts in the old PRs show how confused I was about this question) is that anonymous routing is not necessarily a P2P or nodal network (ie, not necessarily symmetrical). I think a federated network could be an anonymous routing network too given an adequate implementation, ie, as long as both senders and receivers are hidden and cannot be linked by external observers nor any of the federated servers. The survey actually classifies Tor as being a hybrid system, ie, half P2P and half federated (because there needs to be service nodes). Hence, classifying communication apps on PG with tags seems to be more adequate than trying to binarily classify in sections. |
Beta Was this translation helpful? Give feedback.
-
|
Just a quick note: I think the cryptocurrency Oxen is a minor detail in terms of assessing the threat model. Initially, I found Session because I was looking for blockchain based telecommunications, but I came to realize that this is not the foundation of this network, which is good and is how they can keep telecommunications free. Session uses a 3-hops onion-like TCP routing for now. In the future, this will be replaced by the much faster UDP Lokinet. The nodes are the validators of the Oxen blockchain. In other words, Oxen just serves as a financial incentive for providers to support the Session network infrastructure, whereas Tor relies on goodwill. This is clever, as indeed blockchains' main flaw, the Sybil attack, is the same limitation as for Tor. So if cryptocurrencies regulations become unfavorable, the major issue I guess would be that Oxen nodes may lose the financial incentive to provide nodes to service the network, hence reducing the security of the network. But 1) Oxen nodes are already distributed worldwide, so let's say a ban on cryptocurrencies in Australia won't bring down all nodes, only a subset, 2) this can be monitored in real-time in a decentralized and objective way since it's a blockchain (in the previous PR, there is a link to such a dashboard -- note the dashboard can go down if the Oxen foundation goes down, but not the blockchain). Disclaimer: this is my own analysis based on my own understanding of how this very complex interlinked suite of tools work, there may be some inaccuracies. |
Beta Was this translation helpful? Give feedback.
-
|
In addition their dashboard is open source, the dashboard can go down if the Oxen foundation goes down, but other people would be able to bring it back up. After all they are not a central authority so anyone should be able to replicate this with the code they provide here : https://github.com/oxen-io/oxen-observer |
Beta Was this translation helpful? Give feedback.
-
|
Oh great! I didn't know it was opensource! Is this the repo for the dashboard? https://github.com/cryptolokimax/loki-dashboard Although I couldn't find an official link from the repo to the live version ( https://oxendashboard.com/ ), the titles of the various pages can be found in the code. |
Beta Was this translation helpful? Give feedback.
-
|
Oxen observer is a blockchain explorer which allows users to inspect transactions and see the state of the Service Node network (which is constructed from data stored onchain) you can find the source code here https://github.com/oxen-io/oxen-observer Oxen Dashboard contains a number of key statistics, like Service Node count, fees burned, price, supply and other relevant information taken from the Service Node network, exchanges and blockchain, source code is here https://github.com/cryptolokimax/loki-dashboard Theres also https://oxensn.com which gives some more relevant stats about Service Node health and other interesting metrics about Service Node history and unlock schedules |
Beta Was this translation helpful? Give feedback.
-
|
I think this issue is ready to proceed to a pull request. In conclusion, we should modify the page accordingly, as discussed and require:
|
Beta Was this translation helpful? Give feedback.
-
|
Here's a draft: #192 , please let me know what you think about it. If what I wrote was not clear enough, the criterion is that an anonymous routing messenger should hide the identity of the sender, the recipient or evidence that they have been communicating. Please let me know if I need to rewrite some parts, I pieced everything quickly together from the old PR with some modifications to fit what we discussed here. |
Beta Was this translation helpful? Give feedback.
-
|
Session doesn't have perfect forward secrecy though? |
Beta Was this translation helpful? Give feedback.
-
|
Wow I didn't know about this, I would prefer PFS being a requirement for listing. The argument used by Session for not implementing it is extremely weak and quite ironic given the name of the app. PFS is not about physical access, but about the possibility to decrypt a message by exhaustive search. https://www.eff.org/deeplinks/2014/04/why-web-needs-perfect-forward-secrecy |
Beta Was this translation helpful? Give feedback.
-
|
What do you mean by exhaustive search? The only way a message can be read by a Service Node in Session is if they have the users private key, and the only way to access the users private key is to gain access to the local device. In most cases even with a messenger that uses PFS device compromise is going to result in compromise of past messages because the device keeps a local copy of message history. |
Beta Was this translation helpful? Give feedback.
-
|
@KeeJef shocked you don't know, but: https://wikiless.org/wiki/Brute-force_search Edit: Endpoint protection is really something else, and no PFS does not offer anything in regards to that. |
Beta Was this translation helpful? Give feedback.
-
|
I am aware of Brute force attacks, we usually don't refer to these as Exhaustive search attacks though. There isn't any currently available technology which would be able to perform a Brute force attack to decrypt a Session message. Quantum computers are the most commonly proposed technology which would break the discrete logarithm assumption which would allow for decryption of Session messages, however its unclear how long this technology will take to develop to a useful state, if its even possible at all In the case that the discrete logarithm assumption breaks my understanding is that both Signal (Uses PFS) and Session messages that were collecte would be able to be equally decrypted and read https://crypto.stackexchange.com/questions/40860/does-perfect-forward-secrecy-using-dh-or-ecdh-imply-quantum-resistance . If my understanding is correct PFS does not provide protection against a post quantum attacker that collects encrypted messages collected at the network level |
Beta Was this translation helpful? Give feedback.
-
|
"Perfect forward secrecy however doesn't make it impossible to break DH or ECDH. It means that a leaked private key cannot be used to decrypt all recorded messages. It also means that you would have to perform an attack for each separate connection as you'd have to attack each separate key pair of one of the parties to retrieve the secret value." From your stackoverflow link @KeeJef. PFS adds an important layer of security. If my understanding is correct the Session Protocol is based of Signal's, so why wouldn't you include it? The risks of quantum are highly debatable, but let's agree that there is a reason why organizations such as NIST are working on new standards. That being said, it isn't the only attack possible, as @lrq3000 also described. |
Beta Was this translation helpful? Give feedback.
-
|
I think Kee knows what a bruteforce search is, but I think the question was
how it can apply (what attack scenarios) to an already encrypted and
anonymously routed communication protocol. And to me it was not obvious
either but I think I now have some idea how it could be conducted. Bear in
mind I am not a professional cryptographist, just a hobbyist.
I used this resource for my reasoning :
https://cryptologie.net/article/174/forward-secrecy/
Ok so let's assume that a malicious actor could find a way to record all
the encrypted messages emitted by a user, along with the time and day of
sending, and that the attacker knows the user's language. It is reasonable
to assume that we can filter the first message of each communication
session (ie, when there is a big time gap between two streams of messages,
probably a day has passed, we keep the first message of each stream). This
way we now have a list of "first message in the day" that the user sent.
Since we know the user's language, it's reasonable to assume that we have
good chances to assume that at least one of these messages, but likely a
lot of them, would simply be an encryption of a simple "hello" message in
the user's language. Now that we know the likely ciphered text, we can
perform a bruteforce attack on this subset of messages, which aren't that
many since we get 1 message per communication session = about 1 per day for
a very active user.
So in summary, if my understanding is correct, the messages history
increases the attack surface over time, and perfect forward secrecy is
essentially a way to completely destroy this cumulative effect of time. So
PFS is not about device access but to reduce the attack surface when an
attacker can record the whole messages history of a user, remotely or not.
See also: https://cryptologie.net/article/174/forward-secrecy/
Now it's worth keeping in mind that the nature of anonymous routing makes
it very difficult for a malicious third party to record the whole history
of a specific user, so IMHO session is much less affected than say Matrix.
Btw I think Briar also does not implement PFS? Should add a warning too
then.
I think it would be a very welcome additional security to have PFS in
Session, but IMHO this is not a critical flaw thanks to anonymous routing
which is already a barrier (but not a bulletproof guarantee) against
network graph data mining.
/EDIT: Also ph00lt0 edited their message on github to clarify it's a theoretical
risk of quantum computing, so implementation of PFS would make Session more
future-proof. I agree, since quantum computing is now a real thing, it will
certainly continue to progress over time to a point where such attacks can
be conducted.
|
Beta Was this translation helpful? Give feedback.
-
|
@lrq3000 I haven't really looked into Briar ever, but they do mention it here in their transport protocol: https://code.briarproject.org/briar/briar-spec/blob/master/protocols/BTP.md |
Beta Was this translation helpful? Give feedback.
-
|
Maybe actually essential wasn't the right word. I just really would have a hard time recommending something with better security is available. The argument written on the website, just really doesn't make sense to me. |
Beta Was this translation helpful? Give feedback.
-
|
Actually just noticed: Rocket chat also has a warning for not having PFS on the website. It might be good to ask someone with actual authority on cryptography to write something about the attack possibilities and add that to the website, to inform people of the risk. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for linking to Briar's relevant doc, I'll add that in my PR. Apriori Rocket.chat is going to be removed with my PR. Yes I agree it would be a good idea to have a paragraph about PFS and how it improves security by someone knowledgeable. |
Beta Was this translation helpful? Give feedback.
-
|
@lrq3000 I think with rocket.chat it depends on how you use it. Self-hosted within own network can still be a great alternative to Slack/Teams, unlike mattermost they actually work on encryption. It also integrates very well with Jitsi. |
Beta Was this translation helpful? Give feedback.
-
|
Arg typos, read "anonymous routing" instead of "anonymous recording" at the
end of my previous message.
Also ph00lt0 edited their message on github to clarify it's a theoretical
risk of quantum computing, so implementation of PFS would make Session more
future-proof. I agree, since quantum computing is now a real thing, it will
certainly continue to progress over time to a point where such attacks can
be conducted.
Le mar. 30 nov. 2021 à 17:53, Stephen LARROQUE ***@***.***> a écrit :
… I think Kee knows what a bruteforce search is, but I think the question
was how it can apply (what attack scenarios) to an already encrypted and
anonymously routed communication protocol. And to me it was not obvious
either but I think I now have some idea how it could be conducted. Bear in
mind I am not a professional cryptographist, just a hobbyist.
I used this resource for my reasoning :
https://cryptologie.net/article/174/forward-secrecy/
Ok so let's assume that a malicious actor could find a way to record all
the encrypted messages emitted by a user, along with the time and day of
sending, and that the attacker knows the user's language. It is reasonable
to assume that we can filter the first message of each communication
session (ie, when there is a big time gap between two streams of messages,
probably a day has passed, we keep the first message of each stream). This
way we now have a list of "first message in the day" that the user sent.
Since we know the user's language, it's reasonable to assume that we have
good chances to assume that at least one of these messages, but likely a
lot of them, would simply be an encryption of a simple "hello" message in
the user's language. Now that we know the likely ciphered text, we can
perform a bruteforce attack on this subset of messages, which aren't that
many since we get 1 message per communication session = about 1 per day for
a very active user.
So in summary, if my understanding is correct, the messages history
increases the attack surface over time, and perfect forward secrecy is
essentially a way to completely destroy this cumulative effect of time. So
PFS is not about device access but to reduce the attack surface when an
attacker can record the whole messages history of a user, remotely or not.
See also: https://cryptologie.net/article/174/forward-secrecy/
Now it's worth keeping in mind that the nature of anonymous routing makes
it very difficult for a malicious third party to record the whole history
of a specific user, so IMHO session is much less affected than say Matrix.
Btw I think Briar also does not implement PFS? Should add a warning too
then.
I think it would be a very welcome additional security to have PFS in
Session, but IMHO this is not a critical flaw thanks to anonymous recording
which is already a barrier (but not a bulletproof guarantee) against
network graph data mining.
Le mar. 30 nov. 2021 à 16:46, ph00lt0 ***@***.***> a écrit :
> @KeeJef <https://github.com/KeeJef> shocked you don't know, but:
> https://wikiless.org/wiki/Brute-force_search
> Obviously PFS does offer protection against physical access but PFS is
> her for different reasons. Key rotation is essential for secure
> communication if you want to be prepared for future leaks caused by
> interception.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <https://github.com/privacyguides/privacyguides.org/discussions/57#discussioncomment-1723045>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAIRFXXK4RQCIM56HTFC46TUOTWU7ANCNFSM5EAYL47A>
> .
> Triage notifications on the go with GitHub Mobile for iOS
> <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
> or Android
> <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
>
>
|
Beta Was this translation helpful? Give feedback.
-
|
Includes proprietary Google dependencies: Whereas other apps make it a compile time option: |
Beta Was this translation helpful? Give feedback.
Done in privacyguides/privacyguides.org#192