Hello, dear friend, you can consult us at any time if you have any questions, add WeChat: THEend8_
CS 550
Programming Assignment
SECTION 1: The problem
This project builds on the previous projects. The goal of this project is to add RSA encryption to a
hierarchical Gnutella-style P2P file sharing system.
The idea is simple:
1. You will build RSA encryption into your push-based Gnutella P2P system.
2. All peers (and superpeers) should have unique RSA keypairs
3. You may transmit your public key to your superpeer in plaintext.
4. All communications except the transmission of a peer’s public key to it’s superpeer must be
RSA encrypted, including all messages, broadcasts, and file downloads.
You are free to use any programming languages (e.g., C/ C++ or Java) and any abstractions such as
sockets, RPCs, RMIs, threads, events, etc. that might be needed. Your code must run on the
provided Vagrant system, and you must give explicit installation instructions. But otherwise, you have
design freedom.
You may not use any pre-built packages to implement your RSA encryption. Key generation
can be done in your application, or via an external application such as ssh-keygen or openssl.
In Java, you may use java.math.BigInteger and java.security.SecureRandom, but nothing else in the
java.security, java.crypto, or related classes. In Python, you may not use any pre-made RSA
packages, key generators, cryptographic packages, or so on.
See PA3 for details on the push-based approach to consistency within a Gnutella-style P2P file
sharing system.
Below is a list of what you need to implement:
PA3, 1
1. Generation of keys
2. Public key sharing at connection establishment.
3. RSA encryption/decryption not using any pre-built packages, code, or systems – you must
build your RSA algorithm yourself!
4. All messages and communications between peers and superpeers must be encrypted except
initial sharing of the public key. This includes communication establishment between peers.
5. You do not need to store the file encrypted; only communications must be encrypted, not
storage
6. As before, peers must be able to request files for download using the push-based consistency
scheme implemented in PA3.
7. Ensure your code runs on the provided Vagrant system. For information on how to use
Vagrant, visit their website at https://www.vagrantup.com/. It works on all standard operating
systems. If your code does not run on the provided Vagrant system, it cannot be
graded. You can install packages as described in your manual, but everything must work from
the command line in this environment.
Other requirements:
● No GUIs are required.
● You will be given a Vagrant file that will build your test environment. Ensure your code
runs in this environment before submission, as it will be used to grade your code.
SECTION 2: Evaluation and Measurement
Use the same topology as in PA3. Each leafnode has in its shared directory at least 10 text files of
varying sizes (for example 1k, 2k, …, 10k). For this assignment, all text files must be English plaintext;
feel free to use repetitive text, I recommend this site for text generation.
Do the following experiments:
1. Use a system like TCPdump to ensure your inter-peer communications are actually encrypted
over the wire, including the entire establishment process
PA3, 2
2. Have some switchable (on/off) debugging printout system in place to have peers print at least
part of their message before and after encryption/decryption so you can show your RSA algorithm is
doing its job.
1. Ex, the peer prints its message in plaintext, its encrypted message, and the recipient
peer prints its ciphertext followed by the decrypted plaintext
SECTION 3: What you will submit
When you have finished implementing the complete assignment as described above, you should
submit your solution to ‘digital drop box’ on blackboard.
Each program must work correctly and be detailed in-line documented. You should hand in:
1. Output file: A copy of the output generated by running your program. When it downloads a
file, have your program print a message “display file ‘foo’” (don’t print the actual file contents if
they are large). When a leaf-node issues a query (lookup) to the indexing server, having your
program print the returned results in a nicely formatted manner.
2. Design Doc: A separate (typed) design document (named design.pdf) of approximately 2-4
pages describing the overall program design, , and design tradeoffs considered and made.
Also describe possible improvements and extensions to your program (and sketch how they
might be made).
3. Source code: All of the source code and a program listing containing in-line documentation.
4. Manual: A detailed manual describing how the program works. The manual should be able to
instruct users other than the developer to run the program step by step. The manual should
contain at least a test case which will generate the output matching the content of the output
file you provided in 1.
5. Verification: A separate description (named test.pdf) of the tests you ran on your program to
convince yourself that it is indeed correct. Also describe any cases for which your program is
known not to work correctly.