Hacker News Reader

> If your communication is encrypted it shouldn't matter if it passes AT&T networks.

That assumes metadata is irrelevant. The destination, time of day, and volume of the traffic all have value separately and especially so when together. The destination can be masked if you control both sides and AT&T is a go between, but timing issues are subject to analysis unless you are a large enough player to give safety in numbers or you push noise across your pipes.

Hear, hear. The stream of encrypted packets that makes up someone's web browsing traffic is a very telling one and transactions of various web apps have telling signatures, which can be then correlated with eg social media updates or other signals that ripple to the target's contacts.

It's not that hard to anonymize metadata.

Just decide how thoroughly it must be done, and do what it takes. Plus a safety factor.

It is extremely hard to anonymize metadata, thats part of what makes its capture and analysis so insidious.

Please tell me how i anonymize the metadata of where my cellphone is located, which the telco harvests from towers its connected to.

Put it in a bag, and don’t use it.

Cellphones are a pain, that's true. I was mainly thinking about Internet metadata.

If you really care, one option is having multiple phones, under different identities. Each one only gets used in a distinct set of locations, for distinct projects, with distinct recipients. When not in use, you store phones in labeled Faraday bags. That is, compartmentalization.

Another option is to nuke the radio in your phone, use only WiFi and VPNs for internet access, and use hosted cellphones from multiple providers. You can still compartmentalize, but need only carry one phone. But you depend on WiFi access.

> If your communication is encrypted it shouldn't matter if it passes AT&T networks.

