michael/blog
1
0
Fork 0
Code Issues 2 Pull requests Releases Packages 1 Wiki Activity

new post

Browse source
This commit is contained in:
Michael Zhang 2021-08-30 02:52:21 -05:00
parent 8bcce8a5c7
commit b04175954b
Signed by: michael
GPG key ID: BDA47A31A3C8EE6B
5 changed files with 224 additions and 6 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

11
assets/sass/_content.scss
View file

@ -10,6 +10,10 @@ body {
color: $text-color;
}
h1, h2, h3, h4, h5, h6 {
color: $heading-color;
}
header {
margin: auto 12px;
@ -21,7 +25,7 @@ header {
#title {
font-size: 2.5em;
color: $text-color;
color: $heading-color;
&:hover {
text-decoration: none;
@ -146,4 +150,9 @@ table.table {
> p {
line-height: 1.5;
}
.footnotes {
font-size: .9em;
line-height: 1.2;
}
}

8
assets/sass/main.scss
View file

@ -7,6 +7,7 @@ $monofont: "Roboto Mono", "Roboto Mono for Powerline", "Inconsolata", "Consolas"
@media (prefers-color-scheme: light) {
$background-color: white;
$heading-color: #15202B;
$text-color: #15202B;
$small-text-color: lighten($text-color, 10%);
$smaller-text-color: lighten($text-color, 18%);
@ -17,9 +18,10 @@ $monofont: "Roboto Mono", "Roboto Mono for Powerline", "Inconsolata", "Consolas"
@media (prefers-color-scheme: dark) {
$background-color: #15202B;
$text-color: #D4D4D4;
$small-text-color: darken($text-color, 10%);
$smaller-text-color: darken($text-color, 18%);
$heading-color: #E4E4E4;
$text-color: #BCBCBC;
$small-text-color: darken($text-color, 8%);
$smaller-text-color: darken($text-color, 12%);
$faded: #666;
$link-color: lightskyblue;
@import "content";

2
content/posts/2021-08-11-backup-plan.md
View file

@ -9,7 +9,7 @@ Imagine this: you get hit by a car on vacation and you wake up with memory loss,
We all have secrets that we keep, whether it be social security numbers, passwords, people's birthdays, but how we store that information is all very different. And sometimes, we store information in places that requires possession of other information. One question I began asking myself recently is: have I gotten my information into a circular dependency?
Suppose I have a safe where I protect physical properties, keep the code to a safe in my email, which I protect with a password and two-factor auth via security codes on my phone.
Suppose I have a safe where I protect physical security, like a keep the code to a safe in my email, which I protect with a password and two-factor auth via security codes on my phone.
- Talk about grace period between losing a form of authorization and being locked out from it
-

204
content/posts/2021-08-29-e2e-encryption-useless-without-client-freedom.md Normal file
View file

@ -0,0 +1,204 @@
+++
title = "why end-to-end encryption is useless without client freedom"
date = 2021-08-29
draft = true
tags = ["computers", "privacy"]
mastodon = "TODO"
+++
Today, many companies claim to provide "end-to-end encryption" of user data,
whether it be text messages, saved pictures, or important documents. But what
does this actually mean for your data? I'll explain what "non-end-to-end"
encryption is, and why end-to-end encryption is important, and also why it's
also absolutely meaningless to have in some circumstances.<!--more-->
> If you just want to read about end-to-end encryption, click [here][1].
> Otherwise, I'll start the story all the way back to how computers talk to
> each other.
a game of telephone in a noisy room
---
Computer networks basically operate like a bunch of people yelling at each
other at a public gathering, where everyone is kind of hearing everyone else's
messages, but only really paying attention to ones addressed to them. Let's say
I wanted to grab some Chipotle with my friend Nathan. I'd basically yell "HEY
NATHAN, WANNA GET CHIPOTLE?" over this public network, where Nathan would see
his name, identify it as a message that is intended for him, and then reply
accordingly. Notably, everyone _else_ listening to the network also hears this,
and knows that I'm itching to get some Mexican food.
That's not even the worst part, because how does your computer connect to the
internet? Your router hears your computer's message, and passes it through a
bunch of middlemen, who all do this broadcasting through some local network,
until it gets to wherever your computer wanted to talk to in the first place.
But in order for the middlemen to pass on the message, they'd have to hear the
message, so now my lunch has become a public gathering known to everyone who's
heard or passed on the message.
encryption saves the day
---
That's where **encryption** comes in. Encryption lets me change the message to
something that the middlemen and everyone else listening on the network can't
understand, but the person that I actually wanted to send the message can turn
it back into the original. This way, I can be sure no one except Nathan got the
memo of where we were grabbing lunch.
So the way encryption's being used here is known as _transport_ encryption,
since I'm _sending_ a message somewhere. Transport encryption is basically
standard practice now through a technology called **transport-layer security**,
or TLS, which is used by almost everything that talks to the internet, your
browser, your email client, your phone. If it's not using TLS, it's considered
insecure.
If you're thinking ahead, you'll know that the other place encryption can be
used is **encryption at rest**. This is for documents and pictures that need to
sit somewhere in storage for a while but shouldn't be visible to everyone. Most
business computers use _full-disk_ encryption, so their employees' data don't
get compromised.
When you put these together, your data is actually pretty safe from prying
hands. If I put some tax documents on Google Drive, it'll use _transport_
encryption to make sure no one steals my identity while I'm sending it, and
encryption _at rest_ to make sure someone breaking into Google won't be able to
just pull the hard drive out and read the files off it.
two halves don't equal a whole
---
It turns out just putting together these two types of encryption isn't enough.
There's someone else we haven't protected ourselves against in this case, which
is the party responsible for decrypting the transported data and then
re-encrypting it at rest. Google can read all the documents I upload to Drive
after decrypting it from transit and before encrypting it to disk. Facebook can
read all the messages I send to my friends after decrypting it from transit and
before re-encrypting it to send to my friends.
And this is a lot smaller of a problem than it was before! Companies usually
have privacy policies to protect user data from being used against what they
expect, and many industries have laws like [HIPAA][hipaa] and [FERPA][ferpa] to
make sure the people handling your data don't leak it.
But we don't have to just _trust_ them on that, because we already _know_ how
to protect data from middlemen who are simply taking a message and sending it
somewhere else unchanged, like the ISPs from our networks. We just need _more_
encryption!
**End-to-end encryption** is just encrypting the data in a way that the only
parties allowed to read the data are the people it was intended for. Password
manager services like 1Password and Bitwarden use end-to-end encryption so that
they're not decrypting your passwords when you store them online, they're just
storing the encrypted data as-is, and then handing it back to your device which
then decrypts it offline. [Signal][signal] famously provides end-to-end
encrypted chat, so that no one, not even the government[^1], will be able to
read the messages you send if they're not the intended recipient.
it's still not enough {#not-enough}
---
End-to-end encryption seems like it should be the end of the story, but if
there's one thing that can undermine the encryption, it's the program that's
actually performing the encryption. Cryptographic algorithms usually work in
terms of clients, but unless you want to sit there adding points on an elliptic
curve in a finite field, that client is your device or your browser, not you.
The big problem here is how do you know your device is actually performing the
encryption? How do you know the apps on your phone are only sending the data it
needs to send, and not a lot more? Traditionally, independent researchers or
bounty hunters may reverse-engineer client software and discover that they
didn't quite operate as advertised, but we can't just rely solely on people
from reddit with too much time on their hands to uphold security.
Imagine if Google Drive was actually a physical vault service and the website
was just a person you would hand your valuables to to keep safe. They could say
"we're keeping this in military-grade security," but unless you watched what
they did, how do you know they didn't cheap out on you and just shove it under
the mattress where hackers breaking in could just steal everything?
Same applies to Apple's new child protection system. Their [white paper][csam]
goes in painstakingly great detail about how photos are protected by
"multi-layer" encryption before it's able to be decrypted by Apple. But typical
users are not allowed to pick apart your iPhone to make sure it's encrypting
everything correctly, or that the perceptual hashing algorithm it uses to
filter pictures isn't just trivially flagging everything for manual review.
WhatsApp data is stored unencrypted to the running application in order to
store a database of messages locally. Additionally, this database can be backed
up to iCloud, and according to [WhatsApp themselves][whatsapp], that data is
stored unencrypted, which means that it may benefit from _transport_ security
and _encryption at rest_ independently, but ultimately the people moving data
around are still able to read it.
I've also seen discussion of undermining end-to-end encryption in a [ghost
proposal][ghost], a method that abuses multi-party encryption to add in a
"ghost" listener, which can be the company or the government or anyone else
that the vendor chooses. In theory, this backdoor could be prevented by an
open-sourced client that properly checks each recipient to make sure it's the
expected person before encrypting the message and sending it.
Given that end-to-end encryption solely exists because trusting companies that
run services is insufficient, it's safe to say that trusting companies to make
client software that act in the interest of their users is just as useless as
trusting companies to make services that act in the interest of their users.
what can i do?
---
Although inconvenient, trusting different vendors for different pieces of this
technological assembly line is the best way to prevent it from becoming abused.
Many software use **open protocols**, communication schemes that are agreed
upon and freely available to everyone[^2]. Then, independent parties develop
and maintain lots of different software that all speak the same protocol, so if
you don't trust a particular service to have an app that doesn't encrypt its
data properly, you can just choose to use a different one by someone who you
trust more.
Email is a famous case of this: if I sign up for an email account with Outlook,
I don't have to use a proprietary Outlook client. I _could_ if I wanted, and I
imagine that there may be some features that Microsoft has added specifically
to the Outlook website and apps, but since they claim to conform to the _open_
email specifications, I can just choose to use a different one.
On top of that, email is _federated_, which means that if I didn't like
Outlook's services, I could switch to a different provider and _still_ be able
to chat with people on Outlook, unlike many of today's siloed services where I
can't just message people on Facebook if I only have an account on Twitter,
since they don't talk to each other using the same protocol.
[Matrix][matrix] is a new chat network that also follows in the same spirit as
email, but also has the benefits of multi-party encryption. There are multiple
apps and servers, and servers can federate with each other using an open
protocol. I would strongly recommend people who are interested in privacy to
consider it.
conclusion
---
Why care? This might just seem to be some superficial political concern by
privacy advocates who warn of dangerous edge cases that only matter to people
whose rights are being violated by some dystopian government. Well, to put it
bluntly, that dystopia is now, and it's not just the government we should be
afraid of, but tech megacorps who possibly have even more power.
We live in a digital world, so it's important to know how it works and who's in
control.
[^1]: Governments and other parties with enough computational resources may
still be able to undermine specific levels of security, or just [threaten you
personally][wrench] until they get what they want.
[^2]: Large corporations typically still have majority representation in the
committees that decide on the most impactful specifications, but these are
still made available to researchers who can analyze and critique it.
[1]: {{< ref "#not-enough" >}}
[csam]: https://www.apple.com/child-safety/pdf/CSAM_Detection_Technical_Summary.pdf
[ferpa]: https://en.wikipedia.org/wiki/Family_Educational_Rights_and_Privacy_Act
[ghost]: https://www.internetsociety.org/wp-content/uploads/2020/03/Ghost-Protocol-Fact-Sheet.pdf
[hipaa]: https://en.wikipedia.org/wiki/Health_Insurance_Portability_and_Accountability_Act
[signal]: https://signal.org/
[wrench]: https://xkcd.com/538/
[matrix]: https://matrix.org/
[whatsapp]: https://faq.whatsapp.com/iphone/chats/how-to-back-up-to-icloud

5
layouts/posts/single.html
View file

@ -23,7 +23,10 @@
<hr />
<small>
End.
Thanks for reading!
{{ if .Params.mastodon }}
Have comments? Discuss this post on <a href="{{ .Params.mastodon }}" target="_blank">Mastodon</a>.
{{ end }}
</small>
{{- end -}}