Encrypted File Store

The goal of this assignment is to build an encrypted file store. The stored files are each encrypted; the archive as a whole is integrity-protected.

Implement a command called cstore. The  command must  accept only the following options:

cstore list archivename

cstore add [-p password] archivename file

cstore extract [-p password] archivename file

cstore delete [-p password] archivename file

The command you build must be named cstore, and it must accept exactly this syntax.

Multiple files may appear on each command. If no password is given, it should be read from the keyboard. Use of the getpass() library routine is encouraged but not required. (For reasons we'll discuss later in the semester, the -p option is  not particularly secure. However, it's useful for testing.)

To convert a password to a cryptographic key, iteratively apply SHA2-256 at least 10,000 times. (Again, this isn't the best way. You may implement PBKDF2 if you wish, but it's not required and there's no extra credit.)

The attacker's goal is to steal one of the files, or to corrupt the archive. Therefore, the files must be encrypted and the archive must be  integrity-protected. However, it must be possible to list the archive without supplying a password.

I suggest download AES and SHA2-256 source code from https://github.com/B-Con/crypto-algorithms (by Brad Conte (brad@bradconte.com)), though you're welcome to use any other open source implementation you find. (If you do, document the location.) I've compiled and tested those files on Linux. If you use them:

• You may only use the AES key setup routine aes_key_setup and the ECB encrypt/decrypt routines (aes_encrypt and aes_decrypt)
• The aes.h file is (skimpy) documentation of the parameters to each routine. You may find it useful to look at aes_test.c for sample calling sequences
• If you need any other modes of operation, you must implement them yourselves

Similarly, see sha256.h and sha256_test.c for how to use SHA2-256. The style—calling sha256_init() to initialize the state, using sha256_update() for each block of additional text to be hashed, and sha256_final() to produce the final output—is the way every cryptographic hash function I've seen operates. 

If you need cryptographically strong random bytes, read them from /dev/urandom. Note that since its output is constantly changing, you may see non-reproducible errors. You may, if you wish, build in some test scaffolding; if yo do, you must document it.

You must submit:

• Source code
• A single Makefile to compile everything. Typing 'make test' should run your tests
• Test scripts to exercise everything. The graders may supply their own test data, too.
• A short document explaining any design choices. You must explain which AES mode of operation you used and why. You must also explain how you have chosen to integrity-protect the archive

The archive file format is up to you. Efficiency is not especially important.

And remember—since buggy code is often insecure code, there will be deductions for any bugs.