[Napshare-developer]Is it safe to jump back into the MUTE Network "pool"?

[Nate <fi...@fa...>]

I hope I can explain a little clearer how the new GMT time stamp thing
works to protect privacy.

The two posted attack scenarios created two problems:

1. How to prevent the attacks.
2. How to do #1 above and still keep broadcast messages from living
forever.

Every message sent on the network has a unique Message ID and a Message
Counter attached to it. It looks something like this:

57EE60E1417F6048588A5B9874F0E5BDAB519AC0_67752657

Message ID (40 characters), then "_" (underscore character) then the
Message Counter.

The Message Counter was a number that we added +1 to when we sent a new
message out to the network. It slowly increased as new messages were
added to the network.

The Message Counter on new versions is now simply a Time Stamp based on
GMT, the number of seconds since midnight Jan 1, 1970 (also known as
UTC). We simply "stamp" new messages with the time.

If a message is older than 10 seconds, it's ignored, no action is taken.
This prevents messages from living forever. In the actual code, we allow
for a little slop between clocks, since real world clocks drift a little
and get out of sync. Broadcast messages do not live more than 10
seconds.

If a message is "fresh", then we process it internally, respond if
needed and pass it on to all the other connected nodes.

This protects the privacy of the user because we either react to the
message and also pass it on to other nodes that may also react, or we
ignore the message and it goes no further.

An attacker connecting twice to a node (either of the previously posted
attacks) only sees the message being passed on or not, and possibly a
number of reply messages that could have come from other connected nodes
further down the line.

Knowing the value or modifying the "UC" / TTL counter doesn't provide
any information because we ignore that too.

An attacker can't know what your clock is set to exactly, so there is no
way to know if a message originated at your node or was passed *through*
your node. (typical internet packet delays and routing also help with
this)

An attacker can modify the Time Stamp of it's sent messages, but the
receiving node will also pass that message to other nodes (if it isn't
old), so any replies may have come *through* the receiving node.

10 seconds is enough time to allow for clock "slop" and also create a
good number of results. Reply messages and other messages are allowed to
live a little longer because they are not broadcast messages and have
little chance of living forever.

If a source is more than 10 seconds away, the download travel time will
most likely be long also. It would be better to use a different path for
a download in that case. The network is very dynamic, so at any time a
re-search for a file source could show less delay.

This does *not* protect the users of old versions that are still out
there, you need to upgrade in order to be protected with this method.

It is possible to tell what version you are running by the way your node
handles messages.

An attacker *can* easily tell if you have upgraded or not.


Other details:

The time clock is sync'ed to GMT using randomly picked outside sources
selected from a large list of URL's. Four servers in a row must have the
same time within a few seconds in order for it to be a valid time.

The time clock is re-sync'ed every 12 hours, and if this fails, every
hour until a proper time is set.

I have also given a lot of thought to the search originating node
"FORWARD" flag used to protect the senders privacy and couldn't come up
with anything that would let an attacker identify the originating party.