CS 255 Introduction to Cryptography - Stanford University. Programming Assignment 1. Winter 2022

Document Content and Description Below

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]

Last updated: 4 months ago

Preview 1 out of 6 pages