owned this note
owned this note
Published
Linked with GitHub
# Asymmetric Stratified Synchronous DC Network - Dark Rocket Pool
###### tags: `Tag(HashCloak - Chloethedev Personal Notes)`
Author(s): Chloethedev.eth
Paper(s): Papers Referenced from:
1. Blinder – MPC Based Scalable and Robust Anonymous Committed Broadcast - 2020
* https://hackmd.io/lM3k6574RjiZX3gOIIHw3A?view
* https://eprint.iacr.org/2020/248.pdf
2. Group Formation for Asymmetric DC-nets - 2018**
* https://hackmd.io/H9hEPKorTE-aFBuk5OD2qw?view
* https://tuprints.ulb.tu-darmstadt.de/9143/7/thesis-final.pdf
3. PriFi: Low-Latency Anonymity for Organizational Networks
* https://hackmd.io/MQgU2UyCR8GFLuMd6V6TzA?view
* https://arxiv.org/pdf/1710.10237.pdf
4. ANONYMOUS PUBLISH-SUBSCRIBE OVERLAYS - 2016
* https://hackmd.io/BMGvOx0mRByO74n13VAH5g?view
* https://tuprints.ulb.tu-darmstadt.de/5473/9/2016-05-03%20ClassicThesis_2.pdf
5. Generic, Decentralized, Unstoppable Anonymity: The Phantom Protocol (Video & Whitepaper) **
* https://hackmd.io/bfijThaDSjWiSYnM44d5SQ?view
* http://www.magnusbrading.com/phantom/phantom-design-paper.pdf
### Table of Contents
[toc]
:::info
>Abstract: The goal of this paper is to formulate a general specification for how an "Asymmetric Stratified Synchronous DC Network" might work in a practical setting; to be useful for anonymous PoS P2P networks. The Anonymity Trilemma (https://freedom.cs.purdue.edu/projects/trilemma.html) makes it so that DC nets to not currently meet the low-latency requirements needed for these PoS networks; I suppose I will try and prove the trilemma wrong (Or maybe there is a better solution to the problem at hand)?
>
> With ETH2.0 beacon chain launch quickly approaching, an anonymous staking service will be needed. The two general directions of this service are one in which users already have the 32 ETH required to stake, and another where secret sharing is used to allow for users with less than the required 32 ETH to join together to validate on the network.
>
> With other current PoS chains (DPoS) delegation is involved. There is no clear way as of yet to add an anonymous application layer to these networks. Delegation is a built in mechanism.
>
> If not carefully designed, any anonymous PoS network will become the target of various forms of attacks so the goal is to create a secure and general specification that can be used on any PoS network to provide a way to validate privately.
>
> The network should be free, open, and community owned? Either way, the network should be designed for the future in mind (technological advancements, increased userbase, edge cases).
The design goals of the network are as follows:
1. Completely decentralized?
* Is some level of centralization needed for "Supernodes"?
2. Maximum resistance against all kinds of DoS attacks.
* Attackers/lazy nodes should not be able to stop the network.
* Attacks need a way to be noticed, mitigated, defended against.
3. Theoretically secure anonymization.
* Assume no peer can be trusted (byzantine fault tolerant).
4. Theoretically secure end-to-end transport encryption.
* TLS?
5. Maximum protection against identification of protocol usage through traffic analysis.
* It may be known that a user is validating, but how much information can be hidden?
* Is this Doesn't seem
6. Generic and well-abstracted design, compatible with all new and existing network enabled software.
* Anyone and everyone with the required stake, should have the ability to validate privately if they have the ability to validate publicly.
:::
## 1. Introduction
As Proof-of-Stake (PoS) becomes a viable alternative to Proof-of-Work (PoW) as an underlying consensus algorithm for Peer-to-Peer (P2P) decentralized networks, a wonderful opportunity has arisen to allow for an anonymous messaging network to be built to enhance the security and usability of p2p networks in general. While there is currently a lot of research being conducted surrounding the safety/security of PoS networks, there is not nearly as much emphysis on anonymity within these networks.
Allowing anonymous validators within a PoS network deffinitely poses many diffelicult and novel issues to P2P networking, but the benefits of providing an anonymous validating option to validators (stakers) seem to greatly outweigh the percieved costs.
### 1.1 Let's Break it Down
To abstract away some of the complexities, for those that may be reading this that do not come from background that provides much insight into why this is so wonderful, lets try and introduce these topics in another way:
- Nodes are simply computers, and messages are simply communication that can be sent from one computer to another.
Now that we have that out of the way, we simply want a network where every node is private, yet has the ability to communicate (send messages) with other nodes within the network.
This already poses quite a few issues, but let's not worry too much about those for now. Let's use sports to break this down even further (I have a Master's in Sport Psychology so bear with me):
Imagine you are a professional athlete (let's say a soccer player). You want to try out for a team, but you don't want everyone to know that you're thinking about leaving the team you are current signed to.
- There may be many reasons to keep this information private:
- Fans/teammates may lose trust in the athletes supposed allegance to the team. Could lead to lost revenue.
- The athlete inquestion may have a clause in their contract that prohibits interactions with other teams. Legal action may be taken against the athlete! So much for freedom of speech?
A situation such as theone above, and countless other scenarios that I am sure you could think of, would be a prime use case for an anonymous messaging system that would allow this athlete to contact a new team, privately, expressing interest in a potential transfer.
If we go even deeper into the example, we quickly find more issues with this correspondence:
- How does the team receiving the message know that the message is authentic?
- What if someone was trying to impersonate the athlete in question to see what they were worth!
- If the message is found to be authentic, how then does the team that received the message send a message back without linking themselves to the player sending the message?
- Psudonyms (fake names) are used for all nodes participating within the network.
- They change often to try and ensure message unlinkability.
- General idea is that even if a Global Attacker was observing all sent messages, they would only be able to link messages top sudonyms. The real identities of nodes is kept on-linked tothe message that was sent.
- Nodes can change their psudonym at any time.
- Psudonyms should also change without user interaction.
- For example, they could be re-computed each time a node changes groups.
When trying to have secure anonymous messaging, it is not as simple as it may seem. There are many potential exploits against anonymity that attackers of a network can use to try and reduce or eliminate the anonymity that is supposed to be provided by the network.
So, how do we secure against these exploits? By making sure to design a system, from the ground up, that follows the design principals outlined in the abstract of this paper.
### 1.2 So now what?
Now that we understand that anonymous messaging is a little more difficult that it may seem at first thought, who cares? Do professional athlete's really need to be able to communicate with 100% certainty and 100% anonymity with potential new employers?
- Probably not...
- Who DOES need messaging like this then?
- Journalists covering sensitive issues.
- Political whistle-blowers/activists.
- Legal Teams / Military / High-level Government all need to send private (encrypted) messages.
The weirdly beautify aspect of anonymity sets is that they become more effective (at hiding amongst) as they grow! The people that need theoretically provable anonymous messaging may not be numerous, but they would do best to somehow gather other users, who may not need the anonymity to such a degree, to still use the network.
Even with all of this, basically it boils down to alturism. Some users, who don't really need the anonymity that a system provides, need to take part and give up resources that they otherwise could have used for something else.
- Running a node is not free!
It seems like what we really need are some incentives!
### 1.3 Incentivising Anonymity Sets
Many of the issues arising from the security of DC nets stem from the issue that when an attacker was discovered (someone who was not following the rules of the network) they could be kicked out of the network, but that's about all.
- The malicious node could just re-join the anonymous network under a different (psudonym).
- The malicious node has not lost anything of value to deter it from attempting an attack again.
With a strong PoS network as a base layer, it seems intuitive that an anonymous messaging network could follow a similar set-up.
- Users of the anonymous messaging system could use their "stake" (lock-up assets into a network) in a network as a way to gain membership, and if they were found guilty of an offence, they would be slashed(they would lose some of their stake)!
- This provides an economic incentive for nodes to remain honest within a network.
- The slashed stake from dishonest/malicious nodes can be distributed to honest nodes within the network to further promote honesty within the network.
This increases the security of the DC-net (because now we can reasonably fight off attackers), but doesn't actually increase its anonymity. Again, one of the ways to increase the anonymity provided by a network is to increase the size of the anonymity set (yes, yes, overhead issues with > number of nodes in the network). What that really means is that the more users the network has, the greater the available anonymity.
- Intuitively this makes sense when thinking about hiding within a crowd. The larger the crowd, the easier it is to hide.
- Other factors may come into play as well.
- For example if it is a crowd of shorter children, and the person trying to hide is quite tall, the larger anonymity set (larger crowd) might actually not be that useful.
So, a large set of users is needed.
One that is:
- Uniform: Distinguishing characteristics, can be used by attackers to reduce anonymity set size and single out nodes/users.
- In the example above, height or age might be used to single out the one tall adult in the crowd.
- Mostly Honest: DC-nets require greater than $1- (1/3) \over n$ honest nodes within the network (> 33%).
This is where design goal #6 comes into play. Let's get everyone involved!
> Generic and well-abstracted design, compatible with all new and existing network enabled software.
>- Anyone and everyone with the required stake, should have the ability to validate privately if they have the ability to validate publicly.
### 1.4 | SSV & Pooled Staking
One of the main barriers to entry in a PoS system such as ETH2.0, is the staking requirement. 32 ETH is required to stake on the network (run a node that validates the state/transactions/etc.) and at the current price of ~$400 USD, that is an immediate halt to the process of joining the ETH2,0 network, never-mind the anonymous ADC-net overlay.
There is work currently being done by Consensys around Secret Shared Validators(SSV) which would allow users with less than the required 32 ETH to group together and stake.
- One potential avenue is that this would allow for the SSV group to enter their node into the anonymous staking network.
- Another avenue is to allow for any user to stake a certain amount of ETH in the anonymous overlay (let's say 1 ETH) which would then form its own nodes and group members.
- Since ETH2.0 Beacon chain does not allow for transfers of assets from account to account, this may pose issues.
- Are assets locked in to the SSV group?
- How do nodes that disconnect receive their payout?
- Ensure that nodes have a local hash of their rewards that they can distribute to themselves after ETH phase 1 (transfers allowed).
- This hash can be used as an IOU? Allow users to exit the system in exchange for transferring ownership of their IOU rewards.
However this gets done, it will lower the barriers to entry and allow for greater anonymity within the whatever anonymous validator network gets implemented for PoS networks in the future.
## 2. Background
There are many pieces to the puzzle that is low-latency anonymous messaging.
- Chaum mixnets/DC-nets
- SSLE
- Random walks
- Anonymity Trilemma
-
## 3. High Level Overview
**Greedy group formation and synchronous rounds**
Superstar nodes from top groups have a chance to help out struggling groups that can't seem to reach finality (disconnecting nodes/malicious nodes), nodes that aren't performing well get kicked from the group/team and lose some sort of reputation.
* This means superstar nodes have a chance to get paid twice if they can successfully aid a weaker group to completion.
* Also should increase the chance that all groups reach finality.
Main idea is that this would allow for hiding amongst a large set of nodes and staking on a network. Malicious nodes can be slashed and kicked from the group (or if it's a serious offence, the network). Epochs on eth2 seems long enough for the few second check. And the last Epoch before finality, maybe more stringent requirements would be needed before the payout is distributed for that round. Overall though, since there is no transfers in eth2 stage 0 it shouldn't matter and the actual rewards should be able to lag behind the actual beacon chain by a bit without too much UX issues.
> As for other networks, I would definitely have to look more into them to better understand how these ideas would work specifically there. The ideas above are meant to be able to be generalized for privately validating on any PoS network.
Potential group formation example:
> As for your ideas, are you taking into account the fact that in a p2p dc net, given f faulty nodes, you need a minimum of 4f + 2 rounds? Mikerah*
>
> Some points here are definitely a wishlist for group formation. https://hackmd.io/H9hEPKorTE-aFBuk5OD2qw?view should be consulted.
1. The DC net groups take between 8-12 nodes per group and the greedy group selection tries to select as many SuperStarnodes as possible.
2. Assuming we zoom into one group, let's call it "dream team", this group habitually has a lot of SuperStarnodes, so lots of nodes apply to join that group.
3. The group randomly selects some of the quickest and most reputable nodes and starts the round.
* Other groups are forming at the same time and starting whenever that are ready.
* All rounds must finish at a certain time (synchronous) or their results are discarded, groups disbanded and a new round is attempted(economic loss).
4. In this dream team group let's assume at least 7 of the 12 are confirmed SuperStarnodes (criteria for that to be discussed) that leaves 5 potential slots for nodes (other slots to be padded with dummy traffic so all groups show 12?).
* Of these 5, a few directions could be taken.
* Either these 5 could be SubSuperStarnodes that are close to meeting the criteria, but are not yet there.
* SubSuperStarnodes would be very reliable.
* Or some less reputable nodes could be included.
* These nodes would be generally neutral reliability (new nodes to the network).
* Since only 8 real nodes are needed to finalize a round and there are 7 SuperStarnodes already, only one of the SubSuperStarnodes would have to be honest/online for the round to eventually finalize.
* Since there are 7 known SuperStarnodes and a few SubSuperstar nodes assumption is that even if the first round fails with 12 (or less depending on dummy traffic) it can kick the bad node and simply try again which should work since those nodes are quicker anyways?
* All greedy formation would allow all nodes from the dream team the ability to help out weaker teams/groups.
* Greedy formation mixed in with some alturism might provide a better experience for new nodes to the system and nodes that may have made some mistakes/want extra security and need to reset their keys/account.
* This path should make the network more useful for more users and therefore could increase the number of network users and the overall size of the anonymity set.
* Might not be needed if all nodes can hide among general traffic of PoS stakers. In which case 5(a) seems more logical.
7. Either way, giving nodes options should help with that, but not too many options to allow for traffic analysis? I suppose that's another design topic to discuss.
8. How much freedom should each node have?
to add:
- Definitions of Anonymity
- Group Formation
- Multi-Round Commuication
- Incentives
- Common attacks
- Common issues?
## 4. Group Formation
- Greedy
- RP nodes
![](https://i.imgur.com/cqIAJuf.png)
### 4.1 ADC vs DC/nets
We introduce a modified version of DC-nets that contain a rendezvous point (RP). A RP is a regular DC-net participant with additional tasks, namely:
- Being the sole receiver of all DC-net messages of the DC-net.
- Decrypting the published secret messages.
- Forwarding them to their recipients that are not necessarily part of the DC-net.
> We refer to DC-nets that contain a RP as ADC-nets due to the asymmetric message flow between the RP and the other participants.
In contrast to classical DC-nets, ADC-nets require the election of a RP before the actual communication can begin. Apart from this additional task, the initialization phase of ADC-nets is comparable to the one of DC-nets.
In contrast to DC-nets, ADC-net messages are not broadcasted to all peers in the network.
- Instead, every participant only sends its ADC-net messages to the RP of the ADC-net.
- The RP then decrypts the messages published in the ADC-net and forwards them to their actual recipients.
- This reduces both the number of messages sent and the number of XOR operations executed per round.
- This addresses the overhead challenge.
ADC-nets induce less overhead than DC-nets. Hence, the overhead challenge is addressed by using ADC-nets instead of classical DC-nets.
- We decouple ADC-net participants from overlay participants by using ADC-nets as intermediate layer between underlay and overlays.
- This decoupling addresses the overlay churn and the anonymity set size limitation challenges.
#### 4.1.1 Anonymity Set Size
ADC-nets comprise a configurable number of peers when used as presented in Section 4.5.
- Hence, the anonymity set size can be individually selected for specific use cases.
- For instance, communication with critical content can be protected by using larger anonymity sets at the cost of increased overhead.
![Uploading file..._d2g511e14]()
#### 4.1.2 Overhead
**Communication Overhead:**
- DC-nets: every participant has to send a DC-net Message to each other participant.
- ADC-nets: Every participant, except the RP, sends its ADC-net message to the RP.
> In contrast to regular ADC-nets, the RP also sends the published message to each other ADC-net participant for collision handling purposes.
**Computational Overhead:** The amount of XOR operations per round can be reasonably reduced by using ADC-nets instead of DC-nets. While RPs execute the same amount of XOR operations as each participant in a DC-net, the other ADC-net peers are relieved of decrypting a message for each round.
### 4.2 Underutilized Groups
A couple techniques for reducing the overhead induced by ADC-nets that are not sufficiently utilized:
- Pausing.
- Disbanding.
A number of challenges arise when using pausing and disbanding:
- A low ADC-net utilization has to be detected before pausing/disbanding can be initiated for the ADC-net.
- ADC-net participants have to be informed of pausing/disbanding.
- Pausing/Disbanding should only commence after a reasonable transition period in which the ADC-net participants can prepare for it.
### 4.3 ADC-net Initialization
We assume that each peer can take part in multiple ADC-nets at the same time.
- However, the participation in each ADC-net results in both communicational and computational overhead for a peer.
We address the DC-net/ADC-net initialization observation challenge by using a randomized approach for the initialization of ADC-nets.
> The approach is presented by Algorithm 2 and is executed individually on each peer.
![](https://i.imgur.com/QQL3anr.png)
Each peer that decides to participate in a group setup reserves capacity for the case that it succeeds and results in a new ADC-nets.
![](https://i.imgur.com/DDF2ObE.png)
Adversaries can easily disrupt group setups by refusing to forward random walks to other peers.
- To increase the probability of at least one random walk not being disrupted by an adversary, we propose the execution of multiple random walks in parallel.
> Each random walk can be executed independently from the other random walks without coordination by the group initiator.
### 4.4 Overlay Interaction
ADC-net participants conduct all sender-related overlay interactions through the ADC-net by using the RP as proxy.
- Adversaries can only observe sender-related overlay interactions of RPs but cannot identify the ADC-net participants behind these interactions.
- Sender-unrelated interactions can still be executed directly by peers.
- For instance, joining an overlay to receive messages on it,
- This solves the overlay interaction observation challenge.
Interest control messages that contain one topic of interest and can be used by ADC-net participants to anonymously notify the RP of their interests.
- These messages are published in ADC-nets as secret messages.
- When a RP receives an interest control message, it tries to join an existing overlay that addresses the topic of interest.
- If no such overlay exists, the RP initiates a new overlay for this topic.
- Using this approach, ADC-net participants can send their interests to the RP without being linked to them.
- Interests should only be sent one-by-one to prevent adversarial RPs from linking ADC-net participants to their interests by comparing interest sets across ADC-nets.
![](https://i.imgur.com/gJCxapG.png)
### 4.5 Example Group Set-up
Multiple scenarios that result in the network structure presented in Figure 4.2:
1. Peer 3 initializes the creation of the ADC-net after its initialization check, as presented in Section 4.5.1, succeeds.
2. Peer 3 starts the group setup as presented in Section 4.5.2. The outcome of this group setup is the set G = {1,2,3,4,6} containing the group participants.
3. The RP election is conducted as presented in Section 4.4.1 and with G as initial candidate set.
- Peer 4 is elected as RP.
4. The ADC-net participants generate master secrets as presented in Section 2.6.1.
5. The ADC-net participants can now induce the creation of the overlay by sending their interests to the RP as presented in Section 4.5.3. For simplicity, we assume that all peers in G are interested in the same topic and that the created overlay is related to this topic.
6. We assume that the remaining participants of the overlay joined it after its initialization by the RP.
7. Now, each participant of the ADC-net can use it to send messages to every participant of the overlay by using the RP as proxy as presented in Section 4.4.2.
## 5. Network Topology
- Base Pos layer
- ADC-net overlay
- TCP/SSL? encryption and general use
## 6. Incentives within anonymous networks
- reputation?
- economic!
- others?!
## 7. Conclusion
- Is this viable?
- Is it realistic?
- What would it take?
### Questions?
1. How many nodes can utilize an ADC-net with the restrictions of Eth2.0 Specs so far?
- Also, what are the tehnical requirements for each node.
- Seems as though nodes could use their extra computing power/bandwith would to their, and the network's, benefit.
### Random Thoughts
* Asymmetrical(A-DCnet) and Synchronous (Blinder)?
* Membership: All nodes staking in the system.
* Can some nodes be in the system for added anonymity, but aren't staking?
* All nodes send 1ETH to stake
* DC-net are used to provide unlinkability for the node that received the stake (Won the secret leader election).
* If only one group was used. 32 nodes would be run, so 1/32 chance of picking the winner of the election
* If multiple nodes are used chances stay similar, but Bloom filers? can be used to increase anonymity (e.g. if groups were in different locations attribute swapping can be used to make it even more difficult to discern what group a node is in based on attributes in that group)
* Nodes must be verified in the group for a set amount of time (at least before the start of the epoch) to be eligible to win the election/rewards.
* Using the dc-net structure, an attacker should not be able to discern who won the election, simplty who took part (again multiple groups could mitigate this risk)
* The economic incentives should work as well because if 32 nodes are needed in the dc-net between each epoch, and 1 $\geqslant$ users try and exit the group, the chance of other users winning the election would go up.
* Instinctively this could be an attack vector because if $I\mathfrak{A}$ colluded with $G\mathfrak{A}$ (and maybe without collusion?) and left the group $G\mathfrak{A}$ would be able to monitor other nodes and seeing their increased chance of winning the election over time would be able to discern the group the nodes belonged to.
* This could also be mitigated if nodes changed groups every so often so that $I\mathfrak{A}$ would have to try and follow the node in question to a different group in order to attain more information about that specific node (baysian attack?)
* Also, pseudonyms that change (maybe as the nodes change groups) would help so that even if an attacker did gain some information on a node, that information would be attached to a pseudonym that would change (and therefore lose value)
* Might be a good idea to have the pseudonyms generate based on local data (verifiable/linkable) so that an attacker couldn't eventually gather enough information about changing pseudonyms to try and match pseudonyms to users.
* Pub/Sub system like GossipSub libp2p would be used to get messages send between nodes.
* Go implementation
### EPoch Info
Eventually the goal would be to have users able to download an app that auto set's up anonymous membership into a random group. Once in a group, and after a set amount of time to ensure fairness, the user would start staking anonymously and have a 1/32% chance (or greater) to win the election. If a challange game is needed, waiting a certain amount of epochs could be neccesary before exiting the network. (dc-net challenegs take less than 6 seconds and epochs are 6.4 minutes.
> An **epoch** is comprised of 32 slots (6.4 minutes) during which the **beacon chain** performs all of the calculations associated with the upkeep of the **chain**, including: justifying and finalising new blocks, and issuing rewards and penalties to validators. [https://blog.ethereum.org/2020/03/27/sharding-consensus/#:~:text=An%20epoch%20is%20comprised%20of,rewards%20and%20penalties%20to%20validators.](https://blog.ethereum.org/2020/03/27/sharding-consensus/#:~:text=An%20epoch%20is%20comprised%20of,rewards%20and%20penalties%20to%20validators.)
Therefore, waiting 1 epoch to enter a group and 1 epoch to exit, should be sufficient. Within that time, any node should be able to challenge an election from the previous epoch and if there was an issue (found within 6 seconds) there would be plenty of time to find a solution similar to slashing where honest nodes are rewarded for validating that the winner of an election was computationally correct.
This wouldn't stop an attacked from knowing users were running nodes, but would make the winner of each stake anonymous.
### Withdraw Privately?
This anonymity wont last once a user withdraws though. (not an issue for a while?) Private transactions will be needed in the future for this (zkopru's might work for this at a later date. private validating nodes could also be the optomistic rollup validators for the private transactions needed and randomized withdrawal transactions could be used for unlinkability of withdrawals of staking rewards to users)
Since withdrawals are not allowed in phase 0, the main goal of a private validator would be so that others couldn't track your staking rewards? This solution achieves that goal.
> Although withdrawals could be allowed by having a central account for the network that did not allow real withdrawals until a later date (until they were techincally allowed) but allow users to withdraw their balance to ETH1.0 chain anonymously (zkopru's).
> * This would reduce their balance of ETH2.0 rewards but those funds would still be within the network as rewards.
> * The only way this would work is if there was an anonymous "dex" of sorts that allowed ETH1.0 to be swapped for validator rewards within the network. This "IOU" system should work since the actual amount of rewards within the network is unable to change (this obviously would add a lot more complexity to the system, but centralized public services will probably offer it and so it should be something offered here as well.)
### Staking Multiple Chains for Greater Anonymity
A secondary solution would be making it so that a $G\mathfrak{A}$ could not uncover the identity of a node operator within the network. This would require a larger group of nodes to hide among. Potential simple solution would be obscuring which network a user is staking on by having different groups that are validating on different networks. That way, even if an attacker was able to find out that a node was within the larger membership group, they would not know which membership group the user was a part of (e.g. staking on ETH, cosmos, or polkadot, or a combination of them). Anonymity increases with a larger set size, so as different networks are added, it provides more groups for private validating nodes to hide among.
Outbound Routing Tunnel Setup Procedure
1. The anonymized node owning the outbound routing path (i.e. exit path) wants to establish a
connection to another node in the anonymous network.
2. The anonymized node generates a dummy random data package, having the size of a single
symmetric crypto block (i.e. 128 bits or more), and sends this package off through the preexisting connection to the next intermediate node in the routing path.
Using the size of a single crypto block is good for preventing an attacker from piggy-backing data
with the block as it is being forwarded through the tunnel. In the case of a single symmetric crypto
block, the entire plaintext contents of it will become completely corrupted if only a single bit of it is
altered by any node in the routing path.
The crypto key initialization block could be anything that enables it to be tested really quickly and
efficiently for internal consistency of some kind. One very simple example is to have two 32-bit
blocks containing the exact same data (any random number). Thus, the test for internal
consistency could be performed simply by comparing the two to see if they are equal or not.
The probability of a random 64-bit crypto key initialization block passing this test would be one in
2
32, and the extra checksum in the tunnel initialization package will make sure to decrease the
probability of false positives to one in 296. The extra checksum test will practically never have to
be used in the primary quick consistency test though, only in the cases where a false positive
passes the primary test, which will be too infrequently to affect the testing speed anyway.
Why can’t each
node just have a single secret symmetrical key, instead of randomly selecting one from a pre-defined set? The reason is that we don’t want the nodes in the path to be able to communicate
with each other through “covert channels”, i.e. using parts of the protocol as a means of encoded
communication. The multiple keys prevent non-adjacent nodes from being able to communicate
with each other through repeated requests for new tunnels, and indirectly through the data
contained in the tunnel initialization packages of these. Using multiple keys chosen individually by
the each node during the establishment of each tunnel, there are no means for a node in the path
to deterministically influence the encrypted form of the tunnel initialization package coming out of
its adjacent node, and even less the remaining nodes.
The main concept of this method is that any attacker (e.g. any of the intermediary nodes in the
path) would rather have to crack at least the equivalence of one full 128-bit key for each of the
nodes in the path in order to get hold of the used keys, an exercise which is not feasible at all (as
long as the symmetrical algorithm used, e.g. AES, isn’t itself cracked, of course, but even in that
event it could be easily replaced too).
The reason for using stream encryption in each node is to eliminate any and all possibilities for
any two non-adjacent nodes in the routing tunnel/path to communicate with each other by means
of any kind of data patterns sent over the routing tunnel. For each encrypted unit of data, the
stream encryption state in each node is updated, which means that it will produce completely
different output even if identical data is sent over the same connection twice.
End-to-end security equivalent to that of SSL, i.e. using secure end-to-end encryption and
bidirectional secure asymmetrical authentication, can also be easily be accomplished over the
connections of the anonymous network too. The best way is most likely to simply use a regular
SSL connection inside the TCP-equivalent anonymized connection that has been described. This
way, the common anonymized connection would be the anonymized equivalent of a TCP
connection, while the SSL-secured version would be the anonymized equivalent of an SSL/TCP
connection.
Due to the inherent problems of using a standard PKI structure with certificate authorities (CA) in
an anonymized network (no certificate authority will obviously be able to positively identify the
owner of any AP address, since this in the foundational concept), other methods of ensuring the
authenticity of end points will have to be used. The classic “web of trust” method can still be used,
where one or several trusted actors (either real identities or other AP addresses) can vouch for
the authenticity of a certain AP address certificate.
Also, a second solution which could be used in parallel with the “web of trust” method is to make
it possible for users to manually store trusted end-point certificates for certain AP addresses
locally in their computers. These will be compared to the certificates presented by the
corresponding AP addresses as soon as they are being connected to, and if a mismatch would
occur, a warning will be presented to the user about this. These trusted certificates would typically
be acquired and stored the first time an AP address is connected to, or even acquired manually
from third party sources.