Encryption
Contents |
How much does encryption have to be end-to-end?
All of the existing social services and softwares are rather low on privacy. The contents of messages and status updates are kept on servers. If the servers are federated, then they are kept on several servers. Unless the messages were intended to be public anyway, we lose control over our messages.
That's why in various discussions on the list we decided to require end-to-end encryption – that means our messages are protected straight from our computer or smartphone all the way to our friends' computers or smartphones. No more in-between servers, gateways, not even trusted ones.
Most likely this requires the installation of a new software. Some initiatives try to do encryption in the web browser, but that doesn't make sense: A web browser is designed to show you a web page from a server, so if the server is no longer trustworthy it can fool you into thinking your browser is doing encryption for you.
This doesn't mean you can't have a web-based social network, the difference is only that there will be no server somewhere else. The server is on your own computer.
How to convert GPG to SSL to SSH and back
Yes, that's possible according to this article.
Some notes on encryption
When designing a communication protocol, we need to select cryptographic primitives at various points to achieve goals we want the protocol to fulfill. As with any technology, this step harbors some potential pitfalls. I'll list some of them here and give more detailed examples below.
- Having a hammer, seeing nails
- With today's cryptography research, it would take a very dedicated person to know about all the (fascinating) protocols and algorithms proposed every year which show solutions for seemingly intractable things like divisible, anonymous cash with protection against double-spending, for anonymous voting that only allows eligible voters who can check their vote has been tallied correctly, but cannot prove that to someone else (to avoid selling votes) etc.
- This fact makes it all the more important to first lay out the actual problem we are trying to solve and to then look for the proper tool (which may or may not be a cryptographic primitive).
- Improper use of good tools
- Unfortunately, cryptography is not yet at the point where a complete layperson can simply throw some routine at a problem and be done with it. The fact that even companies like Microsoft manage to make the same blunt mistakes multiple times in this area should be more of a warning than an excuse.
Tool selection
As stated above, it is not always straightforward to adapt some cryptographic tool to properties deemed desirable – and it may not necessarily be a good idea to bolt new properties onto an existing primitive, such an action usually requiring an analysis not much simpler than the initial design itself.
As an example, some people regard non-binding signatures of messages a desirable goal. The design this author has seen proposed so far was to use some RSA signing key that would simply be made public should the need arise. This approach falls short of being a solution on several counts:
- In as far as it would achieve anything, such a step would invalidate all messages signed by that key.
- The rationale in the protocol design was something along the lines of “since nobody could prove that the signature was made before the key was released” – ignoring that the original author may be the last relevant party to hear about the publication and all sorts of time-stamping.
Depending on the exact goals and the kind of communication to protect, there are various other protocols available, including:
- For private messages between two parties, simply encrypting them with a key known to only those two proves that one of them encrypted it. If Alice receives a message encrypted with a key only known to Alice and Bob, and she knows she didn't send it, then Alice knows the message to come from Bob, but cannot prove that fact to anyone else.
Note that this does not require a private channel between Alice and Bob, since the (very well researched) protocol by Diffie and Hellman gives us a way to get shared secrets without one. - Almost the same holds for small groups where it is only necessary to confirm that the author is a member of the group. In this case, Diffie/Hellman does not apply directly, but there are extensions to multiple parties.
- For larger groups, or if the individual author needs to be identifiable, more complex protocols need to be employed. Such tings do exist.
- For public posts, it may be necessary to either use a server with some kind of zero-knowledge verification protocol (such that a transcript could have been forged) and/or to build in a non-negligible chance of forging posts. Or maybe this author simply doesn't know the proper tool yet? (Hint: If you do, just edit this page.)
Using tools
Cryptographic tools, just like hardware tools, have some specific assumptions on their use built in, and just like knowing where to grab a knife or why not to use a chisel as a screwdriver, it pays to follow them. Two examples of blunt mistakes found in practice:
Stream ciphers
These days, the general trend seems to be to recommend stream ciphers. There's nothing wrong with that, as long as the protocol designers keep the basic safety rules for stream ciphers in mind:
- Do not rely on the encryption for the integrity of your message.
- Never use the same cipher stream for two different messages.
The reason for this is that stream ciphers use easily inverted operations, typically a simple XOR, to combine the cipher stream with the message. If Eve captures two messages encrypted with the same key, (m1 xor key) and (m2 xor key), she can compute (m1 xor key) xor (m2 xor key) = m1 xor m2, and is left with the statistically much, much simpler task of getting information about m1 and m2 from this data.
RSA key packaging
Most people who learned about RSA are aware that public and private key are interchangeable. That is correct – as far as the basic algorithm is concerned. In practical implementations, there are two reasons why it is not a good idea to distribute the private key file and keep the public one secret:
- Virtually all keys are created with small public exponents. In almost every case, the program generating the key will start at a constant (3, 17, and 65537 are typically used, because a low Hamming weight makes the computations a little faster) and if that doesn't work, progress in some non-randomized fashion.
- To speed up computations, the private key file typically contains the values of p, q, and ((1/q) mod p).