CS 255 Introduction to Cryptography - Stanford University. Programming Assignment 1. Winter 2022 1 Introduction
In this assignment, you are tasked with implementing a secure and efficient end-to-end encrypted
chat clie
...
CS 255 Introduction to Cryptography - Stanford University. Programming Assignment 1. Winter 2022 1 Introduction
In this assignment, you are tasked with implementing a secure and efficient end-to-end encrypted
chat client using the Double Ratchet Algorithm, a popular session setup protocol that powers realworld chat systems such as Signal and WhatsApp. As an additional challenge, assume you live in a
country with government surveillance. Thereby, all messages sent are required to include the session
key encrypted with a fixed public key issued by the government. In your implementation, you will
make use of various cryptographic primitives we have discussed in class—notably, key exchange,
public key encryption, digital signatures, and authenticated encryption. Because it is ill-advised
to implement your own primitives in cryptography, you should use an established library: in this
case, the SubtleCrypto library. We will provide starter code that contains a basic template, which
you will be able to fill in to satisfy the functionality and security properties described below.
2 End-to-end Encrypted Chat Client
2.1 Implementation Details
Your chat client will use the Double Ratchet Algorithm to provide end-to-end encrypted communications with other clients. To evaluate your messaging client, we will check that two or more
instances of your implementation it can communicate with each other properly.
We feel that it is best to understand the Double Ratchet Algorithm straight from the source, so we
ask that you read Sections 1, 2, and 3 of Signal’s published specification here: https://signal.
org/docs/specifications/doubleratchet/. Your implementation must correctly use the
Double Ratchet Algorithm as described in Section 3 of the specification, with the
following changes and clarifications:
• You may use HKDF to ratchet the Diffie-Hellman keys the as described in Section 2.3 of
the Signal Specification. Proper usage of HKDF is explained in Section 5.2 of the Signal
Specification.
• HKDF is a key derivation function that we’ve added to lib.js. Section 5.2 describes how it
can be used in your implementation. Read the lib.js comments for how to use our API.
• The lib.js functions contains two HMAC-related functions: HMACtoAESKey (used to generate
keys for AES encryption/decryption) and HMACtoHMACKey (used to generate keys for further
HMACs). Part of your task is determining which function to use in each case in order to
implement the Signal algorithm.
1• Use ElGamal key pairs for the Diffie-Hellman key exchange. See the generateEG function in
lib.js.
• Use AES-GCM as the symmetric encryption algorithm for encrypting messages, using the
sending and receiving keys as derived in Section 2.4.
• Disregard the AD byte sequence input for the ratchetEncrypt and ratchetDecrypt functions
in the Signal Specification. Message headers should still be be authenticated.
• The header of all sent messages must include an encryption of the sending key under the government’s public key. Use ElGamal public key encryption, with AES-GCM as the symmetric
cipher, to encrypt the sending keys. (Note: Since the output of the computeDH function is
configured with HMAC, you will need to run the output through HMACtoAESKey to generate a
key that can be used with AES-GCM. Please use the govEncryptionDataStr variable as the
data parameter in your call to HMACtoAESKey. It may be helpful to refer to the govDecrypt
function in test-messenger.js to see how the govEncryptionDataStr variable is used during
decryption.)
• Every client will a possess an initial ElGamal key pair. These key changes will be used to
derive initial root keys for new communication sessions.
• Public keys will be distributed through simple certificates. Each client generates its own
certificate upon initialization which contains its ElGamal public key. Assume that there is
some trusted central party (e.g. server managed by developers of messaging app), and that
this central party can securely receive certificates generated by clients. This central party
generates a digital signature on each certificate that it obtains, which serves to endorse the
authenticity of the certificate owner’s identity and to prevent any tampering of the certificate
by an adversary. The signed certificates are then distributed back to the clients, so that every
client has the ElGamal public key of every other client in the system.
[Show More]
.png)
.png)
