Quote from: yAmAdA on July 28, 2014, 02:21:57 PM

Quote from: AnonyMint on July 28, 2014, 02:03:02 PM

Quote from: yAmAdA on July 28, 2014, 01:40:25 PM

Quote from: AnonyMint on July 28, 2014, 04:22:57 AM

I assume you mean relay nodes sending out dummy packets at random intervals, so latency doesn't increase for legitimate traffic (as long as relay nodes can handle the additional bandwidth).

I have been thinking about establishing fixed capacity channels between sets of nodes instead. The negotiated capacity is filled completely at all times, either with padding or real data. Because channels are encrypted, an attacker cannot differentiate between them.

The user's packet has to be in the same form as it entered the network when it leaves the network going the miner. Afaics, your proposed cover channels accomplish exactly nothing.

If your threat model includes the attacker looking at clear traffic on both sides, you have lost anyway, because the attacker can already read the transactions senders send and know who the senders are. Otherwise, the attacker cannot tell the way the packet looked when the sender sent it,

Correct (I had momentarily forgotten the logic of my original post to which you replied), the onion routing encryption layers are peeled off, thus the no knows the unencrypted data the sender sent until it arrives at the last node in the network which doesn't forward it.

However, this doesn't stop the adversary from looking at unencrypted data the miner is receiving, thus determining which data was cover (dummy) traffic.

Yet the spender could encrypt data for the miner, so only if the miner was compromised would your idea fail. The uncompromised miner would discard dummy packets and no one would know which they are.

Which is another reason we don't want mining to be centralized because it is more likely the fewer mining pools will be compromised.

But I don't see how cover channels can even work as you describe them? Where does the constant flow originate in onion routing?

Quote from: yAmAdA on July 28, 2014, 02:21:57 PM

Please understand that this proposal is intended to counteract opaque timing attacks only, not sybil attacks.

Why do you mention that? Even if you Sybil attacked the entry node, you wouldn't know what the destination packet looks like due to the onion routing.

Quote from: yAmAdA on July 28, 2014, 02:21:57 PM

Quote from: AnonyMint on July 28, 2014, 02:03:02 PM

Quote from: yAmAdA on July 28, 2014, 01:40:25 PM

Sybil attacks are very hard to defend against...Despite all, in 2012 the NSA was still obstructed in some degree by even Tor use. The least we can do is make it a bit harder for them.

A Sybil attack doesn't mean you succeed 100% of the time, as you don't have 100% of the relay nodes.

I want anonymity by needle-in-haystack, not anonymity by pair of dice.

Apparently nobody knows what percentage level of relay nodes the NSA controls on Tor (or I2P).

I entreat you to stop mentioning Tor. It is a different system than I2P, which is being implemented.

It is still a haystack, just of different size. It is still better than nothing at all. A hypothetical attacker with infinite budget cannot be defeated. We can model an attacker with specific capabilities and attempt to design system which defeats the attacker with a given probability. We do not actually disagree on this?

My point is that 10-20% of the relay nodes Sybil attacked is not needle-in-the-haystack odds, more like the odds of flipping a dice or pair of them.