IIRC, the signals intelligence agencies like the NSA learn almost as much from traffic analysis (e.g. who's talking to who and when) and metadata than from actual message content. Mere encryption itself often doesn't protect much from that.

I'd argue that metadata is more important than content. It enables suspicion-by-association lines of inquiry. Once you know whos' involved in a conversation, it's much easier to target them for closer attention, such as hacking their machine or rubber-hose cryptography, both of which nullify any crypto you might have used.

> I'd argue that metadata is more important than content

Isn't metadata, practically speaking, a subset of content? (If you have the latter, you almost certainly also have the former?)

Metadata is more useful than content if you're capacity constrained, technologically or legally, in collection and/or analysis.

Isn't metadata, practically speaking, a subset of content?

Importantly to how we think about communication, no.

Metadata is the signature that accompanies or encapsulates content, viewable to the world. You can completely conceal content, through encryption for example, but you can't completely conceal metadata.

In other words there must be a physical exchange of energy somewhere (communication), and metadata tells you something about how the exchange happened, irrespective and ignorant of what the content is.

> you can't completely conceal metadata

You can do it with a very high cost (in overhead, latency, and availability) by having a large number of people all send and receive messages, on a fixed or randomized schedule, exceeding their maximum possible amount of communication with one another. Then someone monitoring the network knows that each of the participants in this system could have communicated with any other participant, but not whether or not the communication took place.

Even ignoring the practicality part, it becomes a timing game, because "empty" messages - even if they were filled with unintelligible "random" hex - would traverse the network differently than ones with variable length/size content and would be able to be filtered out pretty quickly.

The bottom line is that you are going to leave a signature of some sort through communications - the question is, can you properly build a comms system system that is functional within the limits of your risk/reward criteria.

> Even ignoring the practicality part, it becomes a timing game, because "empty" messages - even if they were filled with unintelligible "random" hex - would traverse the network differently than ones with variable length/size content and would be able to be filtered out pretty quickly.

To eliminate the statistical observability of metadata, the padding needs to reach or exceed the maximum capacity of the channel. So you can't have people sending more messages than the padded channel permits per time period. In your example, packets "with variable length/size content" would need to be absolutely prohibited, or else all packets' length would need to be randomized, and message data would need to be sent following strictly the same distribution as padding messages.

For example, you and I could have a rule of exchanging exactly 1 MB of data per day, at a specified time, every day. Then an observer wouldn't be able to tell whether, on a particular day, we had actually communicated something to each other or just allowed the padding data to go out. Clearly in this system we're not ever allowed to use it to transmit more than 1 MB per day, without destroying the metadata unobservability property. An attacker still knows that you and I are part of a system that offers us an otherwise unobservable channel, but not when we do or don't make use of that channel.

There are lots of variants that also allow many-to-many messaging, again at a high cost in overhead, latency, and availability.

> Clearly in this system we're not ever allowed to use it to transmit more than 1 MB per day, without destroying the metadata unobservability property.

You're also not ever allowed to transmit links or anything else that goads the user into fetching a remote resource in response to a message.

>>>> but you can't completely conceal metadata.

> For example, you and I could have a rule of exchanging exactly 1 MB of data per day, at a specified time, every day.

Depending on the size and popularity of the relay network, the fact the two parties are connected to it could be valuable metadata.

If you really wanted to minimize the amount of metadata to something that's almost useless, you'd probably need to use something like a continuously-operating broadcast numbers station.

https://en.wikipedia.org/wiki/Numbers_station

On it's face such a scheme seems theoretically robust, but for frequency correlation only. I'd be curious if in practice it would be possible to eliminate all other variability though, of which there are many. For example I'm unaware of any true solution to latency triangulation.

My hunch is that it wouldn't be possible, and there would be a side-channel vulnerability somewhere.

I'm not proposing a low-latency interactive approach, so latency triangulation shouldn't apply. In my example mechanism, we always have to wait a full day until sending any reply, so there's no event that an attacker can use to measure latency from.

Edit: the beginning of this research is the Dining Cryptographers.

https://en.wikipedia.org/wiki/Dining_cryptographers_problem

Although Chaum's solution has terrible availability properties, it's unconditionally secure against outsiders!

There is no evidence of this. If you have a system outside the US sending encrypted data to a system inside the US, all anybody can see is that these two systems are talking to each other. They can't see whose communication is inside that encrypted data to tell who is talking to whom and when.

Encryption is irrelevant if the third parties (google, facebook, apple, etc.) are willing to give up private keys or data in response to requests or secret court orders. The same is true if the devices you own contain backdoors or exploits specifically designed for or not-fixed for the NSA.

In the case that the data is being stored by third parties (google, facebook, apple) or insecure devices then it's also irrelevant if the data passes AT&T's network or not.

Well.. supposedly AT&T is the capture, right? So passing the AT&T network would increase the odds of your packets being read.. right?

In the cases that your traffic is unencrypted, yes, but that should be rare enough that you worry about it each time it happens.

Bigger in this case is the pattern of life rendered by just inspecting headers. And they can get a lot of headers sitting on these ATT locations.

> the communications will not be directly used against you >in court.

Directly. But via parallel construction...

Yeah, gathering evidence not admissible in court really helps the investigation find evidence that is.

Exactly. Once they know exactly what someone has done and how, it's relatively easy for them to find alternative means of "suspecting" that person of doing the crime and convince the judge to give them a warrant for exactly what they've already found through the illegal surveillance operation.

I wish judges and defense attorneys would catch on to these tactics more quickly. The rate at which the prosecutors/FBI invent new tricks to fool the courts and defense attorneys so far seems to far outpace the judge and the defense attorneys' understanding of what's even happening.

Take cell site simulators, for instance - the FBI has used those in secret for more than a decade before they were uncovered at all, and then it took another decade for judges here and there to catch-up and start requiring warrants for such operations.

And this goes for a lot of FBI's "investigative techniques", too, which are often illegal, but what judge is really going to know the difference between those highly technical operations?

All this assumes the judiciary is fair.

I feel otherwise.

When Microsoft was about to be broken up an appellate judge overruled the prior judge. That judge went on to be the FISA secret court judge.

Remember that the NSA Key was discovered around the same time[0].

So Microsoft was in bed with NSA prior to 1999 with a crypto key backdoor.

They were helped by an future FISA judge.(Does that background look like a national security judge?)

When I look at the Judges resume I can help but to wonder if she was an NSA plant the whole time.[1]

The Commerce Department is a frequent cover for the NSA.

I have to assume they use deep cover people all around us.

[0]https://www.heise.de/tp/features/How-NSA-access-was-built-in...

[1]https://en.wikipedia.org/wiki/Colleen_Kollar-Kotelly

I am skeptical of source #0. I thought that idea of nsa keys had been debunked. At least that source is not complete. Someone found a string 'nsakey' and they talk about analyzing the 'entropy of the source code'. What does that actually mean in technical terms that make sense to software engineers? I'm too stupid to understand that I guess. Sure, it would make sense for the nsa to try to do this. But it wouldn't make as much sense for microsoft to do it. Linux is out there now. I used to work at microsoft, and our product had a secured special bug database where we recorded security issues. We didn't want random people in the company to know that you could make your login name do string injection was an example of something we had there.

> I wish judges and defense attorneys would catch on to these tactics more quickly.

Is there a tech-law publication which targets judges and defense attorneys?

https://www.google.com/search?num=100&source=hp&ei=6ngxW9iYG...

Most traffic is HTTP/S. I would bet a decent amount of dollars the NSA can transparently MiTM any common CA certs. Look at what a mess the trusted roots are.

It could always be used as leverage if the appropriate situation arose.

We need a word for pointlessly bringing up quantum computation to prop up a vituosically weak set of arguments. Like Godwin’s Law, but more worse-er.

Quantum computation changes the complexity of brute forcing common encryption algorithms. It seems very plausible that actors are storing high value encrypted messages for future decoding in case QC enters the realm of possibility.

I vaguely remember reading that storing encrypted messages just in case it might become possible to decrypt them later on has been common practice in intelligence services for decades (if not longer).