My Volunteer presentation from 11/11/09 on Distributed Javascript - ... cript.pptx

[ add comment ] ( 6 views )   |  permalink
Screenshots & Test Cases 
The following screenshot is the output of my basic test code. The beginning is the automatic directory loading, and then the last line is the string output of my HiddenService object (the one that represents the service host). More details can be read about what the different variables represent and how they are calculated can be found in the specs: or my notes:

All this code can be found at my github

The output is as follows:

[11/11/09 4:40 PM] DEBUG: Adding trusted authority: (Directory: moria1 fingerprint=ffcb46db1339da84674c70d7cb586434c4370441 v3ident=e2a2af570166665d738736d0dd58169cc61d8a8b) [11/11/09 4:40 PM] DEBUG: Adding trusted authority: (Directory: moria2 fingerprint=719be45de224b607c53707d0e2143e2d423e74cf) [11/11/09 4:40 PM] DEBUG: Adding trusted authority: (Directory: tor26 fingerprint=847b1f850344d7876491a54892f904934e4eb85d v3ident=14c131dfc5c6f93646be72fa1401c02a8df2e8b4) [11/11/09 4:40 PM] DEBUG: Adding trusted authority: (Directory: dizum fingerprint=7ea6ead6fd83083c538f44038bbfa077587dd755 v3ident=e8a9c45ede6d711294fadf8e7951f4de6ca56b58) [11/11/09 4:40 PM] DEBUG: Adding trusted authority: (Directory: Tonga fingerprint=4a0ccd2ddc7995083d73f5d667100c8a5831f16d) [11/11/09 4:40 PM] DEBUG: Adding trusted authority: (Directory: ides fingerprint=f397038adc51336135e7b80bd99ca3844360292b v3ident=27b6b5996c426270a5c95488aa5bceb6bcc86956) [11/11/09 4:40 PM] DEBUG: Adding trusted authority: (Directory: gabelmoo fingerprint=68333d0761bcf397a587a0c0b963e4a9e99ec4d3 v3ident=81349fc1f2dba2c2c11b45cb9706637d480ab913) [11/11/09 4:40 PM] DEBUG: Adding trusted authority: (Directory: dannenberg fingerprint=7be683e65d48141321c5ed92f075c55364ac7123 v3ident=585769c78764d58426b8b52b6651a5a71137189a) [11/11/09 4:40 PM] DEBUG: Adding trusted authority: (Directory: urras fingerprint=0ad3fa884d18f89eea2d89c019379e0e7fd94417 v3ident=80550987e1d626e3eba5e5e75a458de0626d088c)

Hidden Service: JTor Test hidden service:6112-6120 Permanent ID : 1C04EEF2CFCFEA948C3C Service Descriptor : 2631362A025C773CD5B00F8343E5427CE07F711B Tor Public Key: bd56e37e79e7311bb665e2861f4d744866794c6a

This is just the server side of the Hidden Services, and I still need to implement the Rendezvous point circuits. And then I will have to finish the client side as well. After that, sufficient testing would be providing a service with the jTor hidden services, and then trying to connect to it not using the jTor client and vice versa. That would ensure workability as well as compatibility with the other versions of the client.

[ add comment ] ( 6 views )   |  permalink
Article Review 4 

Article Review:
Multi-Level security in tightly coupled military systems:
Virtualization as a path to MLS
From: Matt Anders

Target Audience
The military, or people interested in high security for large
systems. It is informative so it could be for any person who
stumbles upon it - but I don't think someone would be interested
in this unless he/she likes security and/or is part of the

Type of Document
This is an informative document created by academic
professionals. It is brief, but to the point about their
comparisons of virtualization and MLS.

Summary of Article
compares and contrasts virtualization to MLS. They do this by
comparing and contrasting certain elements about the two, their
goal and how they isolate data. The isolation of data is
certainly stressed in this article, because it is their measure
of security. Their solution to what each of these don't have is
the RapidIO network protocol. In their conclusion they claim
that RapidIO could bring security to traditional and virtualized

This is a good informative document about Virtualization and
Multi-Level Security - their differences and similarities, goals
and how they work; however it is mostly a plug for the RapidIO
network protocol.

[ add comment ] ( 22 views )   |  permalink
Article Review 3 
Daniel Priece: ... e/csc8530/

Target Audience
This is targeted at professionals more than it is academics. The application of the technology that surrounds this article mostly seems applicable in a infrastructure business setting.

Type of Document
This document is a Journal article. It explores multiple ways on paralellizing legacy code and the pros and cons of each way. It is somewhat an instructional article and also an educational article.

Summary of Article
Companies with legacy code would like to find a way to easily parallelize that code, but it is not such an easy task. In many cases, the most robust way is to rewrite an architecture to interface over the legacy code and make it thread safe from the bottom up. But this of course requires a reconstruction of the system. Another approach is to distribute the most computationally intensive parts of the legacy code. The article goes into some suggested hardware specs for distributing. This article then summarizes the Fine Grained Distributed Processing approach for parallelizing legacy code.

The Fine Grained Distributed Processing approach is a good approach if you want an easy way to parallelize legacy code. However, there are certain constraints to which this approach works. These constraints are the message length and how easy it is to create a message. But if there is relatively simple message passing in legacy code then The Fine Grained Distributed Processing approach would be a good choice for doing so.

[ add comment ] ( 22 views )   |  permalink
Project Part 2 - Hidden Services implementation overview 
personal public git repository for JTor

Javadocs for hiddenservice package

As part of JTor, the Java Tor Protocol library, I have decided to take on a specific part of the Tor protocol, the hidden services. Say that someone wants to offer a service - web server, chat server, any kind of server/service - but they want their IP to remain anonymous. Tor hidden services allows this.

Because this is a Java library, my goal is to make my code easily usable for people who want to establish a hidden service connection. I will provide an interface for developers who want to incorporate Hidden Services into their program or for alternative Tor clients and protocols.

This problem can be split into two different parts - the Server(Bob) and the Client(Alice). Before this can happen, Bob needs to initialize the service.

  • Bob initializes the Hidden Service with a service name and a port range
  • A public/private key pair is generated for encryption via the hidden service.
  • descriptor-id = H(permanent-id | H(time-period | descriptor-cookie | replica)) - where H(x) is the SHA1 digest of x
  • Bob then establishes introduction points which are also encoded in the Service Descriptor
  • Service descriptor is sent to Tor directory service (advertised) - Bob keeps circuits open to introduction points and waits for connections

Now, the hidden service is available for Alice to connect to:

  • Alice obtains the onion address
  • Alice queries directory services for onion address (x).(y).z.onion
  • Alice obtains the address's ServiceDescriptor
  • Alice sets up rendezvous points to one or more of the advertised introduction points
  • Circuit is established: Alice sends requests to Bob and Bob responds.

Important Algorithms:

  • correct encryption and encoding
  • managing cmultiple circuit connections
  • time synchronization (time-period = (current-time + permanent-id-byte * 86400 / 256) / 86400)
  • maintaining & generating unique identifiers

For more information, please refer to Tor's Hidden Service Spec or my notes about Hidden Services.

[ add comment ] ( 17 views )   |  permalink

<Back | 1 | 2 | 3 | Next> Last>>