151–160 of 164 posts
Earlier quoted context omitted.
I'd love to read a source that describes this in more detail. Assuming such an exploit exists, I don't think I'd be targeted with it. It's my understanding three letter agencies tend to hoard that sort of thing, not blast them at random privacy aficionados.
Look up "Broadpwn" for an attack on Broadcom's BCM43xx radios.
Earlier quoted context omitted.
> Furthermore, they allegedly already had his ip, so why bother with a stingray? They could simply tell his cell carrier to provide them with all his location data Remember that getting subscriber data/metadata from ISPs requires a warrant, and that a single tower location could cover a 6-12 sq. km. area (plenty of space to hide in)
Can’t they use the towers to triangulate the exact position? So that area should be rather small. Furthermore, if they already had the IP of the offender, getting a search warrant should not be the problem at all. This tells me there is more to this story.
Something doesn’t seem to add up. First of all the story fails to mention that those devices do not only track the target, they track and record all phones in its range, which is a massive breach of privacy and the real issue with those devices. Furthermore, they allegedly already had his ip, so why bother with a stingray? They could simply tell his cell carrier to provide them with all his location data (as well as…
I don't know about Verizon, but all the cellphone carriers I know have carrier-grade NAT set up. That would mean the public IP they have would correspond with many customers with different private IPs. The article says Verizon matched the IP address with a particular AirCard, but maybe that was an oversimplification in the article.
Earlier quoted context omitted.
Nit-picking a bit/kind of augmenting your train of thought. You can have non-interactive Diffie-Helman key exchange (via a PKI). As you say, the client would need to know prior to that the public key/have access to the certificate and that would require certainly revamping the DNS approach we now have (even if we did not use DNS, we would still have to deal with DNS requests).
That's literally the second option I describe. What is your point?
Technically, the client could encrypt their IP with the y=H(g^{scr}) key (result of the DH KE) and send (Enc(y, IP), g^{rc})-- where H is the oracle, g^s server public key, rc *key (or generally 1 time key). The server can then compute the same key (g^{rc}^s and then apply H) and decrypt.
So the second and third paragraph contradict a bit each other, which was the sole reason for my clarification. I am not stating you as wrong or anything; I was just augmenting, so other readers don't get the wrong impression and decouple Diffie-Hellman KE from public key cryptography.
P.S. The remaining issue is to make sure the server does not have to decrypt the IP for invalid connections etc (that is avoid DOS or leaking secrets as we are operating on not trusted ciphertext).
Earlier quoted context omitted.
Another thing that is ubiquitous today in airports, restaurants etc. is CCTV.
It's technically infeasible to locate someone via CCTV unless you have an accurate location already, for precisely this reason - there's a massive surfeit of data to search through, and current facial-recognition software is incapable of the task.
Earlier quoted context omitted.
In our thought-experiment world where each address has a public key that can be used to encrypt the payload data destined for it, the public key of the source can also be used to sign the data, ensuring the sender address isn't spoofed.
What validates that - the destination or intermediate devices? Spoofing is often just a means for volumetric DDoS attacks - if the destination is responsible for validate sources then we’re no better off there.
If the third party amplifiers in this scenario can validate that the traffic is spoofed, it cuts out amplification attacks.
Earlier quoted context omitted.
I don't dispute that it's difficult. But expensive? How so?
Any decent VPN service has a monthly cost. That isn't trivial for everyone.
The hacker was exposed because of poor OPSEC (due to tracking of his IP address). > Rigmaiden had received boxes and boxes of criminal discovery that would help him understand how the government planned to prosecute its case. In the penultimate box, he saw the word “stingray” in a set of notes. The authorities were exposed because of poor OPSEC as well. They weren't supposed to ever mention “stingray”.
All secrets eventually leak. It's a question of time. Not even state actors with unlimited resources can prevent secrets from leaking. So this wasn't bad operational security by authorities. It was a fundamentally flawed operation. Security through obscurity has limited and unpredictable usefulness. Good OPSEC can delay a leak, maybe. But OPSEC is still much harder for defenders than attackers. The article doesn't me…