# A3 Part II
**Deadline:** Wednesday, 03/09/16, 11:59 pm
*This assignment may be done as individuals or with one partner.*
In Part II of this assignment, you will implement some core pieces of a
secure instant-messaging application, as well as simulate a Dolev-Yao
attack against that application. You do not need to submit anything
for Part I; we assume that, as you are reading this text, you have
successfully solved Part I.
Your task is to build a collection of four programs named Alice, Bob, Mallory, and Gen:
* **Alice:** repeatedly prompts the user for a string then sends that string over the
network to the recipient.
* **Bob:** displays strings that are received from the sender.
* **Mallory:** the Dolev-Yao attacker. Mallory receives a message
as input from the network, displays the message, and prompts the user
whether to forward the message as is, to modify the message in some way
before forwarding it, or to drop the message and not forward it. Mallory
can also store and replay old messages.
* **Gen:** generates public–private key pairs and stores them in files.
**Requirement 1: Network communication.**
Alice, Bob, and Mallory communicate with one another over TCP.
The communication architecture is that Alice sends messages
to Mallory, who sends messages to Bob:
Alice ---> Mallory ---> Bob
The programs should accept appropriate command-line arguments to specify the
hostname (or network address) and port of their communication partner(s).
The expected workflow is as follows:
1. Run Gen to generate key files, which are then manually distributed
to the filesystems from which Alice, Bob, and Mallory will run.
Alice receives her public and private keys as well as Bob's public
keys. Bob receives his public and private keys as well as Alice's
public keys. Mallory receives both Alice and Bob's public keys, but
not their private keys.
2. Start Bob.
3. Start Mallory, specifying Bob's address as the recipient.
4. Start Alice, specifying Mallory's address as the recipient.
5. Type strings into Alice, which are sent over the network to Mallory.
Use Mallory to read, modify, and/or delete messages. Messages
forwarded on from Mallory to Bob should be displayed by Bob.
It should additionally be possible connect Alice directly to Bob
without the interference of Mallory:
Alice ---> Bob
**Requirement 2: Cryptography.**
The system should provide the ability to operate in each of four configurations:
1. *No cryptography:* messages are not protected.
2. *Symmetric encryption only:* the confidentiality of messages is protected.
3. *MACs only:* the integrity of messages is protected.
4. *Symmetric encryption then MAC:* both the confidentiality and integrity of
messages is protected with Enc-then-MAC.
The programs should accept command-line arguments to support the
selection of which configuration is being used, as well as the location
of key files. Since Alice and Bob do not initially share any symmetric
keys, you need a key establishment protocol; use the protocol provided
in the appendix of this writeup.
Every message should be accompanied by a sequence number (aka message
number). The system should use these sequence numbers to resist replay
attacks, though the success of that countermeasure may depend upon the
configuration in use.
**Requirement 3: Interface.**
Build text-only interfaces that are configured solely by command-line
arguments. The only interactive prompting should be (i) Alice's prompts
to the user for strings to send, and (ii) Mallory's prompts to the user
for what to do with messages.
Choose a programming language and environment with which you are
comfortable and that has library support for the cryptographic and
networking functionality you will need. Java, C#, and Python are
good choices. Use library implementations of encryption schemes,
block cipher modes, MACs, digital signatures, and hash functions.
Do not use library implementations of higher-level protocols, such as SSL/TLS.
All further details are up to you. Make reasonable choices and be
prepared to defend them. You're welcome to seek advice, but the course
staff will resist refining this specification.
### Rationale document
Prepare a *rationale document* explaining the use of
cryptography in your system. Include protocol narrations annotated
with citations into your code to explain to the grader where to look for
implementation of each step. Defend your choices of key lengths and
If you work with a partner, first form a group on [CMS][cms]; submit as that group,
rather than submitting the same solution independently.
Submit your rationale document and an archive of your source code.
You will meet with a grader to demo your system in person on your own
computer. It is acceptable to demo on a single physical computer. We
will schedule the demos on [CMS][cms]. Your demo should begin with you
downloading your submission from CMS, so that the grader is convinced
you have not made any later improvements. The grader will ask you to
demonstrate the functionality and security of your system, largely
following the order of the four configurations above: first demo
without any security, then with confidentiality (showing that Mallory
can no longer read the messages), then with integrity (showing that
Mallory's actions can be detected by Bob), then with both. Any bugs
(i.e., failures) observed during the demo will be penalized. The grader
will also interview you about the cryptographic choices you made to see
whether you understand and can defend them.
You will be evaluated on the quality of your submission and demo, and on your
adherence to the submission stipulations above. The quality of your source
code (documentation, style, etc.) will not explicitly be evaluated.
### Appendix: Key transport protocol
The following, known as ISO/IEC 11770-3 Key Transport Mechanism 2,
is a key transport protocol based on asymmetric cryptography.
It enables A to convey a fresh session key to B by sending a single message.
1. A -> B: B, tA, Enc(A,kAB; K_B), Sign(B, tA, Enc(A,kAB; K_B); k_A)
* A and B are identifiers for principals, which in this assignment may simply be strings
* tA is a timestamp sampled from A's local clock and verified by B against B's local
clock to be *recent*, which in this assignment could be defined as "within the last
* Enc is an asymmetric encryption algorithm
* Sign is a digital signature algorithm
* kAB is a fresh session key generated by A
* K_B is B's public encryption key
* k_A is A's private signing key
Furthermore, Enc must be a [*non-malleable* encryption scheme][nm]. *Hint: RSA with OAEP
padding is non-malleable.*