search

matrix-org / matrix-spec

The Matrix protocol specification
Apache License 2.0
170 stars 90 forks source link

The strategy of `Harvest now, decrypt later' seems like a HUGE problem for matrix's privacy and encryption. #1868

Closed Kreyren closed 2 weeks ago

Kreyren commented 2 weeks ago

Disclaimer: I am making this as https://github.com/matrix-org/matrix-spec/issues/975 doesn't seem to addressed with the needed urgency to verify whether is this actually a problem as assumed and if so to be actionable on the approach and urgency to manage this as e.g. crypto is not the full solution as e.g. routing might also need to be reconsidered.

It seems to me that Harvest now, decrypt later (https://en.wikipedia.org/wiki/Harvest_now,_decrypt_later) a strategy where a threat actor collects and stores encrypted data to be decrypted in the future once a method that can decrypt these messages at a reasonable time and efficiency is discovered (e.g. Quantum Computers) poses a HUGE problem for all matrix users and their privacy as any threat actor can just spin up a home server (or home servers as the way matrix relays the messages seems to make it very efficient to do so) and start collecting these encrypted events (encrypted messages, images, etc..) to be able to decrypt them in the future, but please correct me if i am wrong as where i stand now it seems sane to consider matrix as compromised and consider this a Shit Hit The Fan issue.

richvdh commented 2 weeks ago

Duplicate of #975

richvdh commented 2 weeks ago

Knowingly opening duplicates of an issue is not a good way of persuading people to your cause. Honestly, it just makes you look like a spammer.

Kreyren commented 2 weeks ago

Knowingly opening duplicates of an issue is not a good way of persuading people to your cause. Honestly, it just makes you look like a spammer. -- @richvdh (https://github.com/matrix-org/matrix-spec/issues/1868#issuecomment-2163923749)

This issue is meant to be about whether this is actually a problem and if it is then it's supposed to be actionable on the the urgency and management of issues alike https://github.com/matrix-org/matrix-spec/issues/975 to address the problem rather than the problem itself, adjusted the wording to make this more understandable.

tranquillity-codes commented 2 weeks ago

I do not think this issue is a duplicate, as it is about discussing the importance of PQC in Matrix, unlike #975 which is discussing how to adopt PQC in Matrix after it will be tackled. In my opinion, how important a given thing is is not the same thing as how to do that given thing.

richvdh commented 2 weeks ago

I don't think it's a controversial stance to expect the importance of an issue to be discussed on that issue, rather than opening a completely separate issue. Otherwise we might as well have two copies of every issue in our tracker.

Kreyren commented 2 weeks ago

I don't think it's a controversial stance to expect the importance of an issue to be discussed on that issue, rather than opening a completely separate issue. Otherwise we might as well have two copies of every issue in our tracker. -- @richvdh (https://github.com/matrix-org/matrix-spec/issues/1868#issuecomment-2166118266)

The problem of Post-Quantum Safety ("PQS") is publicly known since like 2018 (published by iacr in 2017 and known about in the Computer Science since 90s) where most projects that are serious about privacy and security has implemented management e.g. OpenSSH, SimpleX, Signal and Lokinet. By 2019 it was reported to matrix (https://github.com/element-hq/element-web/issues/8889) and by 2022 it was correctly triaged in matrix-spec where it seems to be treated as "nice to have thing" to this day instead of "shit hit the fan" that this problem seems to require and imho should have been proactively handled by 2019 max.

This is just not enough, this problem basically defeats the encryption of all harvested data as soon as efficient enough Quantum Computer gets in the hands of a threat actor where based on my tests yesterday and gathering statistics from home server admins it's realistic to collect more than 8 GB of encrypted data in 12 hours where judging by matrix's popularity we can probably sanely assume that a global adversary is already doing this in a much larger scale and for much longer.. That to me is a privacy and security nightmare that each day after it's disclosure in 2018 expands exponentially on severity project-wise and impact on the users as the longer this goes the more sensitive data can be harvested from the users that we have no way of retroactively fixing as we would need a physical access to the threat actor's system to remove them.

This is why this issue exists, beyond the threat to the common user matrix is projected to be used for critical infrastructure in the EU where many banks are already using it and NATO members such as the German Bundeswehr are already known to be using Conduit.rs for their mission-critical and sensitive information in their operation and that's why i believe that we should be focusing a lot more resources into managing this problem as soon as possible which is all that this issue is about.

turt2live commented 2 weeks ago

This all feels like discussion which should be held on https://github.com/matrix-org/matrix-spec/issues/975 - I'm not seeing a distinction between the comments here and the scope of #975.

I'm locking this to encourage the conversation to move to the other issue.