Please support this I2P proposal on Stack Exchange:
https://area51.stackexchange.com/proposals/99297/i2p
Although the proposal was posted by a Monero developer it is meant to benefit the entire I2P community, not Monero specifically (Monero has its own Stack Exchange proposal already https://area51.stackexchange.com/proposals/98617/monero)
If you are interested in the C++ I2P router project happening now you can track its progress here:
https://github.com/monero-project/kovri
Topic: Time to switch to i2P? (Read 4240 times)
If you have a node that is receiving the data then you know what is fake (because you disregard it) and what is real (because you continue to relay it)
Good thing we were talking about protecting against traffic analysis by a passive third party attacker instead of a peer.https://wiki.freenetproject.org/Papers#Small-world_networks
If you have a node that is receiving the data then you know what is fake (because you disregard it) and what is real (because you continue to relay it)
Good thing we were talking about protecting against traffic analysis by a passive third party attacker instead of a peer.https://wiki.freenetproject.org/Papers#Small-world_networks
If you have a node that is receiving the data then you know what is fake (because you disregard it) and what is real (because you continue to relay it)
Good thing we were talking about protecting against traffic analysis by a passive third party attacker instead of a peer.If you have a node that is receiving the data then you know what is fake (because you disregard it) and what is real (because you continue to relay it)
Good thing we were talking about protecting against traffic analysis by a passive third party attacker instead of a peer. 
Fake data is just some real data padded and then encrypted. There is no way to distinguish the two apart without the decryption keys. The fake data is simply generated by the sender, and then discarded on the receiving end.
This reminds me of mp3's. Music used to be encoded as constant bit rate (CBR), now there are more variable bit rate (VBR) files. We are simply going backwards with the technology.
If you have a node that is receiving the data then you know what is fake (because you disregard it) and what is real (because you continue to relay it)This reminds me of mp3's. Music used to be encoded as constant bit rate (CBR), now there are more variable bit rate (VBR) files. We are simply going backwards with the technology.
Excellent point. Unfortunately.
Fake data is just some real data padded and then encrypted. There is no way to distinguish the two apart without the decryption keys. The fake data is simply generated by the sender, and then discarded on the receiving end.
This reminds me of mp3's. Music used to be encoded as constant bit rate (CBR), now there are more variable bit rate (VBR) files. We are simply going backwards with the technology.
If you have a node that is receiving the data then you know what is fake (because you disregard it) and what is real (because you continue to relay it) This reminds me of mp3's. Music used to be encoded as constant bit rate (CBR), now there are more variable bit rate (VBR) files. We are simply going backwards with the technology.
This reminds me of mp3's. Music used to be encoded as constant bit rate (CBR), now there are more variable bit rate (VBR) files. We are simply going backwards with the technology.
Exactly. I hesitate to make a statement with two absolutes, but I'll go out on a limb: the concept is literally the opposite of compression. A constant stream would even be resistant to the active attack Theymos described. In the context of TOR, imagine all nodes doing their best to keep a constant 1Mbps of data flowing between peers in both directions. Then imagine big brother decides to modulate your home internet connection in some way in hopes of tracing and/or confirming an effect somewhere else. The constant flow of data would cause the modulation to be 100% damped upon reaching the first node, resulting in a downstream signal to noise ratio of zero.
Fake data is just some real data padded and then encrypted. There is no way to distinguish the two apart without the decryption keys. The fake data is simply generated by the sender, and then discarded on the receiving end.
This reminds me of mp3's. Music used to be encoded as constant bit rate (CBR), now there are more variable bit rate (VBR) files. We are simply going backwards with the technology.
This reminds me of mp3's. Music used to be encoded as constant bit rate (CBR), now there are more variable bit rate (VBR) files. We are simply going backwards with the technology.
In order to use i2p you have to relay traffic also, making correlation and timing attacks harder.
I2p also doesn't use a static 3-hop one-way path for it's traffic changing every 10 minutes, in and outbound paths in i2p are different and randomized in hop length with a set min and max. Besides this it also uses multiple paths to the destination, not just one.
If you have enough nodes then you can still potentially execute a timing attack, although the randomized number of hops and the additional traffic will make such attacks much more difficult but still not impossible. I2p also doesn't use a static 3-hop one-way path for it's traffic changing every 10 minutes, in and outbound paths in i2p are different and randomized in hop length with a set min and max. Besides this it also uses multiple paths to the destination, not just one.
maidsafe 
While think kind of countermeasure could potentially work, I would think that an adversary would eventually be able to figure out what is fake data and what is "real" traffic and be able to strip out the fake data from their analysis. IMO the only real way to prevent timing attacks is to have a large amount of "real" traffic flowing to your site on a regular basis
If the cryptography is properly implemented, "real data" should appear identical to "junk data". The trick would be merging and alternating between them in a seamless way.While think kind of countermeasure could potentially work, I would think that an adversary would eventually be able to figure out what is fake data and what is "real" traffic and be able to strip out the fake data from their analysis. IMO the only real way to prevent timing attacks is to have a large amount of "real" traffic flowing to your site on a regular basis
If the cryptography is properly implemented, "real data" should appear identical to "junk data". The trick would be merging and alternating between them in a seamless way. The main problem with I2P and Tor is that they only try to protect you against mostly-passive attackers who have absolutely no idea of where you might actually be on the Internet. The Tor threat model says (and this is also true of I2P):
But attackers looking for the real IP of a target hidden service can significantly narrow the set of possible targets by enumerating all active Tor/I2P users (using widespread traffic analysis or by having a lot of nodes on the network), and then they can further narrow it by doing intersection attacks. Once they've narrowed it down to a few hundred possibilities, they can try timing attacks against each one to get solid proof that they're the target.
(I wonder if the hidden services that were not taken down in the recent bust have anything in common. Are they in a particular country that's unfriendly to NSA demands? Do they use a fixed set of trusted entry guards? Probably we won't find out, unfortunately.)
I just don't think that low-latency client<->server networks can be secure. What we need are distributed data stores like Freenet so that the originator/owner of content doesn't need to always be online and moreover has plausible deniability even if they are under active surveillance. However, I really doubt that any existing anonymous data store could actually stand up to targeted traffic analysis of the content originator. Freenet seems to be put together in an especially haphazard way, without much theoretical basis for its claimed anonymity.
I like a lot of what I've read about GNUnet. I think that a good path forward for anonymous networks would be:
- Make the GNUnet software user-friendly.
- Create message board and Web functionality (like FProxy) on top of GNUnet.
- Make GNUnet work over I2P.
- Increase the popularity of GNUnet+I2P so that attackers can't just do traffic analysis of every single user.
There's an solution to traffic pattern attacks - it's just really expensive.Quote
By observing both ends, passive attackers can confirm a suspicion that Alice is talking to Bob if the timing and volume patterns of the traffic on the connection are distinct enough; active attackers can induce timing signatures on the traffic to force distinct patterns. Rather than focusing on these traffic confirmation attacks, we aim to prevent traffic analysis attacks, where the adversary uses traffic patterns to learn which points in the network he should attack.
But attackers looking for the real IP of a target hidden service can significantly narrow the set of possible targets by enumerating all active Tor/I2P users (using widespread traffic analysis or by having a lot of nodes on the network), and then they can further narrow it by doing intersection attacks. Once they've narrowed it down to a few hundred possibilities, they can try timing attacks against each one to get solid proof that they're the target.
(I wonder if the hidden services that were not taken down in the recent bust have anything in common. Are they in a particular country that's unfriendly to NSA demands? Do they use a fixed set of trusted entry guards? Probably we won't find out, unfortunately.)
I just don't think that low-latency client<->server networks can be secure. What we need are distributed data stores like Freenet so that the originator/owner of content doesn't need to always be online and moreover has plausible deniability even if they are under active surveillance. However, I really doubt that any existing anonymous data store could actually stand up to targeted traffic analysis of the content originator. Freenet seems to be put together in an especially haphazard way, without much theoretical basis for its claimed anonymity.
I like a lot of what I've read about GNUnet. I think that a good path forward for anonymous networks would be:
- Make the GNUnet software user-friendly.
- Create message board and Web functionality (like FProxy) on top of GNUnet.
- Make GNUnet work over I2P.
- Increase the popularity of GNUnet+I2P so that attackers can't just do traffic analysis of every single user.
They way you solve traffic pattern analysis is to make your protocol consume a constant amount of bandwidth all the time, regardless of whether anything is actually going on or not.
I've been waiting to see 'constant bandwidth' solutions for quite some time. It would help the anonymity networks. The technique could also be applied to something like VoIP. It would consume lots of bandwidth but not necessarily and unreasonable or unworkable amount. Further, 24/7 availability could be given up in favor of some window of time, maybe one hour per day, where the constant bandwidth would be applied. It would be up to the user to take advantage of that time window. Command and control instructions, and text, take up very little bandwidth, so at least those kind of activities should only take a small bit of fake data to effectively pad the timing.
The main problem with I2P and Tor is that they only try to protect you against mostly-passive attackers who have absolutely no idea of where you might actually be on the Internet. The Tor threat model says (and this is also true of I2P):
But attackers looking for the real IP of a target hidden service can significantly narrow the set of possible targets by enumerating all active Tor/I2P users (using widespread traffic analysis or by having a lot of nodes on the network), and then they can further narrow it by doing intersection attacks. Once they've narrowed it down to a few hundred possibilities, they can try timing attacks against each one to get solid proof that they're the target.
(I wonder if the hidden services that were not taken down in the recent bust have anything in common. Are they in a particular country that's unfriendly to NSA demands? Do they use a fixed set of trusted entry guards? Probably we won't find out, unfortunately.)
I just don't think that low-latency client<->server networks can be secure. What we need are distributed data stores like Freenet so that the originator/owner of content doesn't need to always be online and moreover has plausible deniability even if they are under active surveillance. However, I really doubt that any existing anonymous data store could actually stand up to targeted traffic analysis of the content originator. Freenet seems to be put together in an especially haphazard way, without much theoretical basis for its claimed anonymity.
I like a lot of what I've read about GNUnet. I think that a good path forward for anonymous networks would be:
- Make the GNUnet software user-friendly.
- Create message board and Web functionality (like FProxy) on top of GNUnet.
- Make GNUnet work over I2P.
- Increase the popularity of GNUnet+I2P so that attackers can't just do traffic analysis of every single user.
There's an solution to traffic pattern attacks - it's just really expensive.Quote
By observing both ends, passive attackers can confirm a suspicion that Alice is talking to Bob if the timing and volume patterns of the traffic on the connection are distinct enough; active attackers can induce timing signatures on the traffic to force distinct patterns. Rather than focusing on these traffic confirmation attacks, we aim to prevent traffic analysis attacks, where the adversary uses traffic patterns to learn which points in the network he should attack.
But attackers looking for the real IP of a target hidden service can significantly narrow the set of possible targets by enumerating all active Tor/I2P users (using widespread traffic analysis or by having a lot of nodes on the network), and then they can further narrow it by doing intersection attacks. Once they've narrowed it down to a few hundred possibilities, they can try timing attacks against each one to get solid proof that they're the target.
(I wonder if the hidden services that were not taken down in the recent bust have anything in common. Are they in a particular country that's unfriendly to NSA demands? Do they use a fixed set of trusted entry guards? Probably we won't find out, unfortunately.)
I just don't think that low-latency client<->server networks can be secure. What we need are distributed data stores like Freenet so that the originator/owner of content doesn't need to always be online and moreover has plausible deniability even if they are under active surveillance. However, I really doubt that any existing anonymous data store could actually stand up to targeted traffic analysis of the content originator. Freenet seems to be put together in an especially haphazard way, without much theoretical basis for its claimed anonymity.
I like a lot of what I've read about GNUnet. I think that a good path forward for anonymous networks would be:
- Make the GNUnet software user-friendly.
- Create message board and Web functionality (like FProxy) on top of GNUnet.
- Make GNUnet work over I2P.
- Increase the popularity of GNUnet+I2P so that attackers can't just do traffic analysis of every single user.
They way you solve traffic pattern analysis is to make your protocol consume a constant amount of bandwidth all the time, regardless of whether anything is actually going on or not.
I've been waiting to see 'constant bandwidth' solutions for quite some time. It would help the anonymity networks. The technique could also be applied to something like VoIP. It would consume lots of bandwidth but not necessarily and unreasonable or unworkable amount. Further, 24/7 availability could be given up in favor of some window of time, maybe one hour per day, where the constant bandwidth would be applied. It would be up to the user to take advantage of that time window. Command and control instructions, and text, take up very little bandwidth, so at least those kind of activities should only take a small bit of fake data to effectively pad the timing.
In order to use i2p you have to relay traffic also, making correlation and timing attacks harder.
I2p also doesn't use a static 3-hop one-way path for it's traffic changing every 10 minutes, in and outbound paths in i2p are different and randomized in hop length with a set min and max. Besides this it also uses multiple paths to the destination, not just one.
I think this makes using i2P more risky for the "average" user who is not intending to use it for illegal purposes. The "average" user would risk that traffic would exit from their node that is doing illegal things and they would not have the cover of running a tor exit node that tor exit nodes have I2p also doesn't use a static 3-hop one-way path for it's traffic changing every 10 minutes, in and outbound paths in i2p are different and randomized in hop length with a set min and max. Besides this it also uses multiple paths to the destination, not just one.
I think it is time. I2P is objectively better and the adage is that the slower the system the more secure.
In order to use i2p you have to relay traffic also, making correlation and timing attacks harder.
I2p also doesn't use a static 3-hop one-way path for it's traffic changing every 10 minutes, in and outbound paths in i2p are different and randomized in hop length with a set min and max. Besides this it also uses multiple paths to the destination, not just one.
I2p also doesn't use a static 3-hop one-way path for it's traffic changing every 10 minutes, in and outbound paths in i2p are different and randomized in hop length with a set min and max. Besides this it also uses multiple paths to the destination, not just one.
Someone make a simple "How-To" if you ever want to do something similar. That's not illegal is it? (I mean, information that is not an illegal number.) Like, don't host in Bulgaria or something.
From what I was reading earlier today, multiple sites which were taken down were using the same Bulgarian host.
Link, please?
Link to reddit thread in which translation of article is posted.
https://www.reddit.com/r/DarkNetMarkets/comments/2lm01y/129_onions_seized_on_bulgarian_hosting_company/
Not all of them were drug sites, but many of them were offering illegal services.
This is also...interesting.
https://blog.torservers.net/20141109/three-servers-offline-likely-seized.html
Y'all might find this interesting, too. Doxbin got taken down and this is from the person who operated it.
https://lists.torproject.org/pipermail/tor-dev/2014-November/007731.html
Jump to: