Assignment 2: Asymmetric Cryptography

• Download Files ⇓
• Submit Files ⇑

Introduction

In this assignment, you will add functionality to the code you wrote for Assignment 1, toward the goal of implementing a secure facility for client-server communication across the Internet.

As before, we will give you some of the code you need, and we will ask you to provide certain functions missing from the code we provide. As before, you must not use any cryptography libraries; the only cryptographic primitives you may use are the ones we gave you, and ones you implemented from scratch yourself.

In this assignment you will implement three classes, by modifying three Java code files:

1. You will modify RSAKeyPair.java to implement RSA key-pair generation.
2. You will modify RSAKey.java to implement secure RSA encryption and decryption, and to create and verify digital signatures.
3. You will modify KeyExchange.java to implement secure key exchange.

As in the previous assignment, we have provided you with code files in which some parts are stubbed out. You will replace the stubbed out pieces with code that actually works and provides the required security guarantee. We have put a comment saying IMPLEMENT THIS everywhere that you have to supply code.

Your solution will build on the functionality that you implemented for Assignment 1, but we will test your solution with our own implementation of the Assignment 1 functionality. Your solution must work correctly when we do this — this shouldn’t be a problem as long as you respect the API boundaries between the different classes we have given you. To help you mimic the testing setup that we will use, we are providing a pre-compiled JAR file (library) containing our reference solution to Assignment 1. We recommend that you use this instead of your own solution to Assignment 1.

Objectives

• Understand how asymmetric cryptography works.

RSAKeyPair.java

Your RSAKeyPair class should implement the following API:

public class RSAKeyPair {
   public RSAKeyPair(PRGen rand, int numBits)
   public RSAKey getPublicKey()                 // already implemented
   public RSAKey getPrivateKey()                // already implemented
   public BigInteger[] getPrimes()
}

For RSAKeyPair, the bulk of the interesting work is performed by the constructor. This constructor should create an RSA key pair using the algorithm discussed in class. The constructor will use the PRGen rand argument to get bits from a pseudo-random generator. The numBits argument is the size in bits of each of the primes that will be used. The key pair should be stored as a pair of RSAKey objects (see next section for more information on RSAKey).

The getPrimes() method helps with the grading process. Invoking getPrimes() should return the two primes that were used in key generation. The primes may be returned in either order in a BigInteger array of length 2. Note that in the real-world implementation, you would not need to have a method to return these primes.

RSAKey.java

Your RSAKey class should implement the following API:

public class RSAKey {
   public RSAKey(BigInteger theExponent, BigInteger theModulus)
   public BigInteger getExponent()
   public BigInteger getModulus()
   public byte[] encrypt(byte[] plaintext, PRGen prgen)
   public byte[] decrypt(byte[] ciphertext)
   public byte[] sign(byte[] message, PRGen prgen)
   public boolean verifySignature(byte[] message, byte[] signature)
   public int maxPlaintextLength()
   public byte[] encodeOaep(byte[] input, PRGen prgen)
   public byte[] decodeOaep(byte[] input)
   public byte[] addPadding(byte[] input)
   public byte[] removePadding(byte[] input)
}

The RSAKey class implements core RSA functions, namely encryption/decryption as well as signing/verification. Note that the RSAKey class is used for both public and private keys, even though some key/method combinations are unlikely to be used in practice. For example, it is unlikely that the sign() method of a public RSAKey would ever be used.

The encrypt() method should encrypt the plain text using optimal asymmetric encryption padding (OAEP) as discussed in class. It is not enough to simply compute modular exponentiation on the plain text. Your code for OAEP encoding and decoding should be in the provided encodeOaep() and decodeOaep() methods. Your other methods should call these utility methods to encode/decode when necessary. When decodeOaep() fails integrity checks, it should reveal this by returning null or throwing an exception. For full credit, don’t forget to pad the input to the OAEP algorithm if it is too short – this is necessary to guarantee security (otherwise the exponentiated message might be smaller than the modulus).

The sign() method should generate a signature (array of bytes) that can be verified by the verifySignature() method of the other RSAKey in the private/public RSAKey pair. In the sign() method, you should not include the message as part of the signature; assume that the verifier will already have access to this message. This assumption of access is reflected in the API for verifySignature(), which accepts the message as one of its arguments.

Note that the encrypt(), sign(), and encodeOaep() methods take a PRGen object as a parameter, in case the implementation wants to use bits from a pseudo-random generator. The decrypt() method should correctly decrypt the cipher text.

The maxPlaintextLength() method should return the largest \(\ell\) such that any plain text of size \(\ell\) bytes can be encrypted with this key and padding scheme. Your code must correctly operate on plain texts that are any size less than or equal to the size returned by maxPlaintextLength().

The addPadding() and removePadding() methods are used to pad the input to the OAEP algorithm if it is too short. You should not call these methods from within encodeOAEP() and decodeOAEP().

KeyExchange.java

Your KeyExchange class should implement the following API:

public class KeyExchange {
   public static final int OUTPUT_SIZE_BYTES
   public static final int OUTPUT_SIZE_BITS
   public KeyExchange(PRGen rand, boolean iAmServer)
   public byte[] prepareOutMessage()
   public byte[] processInMessage(byte[] inMessage)
}

The constructor should prepare to do a key exchange. The rand argument is a secure pseudo-random generator that can be used by the implementation. Each exchange has two participants; one of them plays the client role and the other plays the server role. The iAmServer argument is true if and only if we are playing the server role in this exchange. In our automated testing, we will use the iAmServer boolean as a flag to indicate which object belongs to which role. You may not need to use the iAmServer argument in your implementation, but it may be helpful for debugging.

Once the KeyExchange object is created, two things have to happen for the key exchange process to be complete:

• Invoke the prepareOutMessage method on this object, and send the result to the other participant.
• Receive the result of the other participant’s prepareOutMessage, and pass it in as the argument to a call on this object’s processInMessage.

These two things can happen in either order, or even concurrently (e.g., in different threads). This code must work correctly regardless of the order.

The call to processInMessage should behave as follows:

• If passed a null value, then throw a NullPointerException.
• Otherwise, if passed a value that could not possibly have been generated by prepareOutMessage, then return null.
• Otherwise,return a digest (hash) value with length OUTPUT_SIZE_BYTES and the property described below.

Your KeyExchange class must provide the following security guarantee: If the two participants end up with the same non-null digest value, then this digest value is not known to anyone else. This must be true even if adversaries can observe and modify the messages sent between the participants.

This code is not required to check whether the two participants end up with the same digest value; the code calling this must verify that property.

Getting Started

• Start with RSAKeyPair.java. While it is true that it contains instances of RSAKey, the RSAKeyPair class does not use any of the methods that you will implement in RSAKey.
• As in Assignment 1, the specification is deliberately vague regarding how you should accomplish each task. There is a significant design component to each problem.
• Make sure to run your code with the java -ea flag, so that assertions are enabled.
• Use BigInteger:
  • Since you will be doing math with very large integers, you will probably want to use the java.math.BigInteger library class for any such operations. This class provides myriad functions that you may find useful for this assignment, particularly as BigInteger was originally designed with RSA implementation in mind. (Using BigInteger doesn’t violate our rule against using external cryptographic primitives, because BigInteger provides basic mathematical functions, and not cryptography.)
  • If you find yourself writing complex functions involving BigIntegers (e.g., manually testing primality, manually generating primes, manually finding the greatest common denominator of two numbers, manually finding \(d\) given \(p\), \(q\), and \(e\), etc.), you are doing way more work than you need to. Find the appropriate BigInteger method.
  • Converting back and forth between BigInteger objects and byte[] arrays is a major hassle. It’s surprisingly hard to get this code right. We have provided code in the HW2Util.java file that can do this.
  • For maximum elegance in RSAKey, your message should only be in BigInteger format for the purposes of exponentiating and modulusing. In other words, when you are applying OAEP, padding, unOAEP, etc., it is much easier to deal with your input in terms of byte[] arrays.
• Given private and public keys \((d, N)\) and \((e, N)\), we have that \(x = (x^{(de)}\ mod\ N)\), if \(0 < x < N\). Thus, if you are going to use the built-in BigInteger methods to encrypt and decrypt, it is important that you represent your input message as a positive BigInteger.
• An RSAKey object does not know if it is private or public key. Indeed, it is even possible to sign messages using a public key or encrypt using a private key, though neither of these strange operations are likely to be useful in practice.
• We recommend that first you get your code working for the case where all inputs are full sized, then modify your code so that it handles padding. When you implement padding, the relevant code should be in the provided addPadding() and removePadding() methods. Your other methods should call these utility methods to pad/unpad when necessary.
• If your are confident that your solution to Assignment 1 is correct, you could use those .java files for testing your implementation of Assignment 2. Alternatively, you can use our reference solution to Assignment 1, which is provided a pre-compiled JAR file (library). Note that this library does not contain source code. To compile and execute your Assignment 2 code using the JAR file, you need to include it in your classpath.
  For example, using Linux/Mac command line, you may run:

  $ javac -cp hw1.jar KeyExchange.java
  $ java -ea -cp hw1.jar:. KeyExchange
  

  For Windows command line, you may run:

  $ javac -cp "hw1.jar" KeyExchange.java
  $ java -ea -cp "hw1.jar;." KeyExchange
  

  If you are testing and running using an IDE, please refer to the IDE's user manual on how to add .jar files to the classpath.

Submission Checklist

Submit your files to Gradescope: