5 ms·

One not-perfect trick: Stop retaining sensitive information. There is nothing in law that forces you to do retain things like IP addresses. https://www.eff.org

One not-perfect trick: Stop retaining sensitive information. There is nothing in law that forces you to do retain things like IP addresses. https://www.eff.org/issues/mandatory-data-retention/us https://www.eff.org/issues/mandatory-data-retention/us Then they can harass you for data all the time with illegal shit "court" orders and you can give them garbage and they can do nothing about it. This is the best method I've seen for dealing with this problem on a budget. Unfortunately the tradeoff is losing a lot of not-especially-effective tools for dealing with spammers and the like.

strathmeyer 10y ago
You may want to learn about how Lavabit was shutdown.
- function_seven 10y ago
  Lavabit's shutdown revealed the flaw in its premise. That encryption-at-rest was good enough for email security (while using a single TLS key for all in-flight data). Turns out it's not. Only end-to-end encryption—with keys only held by the end-users—can provide that. As despicable as FBI's actions in that case may be, they did the public a service by showing Lavabit's security proposition to be less than what users may have assumed. EDIT: Nothing I wrote above detracts from your point, though. Re-enforces it, in fact. Lavabit held little or no data, which caused the FBI to escalate to the nuclear give-us-your-master-key option.
abraae 10y ago
As far as IP address goes, you could store a cryptographic hash of the IP, rather than the IP itself. That would prevent you from, say, identifying entire subnets used by spammers, but would be better than nothing. You'd just need to do the hashing with some kind of tamperproof keystore that exploded when the FBI fiddled with it.
- woodman 10y ago
  This wouldn't work without some really bizarre implementation that would make it less of a hash and more of a cipher. The range of potential values is too small and highly structured, generating a rainbow table would be braindead simple. > ...tamperproof keystore that exploded... So not one way hashes then?
  - abraae 10y ago
    Ha ha, excellent point until we have ipv6. Less late nights for me.
    - kyledrake 10y ago
      That's a really interesting point actually. A hash of IPv6 would essentially be technically infeasible to brute force if fed through something like scrypt. But it wouldn't be exactly 128 bit random, since they could do a search based on the addresses allocated. I'd need to know the size of that potential pool to know how hard that would be, but if it's already in the dozens of billions, it's pretty difficult.
  - kyledrake 10y ago
    Generating a salt and tossing it into scrypt would break any rainbow table attempts, but it's still only 4,294,967,296 or so addresses for v4. It's pretty hard for a small government to do it, but I wouldn't put it past the NSA. This is how we've implemented IP address retention at Neocities, BTW: https://github.com/neocities/neocities/commit/4983a9b24eac00b8d8bfd300a18cdcee0152a271 https://github.com/neocities/neocities/commit/4983a9b24eac00... Step two is to throw them away after x amount of time. It's not perfect, but there you go. The best way is still to throw them away from the beginning, but we do need them for spammers and the like.
    - woodman 10y ago
      Subtract 588 million reserved IPs, as well as 2 from each subnet (0 and 255). There are also a lot of blocks that are publicly routable but see no use on the internet. If I were to build a rainbow table, I'd start with blocks assigned to ISPs, then throw in the results of publicly available distributed internet surveys, only then would I start the algorithmic address generation. Same story for IPv6. I really don't think it is a state actor level problem, but if it is it won't be for long.
- deleted 10y ago
  [deleted]
_delirium 10y ago
Relevant: Bruce Schneier's "Data is a toxic asset", https://www.schneier.com/blog/archives/2016/03/data_is_a_toxic.html https://www.schneier.com/blog/archives/2016/03/data_is_a_tox...

strathmeyer 10y ago

You may want to learn about how Lavabit was shutdown.

function_seven 10y ago
Lavabit's shutdown revealed the flaw in its premise. That encryption-at-rest was good enough for email security (while using a single TLS key for all in-flight data). Turns out it's not. Only end-to-end encryption—with keys only held by the end-users—can provide that. As despicable as FBI's actions in that case may be, they did the public a service by showing Lavabit's security proposition to be less than what users may have assumed. EDIT: Nothing I wrote above detracts from your point, though. Re-enforces it, in fact. Lavabit held little or no data, which caused the FBI to escalate to the nuclear give-us-your-master-key option.

abraae 10y ago

As far as IP address goes, you could store a cryptographic hash of the IP, rather than the IP itself. That would prevent you from, say, identifying entire subnets used by spammers, but would be better than nothing. You'd just need to do the hashing with some kind of tamperproof keystore that exploded when the FBI fiddled with it.

woodman 10y ago
This wouldn't work without some really bizarre implementation that would make it less of a hash and more of a cipher. The range of potential values is too small and highly structured, generating a rainbow table would be braindead simple. > ...tamperproof keystore that exploded... So not one way hashes then?
- abraae 10y ago
  Ha ha, excellent point until we have ipv6. Less late nights for me.
  - kyledrake 10y ago
    That's a really interesting point actually. A hash of IPv6 would essentially be technically infeasible to brute force if fed through something like scrypt. But it wouldn't be exactly 128 bit random, since they could do a search based on the addresses allocated. I'd need to know the size of that potential pool to know how hard that would be, but if it's already in the dozens of billions, it's pretty difficult.
- kyledrake 10y ago
  Generating a salt and tossing it into scrypt would break any rainbow table attempts, but it's still only 4,294,967,296 or so addresses for v4. It's pretty hard for a small government to do it, but I wouldn't put it past the NSA. This is how we've implemented IP address retention at Neocities, BTW: https://github.com/neocities/neocities/commit/4983a9b24eac00b8d8bfd300a18cdcee0152a271 https://github.com/neocities/neocities/commit/4983a9b24eac00... Step two is to throw them away after x amount of time. It's not perfect, but there you go. The best way is still to throw them away from the beginning, but we do need them for spammers and the like.
  - woodman 10y ago
    Subtract 588 million reserved IPs, as well as 2 from each subnet (0 and 255). There are also a lot of blocks that are publicly routable but see no use on the internet. If I were to build a rainbow table, I'd start with blocks assigned to ISPs, then throw in the results of publicly available distributed internet surveys, only then would I start the algorithmic address generation. Same story for IPv6. I really don't think it is a state actor level problem, but if it is it won't be for long.
deleted 10y ago
[deleted]

_delirium 10y ago

Relevant: Bruce Schneier's "Data is a toxic asset", https://www.schneier.com/blog/archives/2016/03/data_is_a_toxic.html https://www.schneier.com/blog/archives/2016/03/data_is_a_tox...