CS 550, Spring 2020
Programming Assignment 4
Securing your Hierarchical Gnutella-Style P2P System using RSA Encryption
Submission:
● Due by 11:59pm of 1 May 2020
● Late submissions will not be accepted!
● You may work individually or in groups of two for this assignment. For the groups with 2
members, only one submission listing both members is needed.
● Please upload your assignment on the Blackboard with the following name: Section_
LastName_FirstName_PA4
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.
6. Problem report: if your code does not work or does not work correctly, you should report this.
All documents must be typed and submitted in PDF form. Put all of the above into one .zip or .tar file,
and upload it on blackboard. The name of .zip or .tar should follow this format:
Section_LastName_FirstName_PA#.zip.
4. Grading policy for all programming assignments
● Source Code and Program Listing
PA3, 3
o works correctly ————- 50%
o in-line documentation ——– 15% ● Design Document
o quality of design ———— 15%
o understandability of doc ——- 10% ● Thoroughness of test cases ———- 10%
As much time as possible has been allocated for this assignment. No programs will be accepted past the due date for this assignment. There will be no extensions or exceptions.
PA3, 4