Beeds - Revision history

Adamcolton: /* Routing Groups */

2016-05-04T16:14:15Z

Routing Groups

← Older revision		Revision as of 16:14, 4 May 2016
Line 68:		Line 68:

	== Routing Groups ==		== Routing Groups ==
	Just an idea I'm playing around with. Users can form routing groups. Within a routing group, every user has a connection map. This allows efficient design when constructing Beed routes (I can choose A → B → C so that A is already connected to B and B is already connected to C). We can also propagate disconnect information*.		Just an idea I'm playing around with. Users can form routing groups. Within a routing group, every user has a connection map. This allows efficient design when constructing Beed routes (I can choose A → B → C so that A is already connected to B and B is already connected to C). We can also propagate disconnect information* which allows for structures like Braids to operate more efficiently.

	It also allows for reputation management. A group can reject a user without sufficient reputation. This allows for collectives of good actors to have access to reliable routing.		It also allows for reputation management. A group can reject a user without sufficient reputation. This allows for collectives of good actors to have access to reliable routing.

Adamcolton: /* Routing Groups */

2016-05-04T16:13:51Z

Routing Groups

← Older revision		Revision as of 16:13, 4 May 2016
Line 68:		Line 68:

	== Routing Groups ==		== Routing Groups ==
	Just an idea I'm playing around with. Users can form routing groups. Within a routing group, every user has a connection map. This allows efficient design when constructing Beed routes (I can choose A → B → C so that A is already connected to B and B is already connected to C). It also allows for reputation management. A group can reject a user without sufficient reputation. This allows for collectives of good actors to have access to reliable routing.		Just an idea I'm playing around with. Users can form routing groups. Within a routing group, every user has a connection map. This allows efficient design when constructing Beed routes (I can choose A → B → C so that A is already connected to B and B is already connected to C). We can also propagate disconnect information*.

			It also allows for reputation management. A group can reject a user without sufficient reputation. This allows for collectives of good actors to have access to reliable routing.

			(*) I just realized that disconnect information could be a major de-anonymizing datum. If I'm connected to a user anonymously and they disappear, I can narrow that user down to anyone who went offline in that time period. That may not be a huge problem though - users that are serious about security should use a reliable connection and cease all activity a few minutes before disconnecting.

	[[Category:Waxnet]]		[[Category:Waxnet]]

Adamcolton at 19:28, 3 March 2016

2016-03-03T19:28:14Z

