298 lines
15 KiB
Plaintext
298 lines
15 KiB
Plaintext
$NetBSD: patch-ae,v 1.1.1.1 2003/06/05 01:00:47 jschauma Exp $
|
|
|
|
This document created from "waste design.doc" using antiword
|
|
|
|
--- /dev/null 2003-05-31 12:24:31.000000000 -0400
|
|
+++ README 2003-05-31 12:24:37.000000000 -0400
|
|
@@ -0,0 +1,290 @@
|
|
+
|
|
+
|
|
+WASTE.doc v1.0
|
|
+
|
|
+5/28/03
|
|
+(this .doc is just a basic overview about how WASTE works)
|
|
+
|
|
+
|
|
+
|
|
+
|
|
+What is WASTE?
|
|
+
|
|
+
|
|
+WASTE is a tool that is designed to permit secure distributed collaboration
|
|
+and communications for small trusted groups of people. WASTE allows users
|
|
+to communicate and transfer information easily and effortlessly. WASTE
|
|
+requires very little administration, and no central server or central
|
|
+administration is required.
|
|
+
|
|
+Currently the amount of setup required for each user is significant that
|
|
+WASTE is designed for the more computer-literate users or "power users".
|
|
+Having said this, it's worth noting that the audience of WASTE is not
|
|
+limited to such users, as these users are "tastemakers" and will help their
|
|
+less experienced friends get set up.
|
|
+
|
|
+What kind of functionality does WASTE enable?
|
|
+
|
|
+WASTE provides a generic virtual secure private network that other services
|
|
+can be built upon. Currently the following services have been implemented
|
|
+for use on the network and are very functional:
|
|
+Instant Messaging - allows users to communicate with other users on a
|
|
+private WASTE network in much the same way as when using AIM/ICQ/etc. This
|
|
+feature is primarily accessed through the main WASTE window.
|
|
+Group chat - allows two or more users to chat on a WASTE network in much
|
|
+the same way as when using AIM/ICQ/IRC/etc. This feature is primarily
|
|
+accessed through the main WASTE window.
|
|
+Distributed presence - allows users to see what other users are currently
|
|
+on a private WASTE network. This feature is primarily accessed through the
|
|
+main WASTE window, and facilitates ease in Instant Messaging.
|
|
+File browsing - allows users to browse a virtual directory structure for
|
|
+each user on the network. Each user can specify a list of directories to
|
|
+make available to other users on the network. This feature is primarily
|
|
+accessed through the WASTE Browser window.
|
|
+File searching - allows users to search other users' databases. Each user
|
|
+can specify a list of directories to make available to other users on the
|
|
+network. Currently searching for filenames and directory names is all that
|
|
+is supported, but full-text searching and meta-searching would be easily
|
|
+added. This feature is primarily accessed through the WASTE Browser window.
|
|
+
|
|
+File transfer - allows users to transfer files to or from other users.
|
|
+Files can be found via the file browsing and file searching features, or
|
|
+files can be uploaded to other users manually. This feature is accessed
|
|
+through many interfaces, and can be managed with the WASTE File Transfer
|
|
+window.
|
|
+Key distribution - allows hosts on the WASTE network to exchange public
|
|
+keys so that they can directly connect to each other (which helps the
|
|
+network optimize itself)
|
|
+
|
|
+Many other services and capabilities can be added to the WASTE network,
|
|
+these are just the basics that have been implemented.
|
|
+
|
|
+How does WASTE enable these services?
|
|
+
|
|
+WASTE routes all data through a distributed ad-hoc network. The network
|
|
+structure can adapt for traffic, and is fairly organized based on capacity.
|
|
+When moving large amounts of data, the network is redundant and load-
|
|
+balanced (though the load balancing is currently sub-optimal, it does
|
|
+work). Because all data transfer is accomplished through this distributed
|
|
+network, firewalls do not impair function as long as there are sufficient
|
|
+hosts on the network that are accessible from everywhere.
|
|
+
|
|
+WASTE keeps the private network private by only connecting or allowing
|
|
+connections between known users, and by using strong encryption to secure
|
|
+those links.
|
|
+
|
|
+Once a WASTE network is up, users do not have to worry about IP addresses
|
|
+to connect to, firewalled machines, or other network topologies. As long as
|
|
+the user can connect to any other host on the WASTE network, the user can
|
|
+access all of the services of the WASTE network. All of this happens
|
|
+automatically.
|
|
+
|
|
+WASTE network architecture
|
|
+
|
|
+WASTE is built upon an underlying distributed network architecture that is
|
|
+similar to that of Gnutella. It consists of a distributed "peer to peer"
|
|
+network that allows communication between hosts based on the model of
|
|
+broadcast request routed reply, where a host sends out a broadcast message
|
|
+to the network, and zero or more hosts send routed replies that follow the
|
|
+path of the broadcast message back to the sender. WASTE uses 128 bit IDs
|
|
+for each new broadcast message, so that each node can track which broadcast
|
|
+messages it has seen, and so that it can route routed messages back to
|
|
+where the original broadcast message came from. Due to the logic of each
|
|
+node on the network, if there are multiple paths to a particular node from
|
|
+another node, the path that took the least time to broadcast is used for
|
|
+the routed reply.
|
|
+
|
|
+Nodes on the WASTE network can decide whether or not to rebroadcast or
|
|
+route traffic based on their connection type (modem nodes communicating
|
|
+with nodes on T1s/DSL will generally not want to route).
|
|
+
|
|
+Each node organizes a queue of messages for each connection, and
|
|
+prioritizes messages in the queue as appropriate for optimal network
|
|
+performance.
|
|
+
|
|
+WASTE has a basic protocol for sending messages that involves the following
|
|
+information per message:
|
|
+16 byte MD5 of message
|
|
+ For verifying the integrity of the messages
|
|
+1 byte TTL of message
|
|
+ Used to prevent broadcast messages from saturating the network in the
|
|
+ rare instance where multiple hosts have their routing tables
|
|
+ overflowed, or a slow node gets very far behind in broadcasting.
|
|
+1 byte message priority
|
|
+ Tells how to prioritize the message in sending (0=highest, 255=lowest)
|
|
+4 byte message type
|
|
+ Contains information on what kind of message this is, as well whether
|
|
+ or not it is a broadcast message, routed message, or local message.
|
|
+2 byte message length (max of 32kb for routed messages, 2kb for broadcast
|
|
+messages)
|
|
+16 byte (128 bit) message ID
|
|
+<message length bytes> message data, dependent on the message type
|
|
+
|
|
+
|
|
+WASTE service implementations
|
|
+
|
|
+WASTE currently provides numerous basic services for users on the network.
|
|
+Here are basic descriptions of how each service is implemented:
|
|
+
|
|
+Instant Messaging - text messages are broadcasted on the WASTE network,
|
|
+with information on the sender and the recipient. Routed replies inform the
|
|
+sender of the instant message when the recipient has received the message,
|
|
+and how long it took to go round trip.
|
|
+Group chat - text messages are broadcasted on the WASTE network, with
|
|
+information on the sender and the destination channel name. Automated
|
|
+notification messages, such as when a user joins or parts a channel, are
|
|
+sent via the same means. Routed replies are sent when a user receives a
|
|
+channel message, so that the sender can see who on the channel has gotten
|
|
+the message, and if not, the client can determine that the user has "pinged
|
|
+out".
|
|
+Distributed presence - Two methods are used to let each user have a
|
|
+reliable prediction of who is on the network at any given time. The first
|
|
+method consists of each user periodically broadcasting (especially on each
|
|
+new connection brought up) its existence on the network, so that other
|
|
+users can see when a new user comes on, and detect when the user is no
|
|
+longer broadcasting their existence. The second method is a user can send a
|
|
+broadcast message to request replies with user names. This allows a user to
|
|
+quickly get a full list of who is on the network. Users detect when other
|
|
+users go offline when no activity from that user has been seen in a
|
|
+specified amount of time.
|
|
+File browsing - File browsing is accomplished by sending a broadcast
|
|
+message with a browse path to the network, to which each host may send
|
|
+routed replies with any results it may have.
|
|
+File searching - File searching is accomplished by sending a broadcast
|
|
+message with a search specification to the network, to which each host may
|
|
+send routed replies with any results it may have.
|
|
+File transfer - Efficiently implementing file transfer is a bit more
|
|
+complex than the other services, but it also demonstrates the flexibility
|
|
+of the underlying network architecture.
|
|
+
|
|
+ When a node wishes to download a file (or portion of a file) from
|
|
+ another node, the requesting node broadcasts a message with
|
|
+ information on which file it is requesting (including host ID, length,
|
|
+ file index, filename hash, etc), which portions of the file it wants
|
|
+ sent (in 4kb blocks, up to 64 per request (these are run-length
|
|
+ encoded for size considerations), and so on.
|
|
+
|
|
+ When a node that has the file receives the broadcast message
|
|
+ requesting a file, it routes one or more replies, that include
|
|
+ information on the file that it is sending, and up to 64 of the 4k
|
|
+ blocks of the file. If the file is larger than 64 blocks, or if any of
|
|
+ the blocks are lost during transit (which the receiver can detect by
|
|
+ timing out or other means), then the receiver can request more blocks
|
|
+ (when it does so, it also includes information on what the last
|
|
+ request was, so that the sender can efficiently manage the download).
|
|
+ Because each request for more blocks consists of a new broadcast
|
|
+ message, the route that blocks get sent back to the receiver can
|
|
+ change throughout the transmission of a file.
|
|
+
|
|
+ The sender and receiver in a file transfer can compute SHA-1 hashes of
|
|
+ the file data, to ensure reliable transfer.
|
|
+
|
|
+ Finally, to accomplish an upload, the sender sends a broadcast message
|
|
+ to the recipient requesting the upload, which the recipient can
|
|
+ optionally accept. Once the recipient accepts the upload, the
|
|
+ recipient downloads the file as it would any other.
|
|
+
|
|
+Key distribution - WASTE also distributes public keys for connection
|
|
+negotiation by periodically broadcasting them on the network. If a host
|
|
+encounters a new public key on the network, it can optionally accept it
|
|
+(often with user approval), and can optionally send a routed reply to the
|
|
+message with its own public key.
|
|
+
|
|
+
|
|
+
|
|
+
|
|
+
|
|
+WASTE network design limitations
|
|
+
|
|
+
|
|
+The underlying design of the WASTE network and the basic services that run
|
|
+on it requires that the following conditions be met for the WASTE network
|
|
+to function well:
|
|
+The number of nodes on the network should be small, since the amount of
|
|
+traffic on the network scales more than linearly with the number of users.
|
|
+Each node on the network should trust other users on the network, since
|
|
+messages are inherently broadcasted (often unnecessarily) to many nodes on
|
|
+the network, and data is routinely routed through other nodes on the
|
|
+network.
|
|
+
|
|
+
|
|
+WASTE cryptography
|
|
+
|
|
+Since WASTE requires a small trusted network to function efficiently, it
|
|
+benefits greatly from cryptography. Using public-key encryption for session
|
|
+key negotiation and user authentication allows both the prevention of
|
|
+unknown users from joining the network as well link data security to
|
|
+prevent unknown users from "sniffing" network traffic.
|
|
+
|
|
+WASTE also provides for an additional "network name or ID" that can be used
|
|
+to secure a network against people who do not have the name or ID. This can
|
|
+be useful if you wish to easily prevent multiple networks from merging, or
|
|
+change it to easily remove access of user(s) without having to make
|
|
+everybody ban those user(s) public keys.
|
|
+
|
|
+WASTE uses a (hopefully) cryptographically secure random number generator
|
|
+based on the implementation in the RSA reference code. The code uses a 32
|
|
+byte state, with 16 bytes of counter and 16 bytes of system entropy
|
|
+constantly mixed in, and produces random values by using MD5.
|
|
+
|
|
+WASTE connections use RSA (with 1024 bit or greater public key sizes) for
|
|
+exchange of 56 byte Blowfish session keys, and 8 byte PCBC initialization
|
|
+vectors.
|
|
+
|
|
+The link connection negotiation, where A is connecting to B, goes something
|
|
+like this:
|
|
+
|
|
+ 1. A sends B 16 random bytes (randA), or blowFish(SHA(netname),randA) if
|
|
+ a network name is used.
|
|
+ 2. A sends B blowFish(randA, 20 byte SHA-1 of public key + 4 pad bytes).
|
|
+ 3. B decrypts to get the SHA-1 of A's public key.
|
|
+ 4. If B does not know the public key hash sent to it, B disconnects.
|
|
+ 5. B sends A 16 random bytes (randB), or blowFish(SHA(netname),randB) if
|
|
+ a network name is used.
|
|
+ 6. B sends A blowFish(randB,20 byte SHA-1 of public key + 4 pad bytes).
|
|
+ 7. A decrypts to get the SHA-1 of B's public key.
|
|
+ 8. If A does not know the public key hash sent to it, A disconnects.
|
|
+ 9. A looks up B's public key hash in A's local database to find B's
|
|
+ public key (pubkey_B).
|
|
+ 10. A generates sKeyA, which is 64 random bytes.
|
|
+ 11. If a network name is used, A encrypts the first 56 bytes of sKeyA
|
|
+ using the SHA-1 of the network name, to produce EsKeyA. Otherwise,
|
|
+ EsKeyA is equal to sKeyA.
|
|
+ 12. A sends B: RSA(pubkey_B,EsKeyA + randB) (+ = concatenated).
|
|
+ 13. B looks up A's public key hash in B's local database to find A's
|
|
+ public key (pubkey_A).
|
|
+ 14. B generates sKeyB, which is 64 random bytes.
|
|
+ 15. If a network name is used, B encrypts the first 56 bytes of sKeyB
|
|
+ using the SHA-1 of the network name, to produce EsKeyB. Otherwise,
|
|
+ EsKeyB is equal to sKeyB.
|
|
+ 16. B sends A: RSA(pubKey_A, EsKeyB + randA), (+ = concatenated).
|
|
+ 17. A decrypts using A's private key, and verifies that the last 16 bytes
|
|
+ are equal to randA.
|
|
+ 18. B decrypts using B's private key, and verifies that the last 16 bytes
|
|
+ are equal to randB
|
|
+ 19. If a network name is used, A decrypts the first 56 bytes of sKeyB
|
|
+ using the SHA-1 of the network name.
|
|
+ 20. If a network name is used, B decrypts the first 56 bytes of sKeyA
|
|
+ using the SHA-1 of the network name.
|
|
+ 21. Both A and B check to make sure that the first 56 bytes of sKeyA does
|
|
+ not equal the first 56 bytes of sKeyB. If they do (which is
|
|
+ statistically unrealistic and would lead one to believe it is an
|
|
+ attack), they disconnect.
|
|
+ 22. Both A and B check to make sure the final 8 bytes of sKeyA differs
|
|
+ from the final 8 bytes of sKeyB. If they are equal, disconnect.
|
|
+ 23. A uses the first 56 bytes of sKeyA XOR sKeyB to initialize Blowfish
|
|
+ for send and receive. A uses the final 8 bytes of sKeyA as the PCBC IV
|
|
+ for send, and the final 8 bytes of sKeyB as the PCBC IV for receive.
|
|
+ 24. B uses the first 56 bytes of sKeyA XOR sKeyB to intialize Blowfish for
|
|
+ send and receive. B uses the final 8 bytes of sKeyB as the PCBC IV for
|
|
+ send, and the final 8 bytes of sKeyA as the PCBC IV for receive.
|
|
+ 25. All further communications in both directions are encrypted using the
|
|
+ initialized Blowfish keys and PCBC IVs.
|
|
+ 26. A sends B the constant 16 byte signature ("MUGWHUMPJISMSYN2")
|
|
+ 27. B decrypts verifies the signature
|
|
+ 28. B sends A the constant 16 byte signature ("MUGWHUMPJISMSYN2")
|
|
+ 29. A decrypts and verifies the signature
|
|
+ 30. Message communication begins (each message uses a MD5 to detect
|
|
+ tampering - if detected, connection is dropped)
|
|
+
|
|
+
|