What is the alternative interpretation?
2ez
joined 1 year ago
Join us now and share the software
You will be free hackers, you will be free
The encryption software implements math that is designed to be the protection (encryption algorithm). That math is agreed upon by experts, and it gets implemented by software.
Encryption algorithms usually come with an estimated expiration. That is because computer processors become more powerful. Breaking encryption comes down to being able to solve the encryption algorithm quickly. Some algorithms are designed with specific features with certain types of processor architecture in mind, such as to effect the problem solving efficiency.
Encrypted chat messaging services need to upgrade their algorithms over time as processors get more powerful.
Depending on the type of algorithm used, your chat history could be at risk in the future; that is, if someone were to archive those messages and wait for a time when processors can solve the algorithm quickly. Alternatively, the problem solving could be distributed among many powerful computers to increase the number of attempts per second.
However, algorithms such as Signal's add a few more protective layers in the algorithm. The open-source software should be audited, and should have reproducible builds. What that means, is that the app binary that is distributed (such as from an app store) should match exactly one you build from the source code following the instructions.
To summarize many layers of math, and processes (such as validating someone's safety number, and pin numbers on Signal) were designed to protect the data it is encrypting, and who it is communicating that data with.
You cannot trust a vendor on their word, for example, WhatsApp also claims to implement Signal's encryption algorithm, but their source code is not open, so we don't know exactly what is in the binary. We can reverse engineer the binary, and make inferences, but governments and some private organizations love trying to backdoor encryption.
If using docstrings/docblocks to generate SDK documentation, adding something like an OPA policy to validate their existence and semantic structure could help with coverage. Then we have the issue of accuracy, and that needs humans or AI to weigh in. I have a feeling test-driven development would make this process smoother.
You could also add git hooks to facilitate accountability / run the policies.