The Phantom anonymity protocol was designed in 2008 by Swedish security researcher Magnus Bråding to provide anonymity optimized for the current conditions and needs of average internet users. The design goal was feasibility for mass adoption as a de facto internet anonymization standard. This goal differentiates it from other anonymization protocols such as TOR, which have seen only limited adoption among the masses. The Phantom protocol designer hopes to change this situation and provide secure anonymity to everyone, including non-technical people.
The protocol was first presented publicly by Magnus Bråding at the IT security and hacking conference DEFCON 16 in Las Vegas 2008.
https://www.slideshare.net/lokijaja/phantom-pres
The researchers behind the SPECTRE and GHOST projects have proposed a new blockchain scalability protocol.
Called PHANTOM, the protocol claims to provide transaction confirmation that is "secure under any throughput that the network can support" - smart contracts included.
Authors Yonatan Sompolinsky and Dr. Aviv Zohar outlined the new protocol in a paper published this week, building on SPECTRE, which deviates from bitcoin's common block structure with more scalable "directed acyclic graphs of blocks"(blockDAGs). The team describes the tech as "a generalization of Satoshi's chain which better suits a setup of fast or large block[s]."
Unlike off-chain solutions such as the Lightning Network, where transactions are conducted on a separate layer, Phantom proposes an on-chain means of achieving scalability.
The authors explain that PHANTOM's primary focus is that it enables the linear ordering of blocks, which is not possible in the SPECTRE protocol. To do so, it uses a "greedy algorithm" on the blockDAG to identify blocks mined by "honest" nodes, but not those from "non-cooperating" nodes that deviate from the mining protocol.
The paper states:
"Using this distinction, PHANTOM provides a full order on the blockDAG in a way that is eventually agreed upon by all honest nodes."
Solving the problem of linear ordering, the authors say, enables PHANTOM to scale any computation, including smart contracts.
However, Sompolinsky and Zohar note that, by adopting linear ordering, the protocol sacrifices some of the speed of confirmation previously achieved by SPECTRE. The researchers indicated their plans to resolve this problem in future work.
Credit: https://www.coindesk.com/spectre-creators-propose-phantom-blockchain-protocol/
Anonymity on the internet is an interesting problem, for which several different solutions have been implemented (e.g. Tor, Freenet). Creating such a network is an interesting exercise for one thing, but using one is also highly useful to avoid various kinds of internet activity monitoring. While people in relatively free countries may find it useful to avoid their ISP and government's monitoring, activists and others living under more repressive regimes may find it to be much more than that—in some cases, it could make a life-or-death difference. Phantom is another mechanism for providing internet anonymity that has a number of interesting properties.
The Phantom protocol was introduced at DEFCON 16 in 2008 by Magnus Bråding (slides [PPT]) and is designed to provide decentralized anonymity. The idea is that there is no central weak point that can be shut down or attacked to stop the use of Phantom. It also requires end-to-end encryption, unlike Tor and others, so that there is no "exit node" problem, where a compromised or malicious participant can eavesdrop on the communication. In addition, Phantom is designed for higher performance so that large data volumes can be transferred through the network.
One of the most interesting aspects of Phantom is that it requires no changes to existing internet applications. From the perspective of a web browser or other application, it is just using standard-looking IP addresses. In reality, those addresses are Anonymous Protocol (AP) addresses that are handled by the Phantom software. One of the assumptions that Phantom makes is that IP addresses can be mapped to real-life identities (a very sensible assumption), so one of the major goals is to ensure that those cannot leak.
While the internet is used to carry all of the Phantom traffic, that traffic is virtually partitioned from the rest of the internet. Service providers that want to enable anonymous access to their services (e.g. a web server) have to register that service within the Phantom network. Obviously, that registry could be a problem from a decentralization standpoint, but Phantom uses a distributed hash table (DHT) to contain the information. Various large-scale implementations of DHTs, like Kademlia that was used by the eMule peer-to-peer system, are already in existence.
The DHT is known as the "network database" and contains two separate tables. One lists the IP addresses, ports, and properties of the currently connected nodes in the network, while the other has the AP addresses and properties of connected and registered nodes. The two tables are, obviously, not directly correlated as that would defeat the whole purpose. In order to get a "copy" of the DHT, a new node just needs to contact one existing node and join into the distributed database. Lists of valid IP addresses to connect to could come via nearly any mechanism: web sites, email, or even distributed on pieces of paper. If even one of the listed nodes is still valid, a new node can use it to join in.
A client that wants to communicate on the network must set up its own exit node. It does so by choosing a number of other nodes in the network with which to establish a routing path, the last one of which is the exit node. Unlike Tor, there isn't an established set of exit nodes as any system participating in the network can potentially be an exit node. Also unlike Tor, it is the endpoint that chooses its routing path, rather than the network making those decisions. There is a detailed description of the protocol for establishing a routing path in the Phantom design white paper [PDF]. Each step along the path is encrypted using SSL and the paper shows the details of the complicated process of creating the exit node.
Similarly, any services on the network need to create a routing path to an "entry node". In some cases, where the service itself does not require anonymity but wants to provide access for anonymous clients, the entry node may be the server itself. In any case, services register their AP-to-IP address mapping in the DHT using the IP address of the entry node. For services that do wish to remain anonymous, they will still be hidden behind the routing path from that entry node.
Furthermore, nodes create routing tunnels between themselves and their exit or entry node. These tunnels are under the control of the endpoints, not the network or any intermediary (including entry/exit) nodes. Making a connection is then a process of connecting the two routing tunnels together with the exit node of the client connecting to the entry node of the server. These tunnels are bi-directional, and encrypted in such a way that the intermediaries cannot decrypt the traffic, nor can a man-in-the-middle interfere with the communication without detection.
One of the important properties of the system is that nodes do not know whether they are talking to an endpoint or just another node in a routing path. The routing paths themselves can be arbitrarily long, and could even be chained together to provide further isolation as desired.
While the whole scheme seems fiendishly complex, it has been implemented [PDF] by Johannes Schlumberger as part of his Masters Degree work. Performance is, perhaps surprisingly, said to be reasonable: "maxing out a 100 Mb/s network connection for data transfers over multi-hop Phantom routing tunnels, so the crypto overhead does not seem to be significant at all". The code is available under the Hacktivismo Enhanced-Source Software License Agreement (HESSLA), which seems to be a GPL-inspired license with some additional "political" objectives. Based on the README, the implementation uses a tun virtual network device and may be fairly complicated to set up.
Overall, Phantom looks very interesting. Like Tor and others, though, it requires a fairly large number of participating nodes in order to truly be of use. One of the biggest barriers for Tor has been that exit nodes get blamed for the behavior of the traffic that emanates from them. Since that traffic can't be traced further back than the exit nodes (at least hopefully), any criminal or malicious traffic is associated with whoever runs the Tor node. Because services will have to specifically enable anonymous access for Phantom, that may be less of a problem. It may also make Phantom adoption less likely.
It's a bit difficult to see widespread adoption of Phantom (or any of the other anonymous network protocols), though the Electronic Frontier Foundation has been pushing Tor adoption recently. Some kind of solution is clearly needed but, so far, the logistical and legal hurdles seem to be too large for many to overcome. Unfortunately, anonymous networks may fall into the category of "things that are not set up until it's too late". But it is good to see that people are still thinking about, and working on, this problem.
System for generic, decentralized, unstoppable internet anonymity
The Phantom protocol is a system for decentralized anonymization of generic network traffic. It has been designed with the following main goals in mind:
Completely decentralized.
No critical or weak points to attack or put (il)legal pressure on.
Maximum resistance against all kinds of DoS attacks.
Direct technical destructive attacks will practically be the only possible way to even attempt to stop it.
Theoretically secure anonymization.
Probabilistic methods (contrary to deterministic methods) must be used in a completely decentralized design like this, where no other peer can be trusted, so focus is put on optimizing these methods.
Theoretically secure end-to-end transport encryption.
This is simple in itself, but still important in the context of anonymization.
Completely (virtually) isolated from the "normal" Internet.
No one should have to worry about crimes being perpetrated from their own IP address.
Maximum protection against identification of protocol usage through traffic analysis.
You never know what the next draconian law might be.
Capable of handling larger data volumes, with acceptable throughput.
Most existing anonymization solutions are practically unusable for (or even prohibit) larger data volumes.
Generic and well-abstracted design, compatible with all new and existing network enabled software.
Software application developer participation should not be needed, it should be easy to apply the anonymization to both new and already existing products like e.g. web browsers and file transfer software.
The latest version of the source release package can always be downloaded here.
White paper describing the protocol and its design:
http://www.magnusbrading.com/phantom/phantom-design-paper.pdf
Paper describing the protocol implementation:
http://www.magnusbrading.com/phantom/phantom-implementation-paper.pdf
Slides from the original DEFCON 2008 presentation about the protocol:
http://www.magnusbrading.com/phantom/phantom-pres.ppt
DEFCON presentation video (speaker + slides):
https://media.defcon.org/dc-16/video/Defcon16-Magnus_Brading-The_Phantom_Protocol.m4v
DEFCON presentation video (slides only):
https://media.defcon.org/dc-16/video/Defcon16-Magnus_Brading-The_Phantom_Protocol-Slides_Only.m4v
DEFCON presentation (audio only):
https://media.defcon.org/dc-16/audio/Defcon16-Magnus_Brading-The_Phantom_Protocol.m4b
Originally By Андреас Пирес - April 19, 2017
Extra Stuff
https://www.shiftnrg.org/#/news