← Older revision		Revision as of 19:28, 3 March 2016
Line 67:		Line 67:
	From the [https://en.wikipedia.org/wiki/Dining_cryptographers_problem Dining Cryptogrophers] and [http://www.cs.uu.nl/docs/vakken/b3sec/Proj12/Dining.pdf this]. But I'm not sure, and the more I think about it, the less I think it works for this.		From the [https://en.wikipedia.org/wiki/Dining_cryptographers_problem Dining Cryptogrophers] and [http://www.cs.uu.nl/docs/vakken/b3sec/Proj12/Dining.pdf this]. But I'm not sure, and the more I think about it, the less I think it works for this.

			== Routing Groups ==
			Just an idea I'm playing around with. Users can form routing groups. Within a routing group, every user has a connection map. This allows efficient design when constructing Beed routes (I can choose A → B → C so that A is already connected to B and B is already connected to C). It also allows for reputation management. A group can reject a user without sufficient reputation. This allows for collectives of good actors to have access to reliable routing.

	[[Category:Waxnet]]		[[Category:Waxnet]]

Adamcolton at 21:56, 1 March 2016

2016-03-01T21:56:44Z

← Older revision		Revision as of 21:56, 1 March 2016
Line 1:		Line 1:
	Beeds is the onion routing service in Waxnet.		Beeds is the onion routing service in Waxnet.

			== Beed Routing ==
			Unlike "onion routing" "beed routing" is a series of beads (mini-onions).

			A beed-chain is either a "sending beeds" or "receiving beeds". For "sending" the router pops a bead off, decrypts it. If that works, it removes a layer of encryption on every other bead and the message, appends a fake bead on the end and passes it along. For "receiving", it will add a layer of encryption to the message.

	== Onion Routing ==		== Onion Routing ==

Adamcolton: Created page with "Beeds is the onion routing service in Waxnet. == Onion Routing == Requirements # As long as one router is "honest", a message cannot be tracked (correlate this packet to any ..."

2016-03-01T21:45:51Z

Created page with "Beeds is the onion routing service in Waxnet. == Onion Routing == Requirements # As long as one router is "honest", a message cannot be tracked (correlate this packet to any ..."

New page

Beeds is the onion routing service in Waxnet.

== Onion Routing ==
Requirements
# As long as one router is "honest", a message cannot be tracked (correlate this packet to any other packet)
# A sender and receiver can communicate with out knowing their IPs
# There is a priority placed on speed and low-overhead

More on 3; An efficient system will attract more users, this creates more legitimate traffic, more legitimate traffic makes it harder to corrupt and harder to track individual packets. So sacrificing bits of entropy for more speed or less overhead may be acceptable. In particular, users are drafted as routers. If a router incurs large network overhead, this will be an unacceptable proposition for most users. The rule of thumb here is to match (or beat) current internet standards; ie if we consider network overhead plus advertisement and tracking overhead in ratio to "real" content, that is how much crypto and routing overhead users will tolerate.

The research I did on cyclic keys seems to have worked. Not sure yet if it's secure. But it allows for packet switched onion routing. The message goes through a transformation at each step.

=== Overhead ===
* Onion : 73 bytes (empiric)
* Pub: 32 bytes
* First ID: 10 bytes
* Key: 10 bytes

So a full composite route is 32+10+10+6*73, 490 bytes of overhead. Not terrible.

=== Replay ===
A receiver route can be used multiple times. This leaks data for correlation. This is mitigated by a "MaxUse" parameter, but setting the parameter lower also reduces the likelihood of getting a useful response.

=== Dual Redundancy ===
At each layer of onion routing, we choose two mirror nodes. S sends to the first pair. Both nodes forward to the next set of pairs. Or, we can include an ID for each layer, only forward the ID and each node in the next layer, if the next layer doesn't have the onion yet, then forward. The ID could be derived from the message, say the hash of the first 1K.

This allows any one node in a node pair to fail.

L: length of route (number of onion routers)
B: length of message in blocks

Without Redundancy (L+1)*B
Without Tags: (4L)*B
With Tags: (2L + 1)*B + (6L+1) [message + tags]

The works out to with tags being more efficient at
(6L + 1) / (2L + 1)
But we can effectively ignore both +1, which gives us equal efficiency when B=3 for any L
And so we say use tags when B>=4

I need to do some analysis of how much this reduces the security. It would still be true that we would only need a single pair of nodes to be honest.

=== Thwarting Traffic Analysis ===
Ultimately, it is not possible to have real-time communication without exposing a risk of traffic analysis.

==== Priority ====
Each onion could have a priority tag. Onion routers can hold onto messages with lower priority. Then when a message with high priority comes in, all the messages are released at once. This means high priority messages would be subject to traffic analysis.

==== Chaff ====
Routers can send fake message to provide cover for real messages. This could also be tailored to the level of network traffic. That way, when the network is busy, we don't need much chaff to provide adequate cover, and this is when the chaff would slow down the network. When the network is not busy, we can add just enough chaff to provide cover.

==== Garlic Routing ====
We can use a deterministic algorithm to choose a small number of nodes (probably 9) periodically (~1/second), arranged in a feed-forward network. Messages will be bundled into largish groups and passed between these garlic routers, providing cover. This is also a good place to use chaff, because a little here provides a lot of cover.

This is sort of a middle ground. Speed is guaranteed to be no slower than roughly one period, but it is also unlikely to be faster, or anywhere near real time.

The one catch to garlic routing is that it would send a lot of data through a few nodes. That might be ok. If the total garlic traffic through any node is relatively small. We would need 9 routers ever second, so 777,600 routers per Q per day. If the average Q has 1000 P connected at any time, and most users are on for ~10hrs a day, that would be about 2,400 unique users per day. So each node would be a relay about 324 times a day.

The other option is for nodes to volunteer. But that makes me nervous because it opens up the possibility of conspiracy.

==== DC Nets ====
From the [https://en.wikipedia.org/wiki/Dining_cryptographers_problem Dining Cryptogrophers] and [http://www.cs.uu.nl/docs/vakken/b3sec/Proj12/Dining.pdf this]. But I'm not sure, and the more I think about it, the less I think it works for this.

[[Category:Waxnet]]