The Case For Decentralization

Introduction

You can’t and shouldn’t trust massive, centralized tech conglomerates at all. The truth is that using any massive tech company and trusting them with any of your data is a 99.9% of the time a bad move. There’s 2 main arguments for this:

Big tech companies collect a lot of data about you, that comes with its own plethora of problems; namely, the main problem is the amount of tracking they include in their profit models. See, Google and Meta (for example) make most of their money off of you by brokering your data (collecting and selling it) and using it to target you with… advertisements! The modern society is all consume, consume, consume, and they make a HUGE amount of money off of it. As such, your data is incredibly valuable, and these companies have a very common tendency to leak that data. Since these centralized models focus on surveillance and selling your data (if that isn’t a massive concern already as it paves way for profits over humanity), it can also be really easily abused to control people, bringing us to the next point;
Because basically everybody you know uses these centralized platforms, they’re tied into said systems and thus reliant on a frankly parasitic relationship, making a perfect mass surveillance model. Governments and companies alike have abused this model to monitor, oppress, and control people in clear violation of legal and constitutional protections. Here’s some links:

Trust is a Funny Thing

Here’s an example. Assume that I’m a massive tech conglomerate (like Google) and you want to store your files in a very convenient service which saves your files in cloud infrastructure (like Google Drive). Now, using my proprietary service, you can’t really know how I’m handling your data, you just have to place your trust in me. (Side note: you can’t even trust open source services at times because you don’t always know if their servers run that specific code or different code, but in most cases it is much better than using large, centralized services.) Now, let’s assume that I use some insecure form of encryption, like AES 128 ECB.

You can see penguins through it!

ECB Penguin

AES ECB Demo (WASM)

Key (text, 16 bytes):

Key (hex, readonly):

Attacker input (string):

Unknown (secret to recover):

Output

Cracking Your Data

This’ll be a pretty technical section, so you’re free to skip if you want.

I had an encryption oracle (a black box that, given attacker-controlled input P) that returns

C = Encrypt_K(P || S)

where S is a fixed secret appended by the server and K is a fixed but unknown key. The server used AES128 in ECB mode.

I exploited these properties of ECB:

AES ECB encrypts each 16 byte block independently:
```
  C_i = E_K(P_i)
```
where P_i is the i-th plaintext block. There is no chaining or randomization (IV/nonce).
Identical plaintext blocks map to identical ciphertext blocks. That determinism leaks structure and enables chosen plaintext recovery when I (the attacker) controls part of the plaintext.

The process is relatively simple:

Detect block size b (here b is 16) by sending inputs of increasing length and finding the increase in ciphertext length per b bytes.
Confirm ECB by repeating a block of length b and seeing repeated ciphertext blocks.
To recover the first unknown byte of S, I send an input of length b-1 of attack bytes. The oracle encrypts A || S[0..], so the first block is A || S[0]. I then build a dictionary of all 256 possible last bytes: for each guess x, I compute Encrypt_K(A || x) and match against the oracle output. The matching ciphertext gives x = S[0].
Then you just slide one byte and repeat to recover subsequent bytes.

But What Does That Have To Do With Centralization?

The attack you and I just performed was simple and general. If a provider offers any deterministic server-side encryption with attacker controlled input, they leak secrets. Now, this is a pretty narrow case, but I’ll try to expand here a little.

You cannot assume the service you’re using uses the cryptography you think it does. A proprietary server could use weak encryption (AES128 ECB), reuse IVs, or leak data in a plethora of ways. Open source helps but does not guarantee the deployed binary matches the source.
Centralized providers hold keys, metadata, and control service logic. Compromise yields mass exposure likewise. They are attractive targets for coercion or surveillance (legal orders, secret warrants, data requests, infiltration, or – as the current US government likes to do – no warrants and unconstitutionally!)
Many large companies monetize behavioral data; the presence of that business model changes the risk metrics. Data aggregation + surveillance = capability to manipulate, censor, or profile and it’s a very lucrative venture. There is no incentive to stop after all.
Operational mistakes happen. Misconfiguration, poor crypto, migrations, etc. etc. The attack surface is HUGE. All the big tech companies you probably use (Google, Meta, AT&T, Verizon, etc.) have all had data leaks or, for example, the NSA is explicitly tapped in to their traffic (PRISM, Upstream Collection).

They Can Work Though!

There’s loads of things you can do to give your clients pretty good security and privacy; you could use E2EE, split-knowledge or threshold schemes, reproducible builds, remote attestation, stripping metadata, etc. The reason these massive, centralized tech companies don’t do this is because they lose out on a lot of money made from monetizing spying and surveillance.