Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> This is exactly the solution to that problem.

I could be wrong but I was under the impression that the way end-to-end encryption worked (like what Signal claims, I thought) was it was physically impossible for them to decrypt (handover decrypted data (aka your messages) to a court of law) because the public/private keys are impossible to crack and also not known by Signal.

It sounds like this isn't the case whatsoever.

I don't really understand modern chat apps that talk about encryption. By no means am I a pro on the subject so I apologize in advance but... if you really don't want ANYBODY EVER snooping on your data network wise (unless they are holding one of the devices and reading the screen after it has been unlocked via passcode/biometric, etc.), can't you just tell your friend a key and exchange it offline and then communicate freely with no middleman? Or even, with a middleman... that is just transporting your data and doesn't know your agreed upon shared secret or keys.

How could a subpoena ever work against this kind of data?



The problem lies not in encryption or key exchange itself. It’s in the fact that to make/use a solution that doesn’t suck in real life, you need a budget comparable to the entire crime you commit. As a developer, you may [help] create few keys and set up the encrypted scene for sending emails or even insecure chat messages, but your gang will fail even at groceries. All these apps are selling turnkey security in app stores, not something brand new.

can't you just tell your friend a key and exchange it offline and then communicate freely with no middleman

Yes, keywords are pubkey, fingerprint, diffie hellman. It’s easy to use, just run:

  openssl genrsa -des3 -out private.pem 2048
to generate a key pair, then export pubkey via:

  openssl rsa -in private.pem -outform PEM -pubout -out public.pem
Once you have you exchanged pubkeys and checked fingerprints offline, simply create a new secret key:

  openssl rand -base64 32 > key.bin
and encrypt that new key and also your message with it:

  openssl rsautl -encrypt -inkey id_rsa.pub.pem -pubin -in key.bin -out key.bin.enc
  openssl enc -aes-256-cbc -salt -in message.txt -out message.enc -pass file:./key.bin
Now just send .enc files over the wire. It is trivial to decrypt at their side, even my grandma can do that. She usually leaves raw files in her downloads folder though, but it’s easy to remove them via local crontab job.


It takes extra effort to design a system with this little amount of data. Note that we only have Signal's word for some of this; they could in fact log every single time that you login, which would make the amount of data sent to the FBI much larger (and could be of importance to the case, for example, if the defendant had a dedicated Signal account for the crime that they only logged into at certain times).

Then there's IPs. If you log IPs along with when someone connects, then an IP can often be tracked to a WiFi router, which then pins your location.

Most E2EE communication protocols will see (and thus potentially log) the time and destination of every message you send. If two people have been accused of conspiring to commit a crime, this could be material in forming the case. They may also store your contact list, but a sufficiently long list of messages sent will practically determine your contact list anyways.

Even just the time of messages could be important; if someone interviewed claimed to be in the shower at a certain time, but there were logs of a message being sent at that time, that's probably enough for an obstruction of justice charge to stick.


> they could in fact log every single time that you login, which would make the amount of data sent to the FBI much larger

I guess you mean each time you connected to their server to retrieve messages? There is no "login" step, Signal doesn't have a log in process. Presumably a typical Signal client calls several times per day.

The record they provided says connection date and despite being supplied in milliseconds since the epoch the value appears to indeed represent a whole day not a specific time. So you're correct Signal could be lying and actually store the exact moment you last connected, for whatever that's worth, and we could not prove they don't have that info.

> Most E2EE communication protocols will see (and thus potentially log) the time and destination of every message you send

Signal doesn't know who sent messages among close friends, and optionally not anybody who sent messages to a sensitive account.

Let's take the example of a message I sent to my friend Chris. I know Chris, I've sent messages to him previously and he knows me, so I'm in his contacts list. As a result by default my Signal client keeps some "Sealed Sender" tokens for Chris. When I send a message to Chris, my client uses a token it learned from a previous conversation with Chris, but Signal doesn't know who I am, just that I have a valid token for sending messages to Chris. So it stores the message, and gives it to Chris. Chris's client can determine that this is a message from me, tialaramex, but the Signal service never knew who sent the message.

If one day Chris hates me and blocks me from sending messages, his client invalidates all Sealed Sender tokens, and begins issuing new ones to his other friends so they can continue to contact him.


> Signal doesn't know who sent messages among close friends, and optionally not anybody who sent messages to a sensitive account.

I am aware of this, and I had split my comment into "extra things Signal could log" and "Extra things most other E2EE services could log" but somehow lost the divider between the two during editing.


I think you misread the post above. They're saying that the govt should be allowed to issue subpoenas, and nothing more. They shouldn't be allowed to mandate backdoors, or hack suspect's machines, etc. And citizens should be free to use cryptography to control their information.

Also, "Impossible" is not the right term. "Extraordinarily expensive" is a better one. And yes, anyone can share public keys with each other offline and have end-to-end encrypted communication without help from a service. But advertising companies and the govt are not incentivized to make that practice convenient, and people typically do what is most convenient.


> should be allowed to issue subpoenas, and nothing more

Issue a subpoenas for something they know they can't architecturally fulfill? I would imagine the government will get mad and shut them down, no?


This doesn't seem that different from subpoening a McDonalds for their security footage, and getting an answer back like "sorry, we've already deleted the footage from that day".




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: