/Users/alishahc/practicalcrypto/Assignments/Assignment2/.texpadtmp/hw2.dvi
1. There seem to be several hardcoded values in the code. However, it appears that these
values will be manually changed prior to the client or server running the code. That
is, you can assume there will be hardcoded values but those values may be
di!erent on the real client or server compared to the code you found.
2. You notice the protocol uses a modified version of the Noise IK pattern that they
refer to as IKSign. This pattern replaces the se token with a sign token which
represents a ECDSA signature56 over the message contents. So this pattern looks like
the following:
IKSign:
<- s ... -> e, es, s, ss
<- e, ee, sign
This handshake protocol involves a preshared static public key from the server for
both Di!e Hellman and ECDSA operations. How these keys are generated may be
of interest.
3. This code also appears to have many dubious implementation decisions, such as cus-
tom random number generators and multiple di"erent elliptic curves (curve25519 and
P256) used in di"erent places.
4. The protocol that the client and server are engaging in appears to be quite simple.
After the handshake concludes a client can send a normal request or a secret query
to get some hardcoded response from the server. You notice that the client appears
to be hardcoded to only send the normal request.
For this problem you will produce a Go program that interacts with the client and server
in order to obtain the server’s response to the secret query from the client. This will likely
require being able to decrypt and modify messages that are being sent between the two
parties.
While normally a protocol such as this would happen over a network, for simplicity in
this assignment, we will assume that the parties are communicating through files. Each run
of the client or the server will require providing several pieces of information to facilitate
this. First, which step of the protocol they are on. There are 3 possible steps with the
first run of the client starting on step 1, and then the server running on step 1. Then
the client and server run again on step 2. Finally, the client runs on step 3 and ends the
protocol. Additionally, the seed that the server uses for its random number generator will
be required. Finally, you must provide the files that the client and server will read and
write from. Thus the syntax for running the client or server will be:
wg-lite
5https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm
6https://blog.trailofbits.com/2020/06/11/ecdsa-handle-with-care/
Assignment 3-2
So for an example seed value of 1, the correct sequence of program calls would look like:
wg-lite client 1 1 client-message-1 server-message-1 server-message-2
wg-lite server 1 1 server-message-1 client-message-1 client-message-2
wg-lite client 1 2 client-message-2 server-message-1 server-message-2
wg-lite server 1 2 server-message-2 client-message-1 client-message-2
wg-lite client 1 3 client-message-3 server-message-1 server-message-2
Your code can call this program with any arguments that you would like in the process of
carrying out your attack. Additionally, you may repurpose any code from the repositories
linked in this document. Additionally, the math/big.Int library may be of use. The
command line interface of your program should be:
compromiser Your program should output a single line (no newline at the end) that is the recovered Note: While you can modify the code provided for testing purposes, keep in Written Problems 1. Consider a protocol using the specified IK pattern for its handshake. This protocol 2. IPSec7 is another tunneling protocol with similar goals to Wireguard. Briefly compare 7https://en.wikipedia.org/wiki/IPsec Assignment 3-3
response to the client’s secret query.
mind that the wg-lite program used by the autograder will look exactly as the
code appears in the repository with the exception of di!erent hardcoded values.
supports ”Zero-RTT” where the first handshake message’s payload is encrypted and
authenticated. What does it mean for a request to be idempotent and why might
it be a bad idea to include a non-idempotent request in the first payload.
and contrast these protocols