Meeting Minutes

Meeting Minutes

Meeting #1

Ice Breakers n' Chill

Meeting #2

Core design notions for the onion routing implementation:

• Only initiator knows the whole virtual circuit (VC) node-chain

• Responder doesn't have to know initiator in advance

• The goal of onion routing is not anonymity per se, but rather to prevent third parties from knowing end-points (which know each other)

• Onion structure: VCID | COMMAND (setup/data/destroy) | DATA (fwd/bkwd)

  • VCID: Unique, given by directory to initiator
  • Command: Type of onion
    • Create → Each node setps up VCID with fwd/bkwd functions and encryption keys
    • Data → Each node applied fwd/bkwd function through given VCID
    • Destroy → Each node removed VCID from its record, the initiator informs Directory node about released VCID

• Communication sequence: Preconditions: Directory previously has communicated with all nodes in network, obtains their **symmetrical **encryption keys

  1. Initiator requests path to responder from Directory
  2. Directory returns ordered sequence of symmetrical keys of randomly chosen nodes
  3. Initiator builds setup onion, responder now has information regarding VC
  4. Initiator sends data onion
  5. Either endpoint sends teardown onion

• Size of the onion remains constant through nodes → padding

• Reply onion:

  • For when VC is no longer available
  • Sent by initiator to responder, its preformed by initiator with all info required by responder to setup a VC

• EXTRAS: TTL and Duplicate handling

Meeting #3

• Procedure for testing:

  1. Initial scripts for setting up nodes.
  2. Run specific code (python file).
  3. Read log files or use wire shark for debugging.

• Setting up nodes:

  • Procedure:
    1. Remote login to one node.
    2. From the first node, SSH in a loop to all the other nodes.
    3. Delete and then clone the code from the specified branch repository onto all the nodes.
  • Notes: The script will take command line arguments for which branch to clone and what port to use.

Meeting #4

• Code will be done by Wednesday November 15.
• Video deadline extended to November 24.
• Until the code is done, testing team will test raw packages. This includes getting the data, seeing how many machines can be used, how many messages can be sent and the time taken to send/receive the messages (os.time).
• Use wireshark to listen to ports.

Meeting #5

• Tests that should be done
  1. Encryption: use Tshark to show perspective as someone from outside
  2. Make python scripts for timing
  3. Does it expand to multiple clients
  4. Length of message
• Video scripts should done by Monday evening