Why Cryptography? I personally have only a superficial knowledge of it. Yes, I have read the classic work , but that was a long time ago; yes, I understand the difference between symmetric and asymmetric encryption, I know what elliptic curves are, but that’s about it. Moreover, the existing cryptographic libraries, with their charming habit of including the full name of the algorithm in each function name along with a bunch of initializer parameters sticking out, give me, as a programmer, a terrible headache.
So why? Probably because while reading the current flood of publications about data protection, confidential information, etc., I get the feeling that we are digging in the wrong place, or more specifically, that we are trying to use technical means (cryptography) to solve issues that are essentially social problems. Let’s talk about that; I don’t promise any groundbreaking discoveries or specific suggestions, just idle thoughts.
A little history, just a tiny bit
In 1976, the United States adopted a federal standard for symmetric encryption algorithms — DES. This was the first publicly available and standardized cryptographic algorithm created in response to the growing demands of business for data protection.
A beardy curiosity
The algorithm was published by mistake. It was optimized for hardware implementation and was considered too complex and inefficient for software. However, Moore's Law quickly put everything in its place.
It seemed — the end of the story, just encrypt, decrypt, and if necessary, increase the key length. You might know perfectly well that the Americans left backdoors in it; for you, there is a Russian equivalent — , which you probably trust even less. Then use both, one on top of the other. If you believe that the FBI and the FSB have united for your sake and exchanged their backdoors, then I have good news for you — you are not paranoid, you have a simple delusion of grandeur.
How does symmetric encryption work? Both parties share the same key, also known as a password, allowing them to decrypt whatever has been encrypted. This scheme works perfectly for spies but is entirely unsuitable for the modern internet, as this key must be transmitted in advance to each participant. For a time, while a relatively small number of companies protected their data in communication with known partners, the problem was resolved using couriers and secure mail. However, as the internet became widespread, the issue emerged.
Asymmetric cryptography
involves two keys: a public key, which is not kept secret and can be shared with anyone; and a private key, known only to its owner. Anything encrypted with the public key can only be decrypted with the private key, and vice versa. This way, anyone can learn the public key of the recipient and send them a message, which will only be readable by the recipient. It seems the problem is solved?
However, The internet does not work that way,, and the problem of authentication , especially, initial authentication, and, in a sense, the reverse problem of anonymity, arises. In short, how can I be sure that the person I am talking to is indeed who I intended to speak with? And that the public key I am using really belongs to the person I intend to communicate with? Especially if I am contacting them for the first time? And how can I instill trust in my partner while maintaining anonymity? Right here, if you look closely, you can see an internal contradiction.
Let’s consider in general terms what interaction schemes between participants exist and are practiced:
- server-to-server (or business-to-business, in this context they are the same): this is the simplest classic scheme, for which symmetric cryptography is quite sufficient; the participants know everything about each other, including out-of-network contacts. However, note that there is no talk of anonymity here, and the number of participants is strictly limited to two. In other words, this is almost an ideal scheme for a very limited number of communications and is generally obviously seldom applicable.
- Server — anonymous (or business — client): there is some asymmetry evident here, which asymmetric cryptography successfully addresses. The key point here is the absence of client authentication; the server does not care with whom it exchanges data; if such authentication is ever needed, the server conducts secondary authentication using a pre-agreed password, and at that point, it all reverts to the previous case. On the other hand, the client places extreme importance on server authentication, as they want to be certain that their data is being sent to exactly the address intended; this aspect, in practice, relies on a certificate system. Overall, such a scheme is quite conveniently and transparently covered by the https:// protocol, yet a couple of interesting points arise at the intersection of cryptography and sociology.
- Trust in the server: even if I securely transmit some information to the server, technically, unauthorized individuals could access it there. This issue is completely outside the realm of encryption responsibility, but I ask you to remember this point, as it will come up later.
- Trust in the server's certificate: the hierarchy of certificates is based on the existence of a root certificate that is worthy of absolute trust. Technically, a sufficiently powerful attacker [, please consider the term attacker as a technical term rather than a slander or offense towards existing authority] can replace the certificate of any lower level; however, it is presumed that the certification system is equally necessary for everyone, i.e., this certifier would be immediately ostracized and all their certificates revoked. While that may be the case, do note that the system is based not on technical means, but on a kind of social contract. By the way, speaking of the apocalypseIn light of the anticipated apocalypse of the RuNet, has anyone analyzed the potential cocooning of the Russian root certificate and its implications? If anyone has read/written on this topic, please send me links; I'll add them, as I find the subject interesting.
- Indirect de-anonymization on the server: this is also a sensitive topic, even if the server has no formal registration/authentication, there are many ways to collect information about the client and ultimately identify them. It seems to me that the root of the problem lies in the existing HTTP protocol and similar ones, which understandably could not foresee such chaos; and it would indeed be possible to create a parallel protocol without these flaws. However, this goes against all existing monetization practices and is therefore unlikely. Still, it raises the question: has anyone tried?
- Anonymous — anonymous: two people meet online, (option — just met), (option — not two but two thousand), and want to chat about their topics, but in a way that Big Brother doesn't hear (option — mom doesn't know, everyone has their own priorities). You may hear irony in my voice, well, that's because it is. Let's apply Schneier's postulate to the task (any algorithm can be hacked if sufficient resources are invested, meaning money and time). From this perspective, infiltrating such a group using social methods poses no difficulty, not to mention the money; that is, the cryptographic strength of the algorithm is zero with the most sophisticated encryption methods.
However, for this case, we have a second bastion — anonymity, and we place all our hopes on it; let everyone know us, but no one will be able to find us. However, with the most modern technical protection methods, do you seriously believe you have a chance? I remind you, I am now only talking about anonymization; we seem to have convincingly dealt with data protection already. For clarity, let’s agree that if your name or home address or IP address becomes known, the cover is completely blown.
Speaking of IP, this brings up the aforementioned trust in the server, after all, your IP knows this without a doubt. And everything is working against you here — from simple human curiosity and vanity to corporate policies and monetization. Just keep in mind that VPS and VPN are also servers; to the theorists of cryptography, these abbreviations are somewhat irrelevant; and the server jurisdiction doesn't matter much in dire situations. End-to-end encryption also falls under this — it sounds nice and solid, but you still have to trust the server on its word.
What is the role of a server in such a messenger? First of all, trivially, it's like a postman; if the recipient is not home, it can drop by again later. But more importantly, it serves as a meeting point; you cannot send a letter directly to the addressee, you send it to the server for further delivery. Most importantly, the server performs the necessary authentication, verifying to everyone that you are who you say you are, and for you, that your interlocutor is indeed who you need. It does this using your phone.
Don't you think your messenger knows too much about you? No, no, we certainly trust it (and by the way, our phone as well, hmm), but cryptographers assure us that it's in vain, that you shouldn't trust anyone at all.
Not convinced? There's also social engineering; if you have a group of a hundred interlocutors, you must assume that 50% of them are enemies, 49% are either vain, foolish, or just reckless. And the remaining one percent, no matter how skilled you are in information protection methods, against a good psychologist in a chat, you likely won't stand a chance.
The only seeming defensive strategy is to blend in among millions of similar groups, but that's not about us; it's again about some spies-terrorists who have no need for online fame or monetization.
Well, it seems to me that I've somehow justified (no, not proven, just justified) my harsh thoughts regarding data protection in today's societal model. The conclusions are simple but saddening — we shouldn't expect help from data encryption beyond what we already have; cryptography has done all it could, and it did well, but our model of the internet completely contradicts our desire for privacy and nullifies all our efforts. I'm actually not a pessimist at all and would really like to say something positive right now, but I just don't know what.
Try looking into the next section, but I warn you — there are entirely pink, unscientific fantasies, yet they might encourage someone and at least amuse others.
Is there really anything that can be done?
Well, for instance, we could contemplate this issue, preferably freeing our minds and shedding prejudices. For example, let's temporarily completely sacrifice anonymity, as terrible as it may sound. Let each person be issued a unique personal public key at birth, along with the corresponding private key, of course. Don't yell at me or stomp your feet; in an ideal world , this is extremely convenient — here you have a passport, a tax number, and even a phone number in one package. Moreover, if we add an individual certificate, it results in a universal authenticator/login; additionally, there could be a pocket notary capable of certifying any documents. We could create a multi-tiered system — only the public key and certificate would be publicly available, while for friends (whose key lists are included here), we could make the phone number and whatever else friends trust available; there could be even deeper levels, but that would imply unnecessary trust in the server.
With this scheme, the privacy of the transmitted information is achieved automatically (although on the other hand, why in an ideal world?), Alice writes something to Bob, but no one will ever read it except Bob himself. All messengers automatically get end-to-end encryption, their role is reduced to mailboxes, and there can be no claims about the content in principle. The servers themselves become interchangeable; you can send through one, through another, or even through a chain of servers, like email. You can also send it directly to the recipient if you know their IP, without engaging any intermediaries at all. Sounds great, doesn't it? It's just a pity that we won't live in such a wonderful time — neither you nor I© Well, here I am again, talking about the sad things.
Next, where will all this be stored? Well, off the cuff, we could create an open hierarchical system, something like the current DNS, only more powerful and branched. To avoid overloading root DNS admins with additions and modifications, we could allow free registration, with only one necessary check — for uniqueness. Like >> " Hello, we are five people, the Ivanov family. Here are our names/nicks, here are our public keys. If anyone asks — please send them to us. And here's a list of five hundred grandmothers from our neighborhood with their keys; if anyone is asking for them, send them to us too.«
We just need to make the installation and configuration of such a home server extremely simple and convenient, so that anyone can figure it out if they wish, and again, no one will unnecessarily overload various official government servers.
Stop!, but what does the government have to do with this at all?
And now, it is possible to carefully restore anonymity. If anyone can generate a personal key and confirm it with an individual certificate and set up a lower-level CA server, or ask a neighbor, or use a public server, what is the point of all this formality? Moreover, there’s really no need to tie it to a real individual; complete privacy, security, and anonymity are achievable. It’s sufficient that there is someone trustworthy at the top of the hierarchy; after all, we trust TM or Let’s Encrypt, and well-known public DNS providers haven’t led anyone astray yet. From the bureaucratic side, there shouldn't be any complaints either—well, there will be complaints, of course, but for what, actually?
Perhaps one day such a system, or something similar, will be created. And of course, we can rely on no one but ourselves, as no known government will build such a system. Fortunately, existing platforms like Telegram, i2p, Tor, and certainly others I’ve forgotten demonstrate that nothing fundamentally impossible exists. This is our network, and it’s up to us to shape it if we are dissatisfied with the current state of affairs.
Brrr, I accidentally ended on a pompous note. In fact, I don't like that; sarcasm is more my style.
PS: this is all, of course, pink fluff and girlish dreams.
PPS: but if someone suddenly decides to try it out — reserve the nickname for me. please, I've gotten used to it.
PPPS: but the implementation seems quite simple, by the way.
Source: habr.com
