Posts Tagged technical
Functionalities and Requirements
Posted by steiakakis in Technical Details on May 6, 2012
Register
# | Requirement | Description |
1 | Required fields | Username, Password, 3 Secret Questions, 3 Secret Answers |
2 | User Verification | Insert password twice.
Acceptance of Terms and Conditions. |
Login
# | Requirement | Description |
3 | User Details | Username and password to gain access |
4 | Password Retrieval | A user can retrieve his password if he provide the correct answers to secret questions |
Edit Profile
# | Requirement | Description |
5 | User Details | A user can edit his personal details providing all the required fields. |
Add Supporter
# | Requirement | Description |
6 | View Supporters list | A user can add another user to his supporters list. |
Support Requests
# | Requirement | Description |
7 | View Support requests list | A user can view his support request list. He can accept or reject a request from another user. |
View Supports list
# | Requirement | Description |
8 | View Supports list | A user can view his supports list which contains all the users that he supports. |
Sent Message
# | Requirement | Description |
9 | Create new message | A user can send a personal message to another user. The receiver can accept or decline this message. If he accepts the communication from a user, that user is inserted on his trust list. |
Add to trust list
# | Requirement | Description |
10 | Add a user to support list | A user can view his trust list that contains the users that he trusts to communicate with. |
Add to block list
# | Requirement | Description |
11 | Add a user to block list | A user can view his block list that contains the users that he does not want to receive messages from. |
Search
# | Requirement | Description |
12 | Search for a topic | A user can search for his desired topic using hashtags. |
Save Search
# | Requirement | Description |
13 | Save a specific search | A user can save his favourites search gaining easier navigation. |
Upload Picture
# | Requirement | Description |
14 | Upload a profile picture | A user can upload a picture and store it in his profile. He can also delete that picture. |
Create new topic
# | Requirement | Description |
15 | Create new topic | A user can create a new topic of his interest using the provided form. The topic needs a title and some hashtags in order to be categorized. |
Comment a topic
# | Requirement | Description |
16 | Comment on a topic | A user can create a new comment under a topic or another comment. |
Hosting on I2P
Posted by drakopoulos in Technical Details on May 3, 2012
The default install of I2P comes with a Jetty web daemom, so starting up the eepsite is actually incredible easy. On the router console homepage, in the left hand bar there is a link to the I2PTunnel under the heading I2P Internals.
Once inside, in the I2P Server Tunnels section, you will see the default eepsite. Click the start button, and wait for it to start up.
On Windows, at this location: C:\Program Files\i2p\eepsite is where you will find the index.html file of the eepsite. There are some redirect to help instructions in the file, once those are deleted things are good to go.
Of course, the destination of the eepsite is on the local host and it will be difficult for other people to find because it doesn’t have a name and they don’t have your really long Base64 key. You could just tell people that really long key, but thankfully I2P has an address book and several easy ways to tell people about your eepsite.
First, enter the new name of the eepsite on the eepsite i2ptunnel configuration page where it says “Website name”. This will replace the default “mysite.i2p”.
Highlight the entire “Local destination” key on the eepsite i2ptunnel configuration page and copy it for later pasting. Make sure you get the whole thing – it’s over 500 characters and it must end in “AAAA”. Enter the name and paste in the destination key into your master address book. Click “Add” to add the destination to your address book.
The final step is registering the eepsite in an address book hosted by i2p, which is part of the NetDB (explained in the about I2P post). Go to stats.i2p. Again, your key is the entire “Local destination” key on the eepsite i2ptunnel configuration page. After adding it, we can check to see if it reports the key was added. Since many routers periodically get address book updates from these sites, within several hours others will be able to find your website by simply typing 3speech.i2p into their browser.
We also used this video to learn how to host an eepsite by creating a new HTTP server tunnel and to map it to a virtual host rather than use the default Jetty. We did not actually do this because we do not have an external server to use.
Technologies Used
Posted by drakopoulos in Technical Details on May 2, 2012
Programming Language / Framework
The chosen language of 3speech implementation is Ruby, which is a dynamic, reflective, general-purpose, open source, object-oriented programming language. Ruby supports multiple programming paradigms, including functional, object oriented, imperative and reflective. 3speech was developed using the Ruby on Rails, open source full-stack web application framework which is a variant of the Model/View/Controller (MVC) architecture pattern to organize application programming. Ruby on Rails is a full-stack framework, meaning that it gave us the full ability to gather information from the web server, talking to or querying the database, and template rendering out of the box.
Web Server
I2P Webserver – A tunnel pointed to a Jetty webserver run on localhost:7658 for convenient and quick hosting on I2P.
The document root is:
Unix – %APPDATA%\I2P\eepsite\docroot
Windows – C:\Users\**username**\AppData\Roaming\I2P\eepsite\docroot
A future consideration is to use server virtualization, which is the partitioning of a physical server into smaller virtual servers to help maximize our server resources. In server virtualization the resources of the server itself are hidden, or masked, from users, and software is used to divide the physical server into multiple virtual environments.
Server virtualization also conserves space through consolidation as several machines can be consolidated into one server running multiple virtual environments. It also utilizes resources to the fullest so we can also save on operational costs (e.g. using a lower number of physical servers reduces hardware maintenance).
Database choice: NOSQL
NoSQL, which most now take to mean âNot Only SQL,â is a new non-relational approach to data
management that supports dynamic and flexible schemas, optimized storage for web scale, and
extreme performance as well as makes semi-structured and unstructured data easier to use and
access. Although RDBMS technology is still a good fit for critical transactional applications, new types of applications are motivating architects to look elsewhere when the relational approach falls short. Craigslist, Facebook, Twitter, Yahoo, and YouTube have already used NoSQL to support demanding web-scale applications. Although adoption of NoSQL in enterprises is around 4%, Forrester expects this to double in the next two years and that by 2015, 20% of enterprises will use NoSQL to support some or all of their applications. This is one of the major reasons for choosing to use NoSQL.
NoSQL offers several benefits in the areas of data management, access, storage, scale, and performance that make it a viable alternative to RDBMS. NoSQL delivers:
Flexible schema structures to support new types of applications.
Unlike an RDBMS, which requires the application developer to predefine data attributes, entities, and relationships, NoSQL offers a more flexible approach in which the application rather than the data store defines the schema and access paths. NoSQL supports a wide range of new data types, including textual types such as JSON as well as many other unstructured and semistructured data types. NoSQLâs inclusion of these flexible schemas and data types makes it easier to build new types of social media, cloud, and other scale-out applications.
High-performance key-value data reads and writes.
Applications that require extensive data reads and writes often experience excessive latency due to disk input/output (I/O) bottlenecks, especially when the app has high volumes of both. NoSQL approaches are efficient at reading very large amounts of data in a scale-out model, with each node in a cluster having its own I/O channels and controllers to deliver linear scale. For example, Twitter spreads accounts across thousands of nodes using a key-value store, and millions of users get low latency while concurrently accessing data. Conversely, NoSQL is not well suited to joining entities unless the store contains prejoined data.
Elastic scale to support dynamic workloads.
Because of the need to partition data across multiple databases, itâs challenging to scale out an RDBMS to handle growth. This makes it challenging to use an RDBMS when building an application that can easily scale from a thousand to a million users. NoSQLâs shared-nothing, scale-out architecture makes it easy to add nodes in a cluster or cloud to deliver linear scale.
Simplicity that makes it easy to get started.
NoSQL solutions have a fourth of the features of a typical RDBMS. This makes NoSQL easier to learn than a traditional DBMS as well as simpler to use when developing and deploying applications. From what we heard in interviews in the past year, many application developers like the simplicity and ease of using NoSQL in development. When using NoSQL, application developers have complete control over data storage and access and typically donât need a database administrator (DBA) to support the NoSQL data store.
A lower-cost data management platform.
Many NoSQL solutions are open source, and others sell for much less than a full version of a commercial RDBMS. Compared with conventional DBMSes, NoSQL products often save enterprises more than 50% of the cost.
Freedom to innovate.
NoSQL is for application developers and programmers who want complete control and flexibility to store and access data in the manner they want without having to comply with the constraints and rigid structures an RDBMS imposes.
Neo4j is an open-source graph database, implemented in Java. The developers describe Neo4j as “embedded, disk-based, fully transactional Java persistence engine that stores data structured in graphs rather than in tables”.
Key benefits*
A graph data model which enables high performance queries on the complex, connected data inherent in today’s applications. You can ask questions such as “Who are all my contacts in Europe?” and “Which of my contacts ordered from this catalog?” It can traverse complex graphs with improvements of 1000x or more compared to SQL and other NOSQL databases.
A graph data model which simplifies the development of applications using complex, connected data. Enterprises can quickly capture all kinds of data – structured, semi-structured, and unstructured – and easily store it in Neo4j. This results in shorter development times, lower maintenance costs and higher performance.
Mature support for transactions so that enterprise developers can execute “all or nothing” transactions. Although this is a must-have for relational databases, none of the other NOSQL databases can do this. Neo4j supports full ACID transactions including XA-compliant distributed two-phase commits.
Enterprise-grade durability that ensures that any transaction committed to the database will not be lost. I
Awesome Java support. While supporting all of the leading development platforms, (Ruby, Python, Groovy, Gremlin, etc) Neo4j began in Java and will always be easily accessible and available for Java, the most widely used development environment in the enterprise.
This was also incredibly help full in helping us learn about representing our social network in the database: Social Network in the Database: Using a Graph Database
*Taken from the neo4j website.
NoSQL
Posted by drakopoulos in Technical Details on May 1, 2012
NoSQL, which most now take to mean âNot Only SQL,â is a new non-relational approach to data management that supports dynamic and flexible schemas, optimized storage for web scale, and extreme performance as well as makes semi-structured and unstructured data easier to use and access. Although RDBMS technology is still a good fit for critical transactional applications, new types of applications are motivating architects to look elsewhere when the relational approach falls short. Craigslist, Facebook, Twitter, Yahoo, and YouTube have already used NoSQL to support demanding web-scale applications. Although adoption of NoSQL in enterprises is around 4%, Forrester expects this to double in the next two years and that by 2015, 20% of enterprises will use NoSQL to support some or all of their applications. This is one of the major reasons for choosing to use NoSQL.
NoSQL offers several benefits in the areas of data management, access, storage, scale, and performance that make it a viable alternative to RDBMS. NoSQL delivers:
Flexible schema structures to support new types of applications.
Unlike an RDBMS, which requires the application developer to predefine data attributes, entities, and relationships, NoSQL offers a more flexible approach in which the application rather than the data store defines the schema and access paths. NoSQL supports a wide range of new data types, including textual types such as JSON as well as many other unstructured and semistructured data types. NoSQLâs inclusion of these flexible schemas and data types makes it easier to build new types of social media, cloud, and other scale-out applications.
High-performance key-value data reads and writes.
Applications that require extensive data reads and writes often experience excessive latency due to disk input/output (I/O) bottlenecks, especially when the app has high volumes of both. NoSQL approaches are efficient at reading very large amounts of data in a scale-out model, with each node in a cluster having its own I/O channels and controllers to deliver linear scale. For example, Twitter spreads accounts across thousands of nodes using a key-value store, and millions of users get low latency while concurrently accessing data. Conversely, NoSQL is not well suited to joining entities unless the store contains prejoined data.
Elastic scale to support dynamic workloads.
Because of the need to partition data across multiple databases, itâs challenging to scale out an RDBMS to handle growth. This makes it challenging to use an RDBMS when building an application that can easily scale from a thousand to a million users. NoSQLâs shared-nothing, scale-out architecture makes it easy to add nodes in a cluster or cloud to deliver linear scale.
High-performance key-value data reads and writes.
Applications that require extensive data reads and writes often experience excessive latency due to disk input/output (I/O) bottlenecks, especially when the app has high volumes of both. NoSQL approaches are efficient at reading very large amounts of data in a scale-out model, with each node in a cluster having its own I/O channels and controllers to deliver linear scale. For example, Twitter spreads accounts across thousands of nodes using a key-value store, and millions of users get low latency while concurrently accessing data. Conversely, NoSQL is not well suited to joining entities unless the store contains prejoined data.
Elastic scale to support dynamic workloads.
Because of the need to partition data across multiple databases, itâs challenging to scale out an RDBMS to handle growth. This makes it challenging to use an RDBMS when building an application that can easily scale from a thousand to a million users. NoSQLâs shared-nothing, scale-out architecture makes it easy to add nodes in a cluster or cloud to deliver linear scale.
Freedom to innovate.
NoSQL is for application developers and programmers who want complete control and flexibility to store and access data in the manner they want without having to comply with the constraints and rigid structures an RDBMS imposes.
Five challenges of NoSQL
The promise of the NoSQL database has generated a lot of enthusiasm, but there are many obstacles to overcome before they can appeal to mainstream enterprises. Here are a few of the top challenges.
Maturity
RDBMS systems have been around for a long time. NoSQL advocates will argue that their advancing age is a sign of their obsolescence, but for most CIOs, the maturity of the RDBMS is reassuring. For the most part, RDBMS systems are stable and richly functional. In comparison, most NoSQL alternatives are in pre-production versions with many key features yet to be implemented. Living on the technological leading edge is an exciting prospect for many developers, but enterprises should approach it with extreme caution.
Support
Enterprises want the reassurance that if a key system fails, they will be able to get timely and competent support. All RDBMS vendors go to great lengths to provide a high level of enterprise support. In contrast, most NoSQL systems are open source projects, and although there are usually one or more firms offering support for each NoSQL database, these companies often are small start-ups without the global reach, support resources, or credibility of an Oracle, Microsoft, or IBM.
Analytics and business intelligence
NoSQL databases have evolved to meet the scaling demands of modern Web 2.0 applications. Consequently, most of their feature set is oriented toward the demands of these applications. However, data in an application has value to the business that goes beyond the insert-read-update-delete cycle of a typical Web application. Businesses mine information in corporate databases to improve their efficiency and competitiveness, and business intelligence (BI) is a key IT issue for all medium to large companies. NoSQL databases offer few facilities for ad-hoc query and analysis. Even a simple query requires significant programming expertise, and commonly used BI tools do not provide connectivity to NoSQL. Some relief is provided by the emergence of solutions such as HIVE or PIG, which can provide easier access to data held in Hadoop clusters and perhaps eventually, other NoSQL databases.
Administration
The design goals for NoSQL may be to provide a zero-admin solution, but the current reality falls well short of that goal. NoSQL today requires a lot of skill to install and a lot of effort to maintain.
Expertise
There are literally millions of developers throughout the world, and in every business segment, who are familiar with RDBMS concepts and programming. In contrast, almost every NoSQL developer is in a learning mode. This situation will address naturally over time, but for now, itâs far easier to find experienced RDBMS programmers or administrators than a NoSQL expert.
References
[1] Stonebraker, M. âSQL databases v. NoSQL databases.â Commun. ACM 53(4) (April 2010), pp. 10 – 11.
[2] Leavitt, N., “Will NoSQL Databases Live Up to Their Promise?,” Computer , 43(2), Feb. 2010 pp.12 â 14.
[3] Yuhanna, N., âNoSQL Offers New Options for Application Developersâ, Forrester Research, September 2011, ID: 60237
[4] Hopkins, B., âBig Opportunities in Big Dataâ, Forrester Research, May 2011, ID: 59321
Omemo: an open source social storage platform
Posted by wang in Existing Similar Tools on April 30, 2012
What is Omemo
Omemo is a free and open source storage platform based on anonymous P2P communication system. It develops a special method which is everyone shares some parts of their hard drive to establish an enormous virtual hard drive throughout the world. It provides a possibility to set up a distributed storage network which might have limitless storage space. The most attractive feature of Omemo is, it’s totally anonymous, no matter users upload or download sources, all the data are transmitted through  key-based routing and randomly assigning query source.
Omemo allows people to upload and organise files with anonymity and user can access their files from anywhere. No one can change or delete the files that users have shared in this social storage network and no one can trace or monitor the exchange of sources, just as a spokesperson said, “There is no way to know who uploads a file, nor who downloads it.” To some extent, it supports the spirit of freedom and democracy of the Internet.
Omemo is available for Windows platfrom only.
How does it work
Users should firstly share some space on their local hard drive and the programm will set up a virtual hard drive based on these shared space. The more users, the larger will this multimedia library be built.
Omemo uses a a ring-shaped DHT based on Chord, it can realise anonymous data transmission based on key-based routing and randomly assigned query source. The more detailed discusstion of Omemo technical information can be found in these two website:
1. OMEMO: einige technische Infos
2. OMEMO: anonymous drive sharing
Support & development
Unfortunately, Omemo has been defunct already. The latest released programme was still a beta version and it stopped the support of any upload/download actions.
Usage experience
As Omemo has stopped any supports of it’s operation, forum and wiki, I cannot run it by myself, but there is still several screenshots can be found in this review article:
Omemo Launches New P2P Network
References:
1. The World of Peer-to-Peer (P2P)
2. 5 Most Efficient Online Data Back Up And Bulk Storage Sites
3. Omemo Launches New P2P Network
4. Innovative P2P Network launched by Omemo
5. Omemo.com â Open Source Social File Storage
6. Â http://en.wikipedia.org/wiki/Omemo
Freenet: The Free Network
Posted by steiakakis in Existing Similar Tools on April 19, 2012
Freenet is free software which lets you anonymously share files, browse and publish “freesites” (web sites accessible only through Freenet) and chat on forums, without fear of censorship. Freenet is decentralised to make it less vulnerable to attack, and if used in “darknet” mode, where users only connect to their friends, is very difficult to detect.
Communications by Freenet nodes are encrypted and are routed through other nodes to make it extremely difficult to determine who is requesting the information and what its content is.
Users contribute to the network by giving bandwidth and a portion of their hard drive (called the “data store”) for storing files. Files are automatically kept or deleted depending on how popular they are, with the least popular being discarded to make way for newer or more popular content. Files are encrypted, so generally the user cannot easily discover what is in his datastore, and hopefully can’t be held accountable for it. Chat forums, websites, and search functionality, are all built on top of this distributed data store.
Freenet has been downloaded over 2 million times since the project started, and used for the distribution of censored information all over the world including countries such as China and the Middle East. Ideas and concepts pioneered in Freenet have had a significant impact in the academic world. Our 2000 paper “Freenet: A Distributed Anonymous Information Storage and Retrieval System” was the most cited computer science paper of 2000 according to Citeseer, and Freenet has also inspired papers in the worlds of law and philosophy. Ian Clarke, Freenet’s creator and project coordinator, was selected as one of the top 100 innovators of 2003 by MIT’s Technology Review magazine.
An important recent development, which very few other networks have, is the “darknet”: By only connecting to people they trust, users can greatly reduce their vulnerability, and yet still connect to a global network through their friends’ friends’ friends and so on. This enables people to use Freenet even in places where Freenet may be illegal, makes it very difficult for governments to block it, and does not rely on tunneling to the “free world”.
Freenet network:
The network consists of a number of nodes that pass messages among themselves. Typically, a host computer on the network runs the software that acts as a node, and it connects to other hosts running that same software to form a large distributed network of peer nodes. Some nodes are end user nodes, from which documents are requested and presented to human users. Other nodes serve only to route data. All nodes communicate with each other identically â there are no dedicated “clients” or “servers”. It is not possible for a node to rate another node except by its capacity to insert and fetch data associated with a key. This is unlike most other P2P networks where node administrators can employ a ratio system, where users have to share a certain amount of content before they can download.
Freenet may also be considered a small world network.
The Freenet protocol is intended to be used on a network of complex topology, such as the Internet (Internet Protocol). Each node knows only about some number of other nodes that it can reach directly (its conceptual “neighbors”), but any node can be a neighbor to any other; no hierarchy or other structure is intended. Each message is routed through the network by passing from neighbor to neighbor until it reaches its destination. As each node passes a message to a neighbor, it does not know or care whether the neighbor will forward the message to another node, or is the final destination or original source of the message. This is intended to protect the anonymity of users and publishers.
Each node maintains a data store containing documents associated with keys, and a routing table associating nodes with records of their performance in retrieving different keys.
This summary was written using the following sources:
[1] Freenet homepage
[2] Freenet papers
[3] Freenet wikipedia
Connecting to I2P
Posted by drakopoulos in Technical Details on April 19, 2012
The following tutorials were used to learn how to connect to the I2P network and how to implement any necessary configurations:
Installing on Windows:
http://www.youtube.com/watch?v=WyN_QK-_3GA
Further information can be found here.
Installing on Linux:
Installing on Apple OSX:
Network Selection
Posted by drakopoulos in Technical Details on April 19, 2012
Having examined the existing anonymous networks and discussing the options in a group meeting, we narrowed down our choices to either the TOR network or the I2P network. We then proceeded to examine the various strengths and weaknesses of the two networks, before finally settling upon I2P. Below are the technical factors that lead us to our choice:
- I2P is completely decentralized, unlike Tor where a âdirectoryâ of the network is maintained. Rather than building an essentially trusted, centralised system with directory servers, I2P has a self-organizing network database with each peer taking on the responsibility of profiling other routers to determine how best to exploit available resources.
- While Tor was designed with the intention to enable anonymous Internet browsing, I2P’s focus is to provide an anonymous network, isolated inside the Internet, offering various protocols and applications within. Furthermore, I2P is designed and optimised for “hidden services” (i.e. websites and other services hosted within I2P), and they are much faster than the corresponding ones on the Tor network, as the I2P network is fully distributed and self-organizing.
- Content hosted on networks such as Freenet are mostly static, whereas websites hosted within I2P can be fully dynamic
- I2P is fundamentally a packet switched network whereas Tor is fundamentally a circuit switched network. This allows I2P to transparently route around congestion and other network failures, operate redundant pathways and load balance the data across available resources.
- Although Tor is more popular and has significantly more funding than the I2P network, in recent times the network has become incredibly saturated and is more vulnerable. In contrast, the smaller size of I2P has allowed it thus far to float beneath the radar of government censors and malicious users.
- The unidirectional tunneling system used by I2P doubles the amount of nodes that a peer needs to compromise to get the same information that could be obtained from Tor’s bidirectional tunneling system. In addition to this, tunnels in I2P are short lived, decreasing the number of samples that an attacker can use to mount an active attack with, unlike circuits in Tor, which are typically long lived.
Architecture of I2P (the following section was taken from the technical documentation of I2P, located here):
How it works:
I2P uses bundled encryption over a multi-proxy like Tor. The packets are bounced all over the globe using I2P. However, the packets are encrypted with EIGamal and AES encryption. Using bundled encryption like this allows a packet to only decrypt the next hop as it passes through various nodes on its path. Once inside the network, IP addresses are not even used. Your node is assigned an address of garbled text to use an identifier.
I2P uses virtual, unidirectional tunnels that pass through a series of routers, and are typically 2 to 3 hops. Each round trip message and reply will require 4 tunnels. One for each the sender and receivers inbound/outbound traffic. Tunnels are created using what is known as âgarlic routingâ. A tunnel build message is sent via garlic routing to an I2P router requesting that it participate in a tunnel.
I2P makes a strict separation between the software participating in the network (a ârouterâ) and the anonymous endpoints (âdestinationsâ) associated with individual applications. The fact that somebody is running I2P isnât usually a secret. What is hidden is the information on what the user is doing as well as what router a particular destination is connected to. End users will typically have several local destinations on their router.
Tunnels:
A tunnel is a directional path through an explicitly selected list of routers. Layered encryption is used, so each of the routers can only decrypt a single layer. The decrypted information contains the IP of the next router, along with the encrypted information to be forwarded. Each tunnel has a starting point (the 1st router (gateway)) and an endpoint. Messages can only be sent one way. To send messages back, another tunnel is required.
Two types of tunnels exist:
- âOutboundâ tunnels send messages away from the creator.
- âInboundâ tunnels bring messages to the tunnel creator.
While the tunnels themselves have layered encryption to prevent unauthorized disclosure to peers inside the network (as the transport layer itself does to prevent unauthorized disclosure to peers in the network), it is necessary to add an additional end to end layer of encryption to hide messages from the outbound tunnel endpoint endpoint and the inbound tunnel gateway. This achieved by a process known as âgarlic routingâ.
Garlic Routing:
I2P uses an extension of the well-known onion routing approach, in which a message is routed from its originator to the final endpoint through several intermediate nodes using layered encryption. The originator adds to the message to be sent an encryption layer for every node in the path, each intermediate node peels off one of these layers, exposing routing instructions along with still-encrypted payload data, and finally the last node removes the final layer of encryption, exposing the original message to the endpoint. This process is called garlic routing, and allows to the originator include several messages in a single onion. I2P currently uses this approach to include the return destination for a given message as well as status messages.
The âinstructionsâ attached to each clove inside the encryption layer includes the ability to request that clove be forwarded locally, to a remote router, or to a remote tunnel on a remote router. There are fields in those instructions allowing a peer to request that a delivery be delayed until a certain time or condition has been met, though they wonât be honoured until the non-trivial delays are deployed.
Network Database (NetDB):
The NetDB uses a pair of algorithms which are used to share network metadata. The two types of metadata carried are ârouterinfoâ and âleasesetsâ â the routerinfo gives routers the data necessary for contacting a particular router (their public keys, transport address etc.) while the leaseset give routers the information necessary for contacting a particular destination. The full info contained in the leaseset is:
- Inbound gateway for a tunnel that allows reaching a specific destination.
- Time when a tunnel expires.
- Pair of public keys to be able to encrypt the messages (to send through the tunnel).
Routers themselves send their router information to the netDB directly, while leasesets are sent through outbound tunnels (leasesets need to be sent anonymously, to avoid correlating a router with his leaseset).
The following sources were used for this post:
The Onion Router (TOR)
Posted by taolu in Existing Similar Tools on April 18, 2012
Tor is a system intended to enable on-line anonymity, originally designed, implemented, and deployed as a third-generation onion routing project of the U.S. Naval Research Laboratory. It was originally developed with the U.S. Navy in mind, for the primary purpose of protecting government communications. Now tor has been used every day for a wide variety of purposes by normal people, the military, journalists, law enforcement officers, activists, and many others.
Tor helps to reduce the risks of both simple and sophisticated traffic analysis by distributing your transactions over several places on the Internet, so no single point can link you to your destination. The idea is similar to using a twisty, hard-to-follow route in order to throw off somebody who is tailing you â and then periodically erasing your footprints. Instead of taking a direct route from source to destination, data packets on the Tor network take a random pathway through several relays that cover your tracks so no observer at any single point can tell where the data came from or where it’s going.
To create a private network pathway with Tor, the user’s software or client incrementally builds a circuit of encrypted connections through relays on the network. The circuit is extended one hop at a time, and each relay along the way knows only which relay gave it data and which relay it is giving data to. No individual relay ever knows the complete path that a data packet has taken. The client negotiates a separate set of encryption keys for each hop along the circuit to ensure that each hop can’t trace these connections as they pass through. Once a circuit has been established, many kinds of data can be exchanged and several different sorts of software applications can be deployed over the Tor network. Because each relay sees no more than one hop in the circuit, neither an eavesdropper nor a compromised relay can use traffic analysis to link the connection’s source and destination. Tor only works for TCP streams and can be used by any application with SOCKS support. For efficiency, the Tor software uses the same circuit for connections that happen within the same ten minutes or so. Later requests are given a new circuit, to keep people from linking your earlier actions to the new ones.
Tor can’t solve all anonymity problems. It focuses only on protecting the transport of data. You need to use protocol-specific support software if you don’t want the sites you visit to see your identifying information. Tor does not provide protection against end-to-end timing attacks: If an attacker can watch the traffic coming out of your computer, and also the traffic arriving at your chosen destination, he can use statistical analysis to discover that they are part of the same circuit.
This summary was written using the following sources:
[1] Tor Homepage
[2]Â Wikipedia about Tor
[3] Tor wiki
Invisible Internet Project (I2P)
Posted by drakopoulos in Existing Similar Tools on April 17, 2012
I2P is an anonymizing network, offering a simple layer that identity sensitive applications can use to securely communicate. All data is wrapped with several layers of encryption, and the network is both distributed and dynamic, with no trusted parties. I2P is designed to allow peers using I2P to communicate with each other anonymously â both sender and receiver are unidentifiable to each other as well as to 3rd parties. It can be used for anonymous: web surfing, chatting, blogging and file transfers.
The I2P network, a low-latency message oriented anonymous network was mainly designed to allow a fully anonymous conversation between two parties with the I2P network limits. The network itself is strictly message based (like IP), but there is a library available to allow reliable streaming communication on top of it (like TCP).
ALL communication is end-to-end encrypted (total of 4 layers of encyption) and even end-points are cryptographic identifiers (public keys) so that neither sender nor recipient of a message need to reveal their IP address to the other side (or to 3rd parties).
The network is formed of a group of routers. A router runs the software that allows any application to communicate through I2P. Applications running on top of it will have a destination associated, which receives incoming connections from third parties. The secret lies in which destination is associated to which router and not in the fact that a user is running an instance of the router. This uncoupling between the router and the destinations provides a certain degree of anonymity. The decentralized nature of the network prevents a single point of failure and adds another element of anonymity, as every client also acts as a server on the network.
The network itself is message oriented, in other words it is essentially a secure and anonymous IP layer, where messages are cryptographic keys (destinations) and can be significantly larger than IP packets. Furthermore, I2P has no official entry/exit points (in contrast to Tor), all peers participate in the mix, and there isnât any network layer in or out proxies (however at the application layer, a few proxies exist).
How it works:
I2P uses bundled encryption over a multi-proxy like Tor. The packets are bounced all over the globe using I2P. However, the packets are encrypted with EIGamal and AES encryption. Using bundled encryption like this allows a packet to only decrypt the next hop as it passes through various nodes on its path. Once inside the network, IP addresses are not even used. Your node is assigned an address of garbled text to use an identifier.
I2P uses virtual, unidirectional tunnels that pass through a series of routers, and are typically 2 to 3 hops. Each round trip message and reply will require 4 tunnels. One each for the sender and receiverâs inbound/outbound traffic. Tunnels are created using what is known as âgarlic routingâ. A tunnel build message is sent via garlic routing to an I2P router requesting that it participate in a tunnel.
I2P makes a strict separation between the software participating in the network (a ârouterâ) and the anonymous endpoints (âdestinationsâ) associated with individual applications. The fact that somebody is running I2P isnât usually a secret. What is hidden is the information on what the user is doing as well as what router a particular destination is connected to. End users will typically have several local destinations on their router.
This summary was written using the following sources:
[1] I2P Homepage
[2] I2P Tech Intro
[3] I2P Tunnel
[4] Getting Started On The I2P Darknet
[5] I2P – The *other* Anonymous Network