MFCrypt originally started as a pretty simple project. I wanted to make a CLI tool in Rust that could encrypt and decrypt files, mostly because cryptography was cool also i watched the Alan Turing movie and that one question on LeetCode. The original plan was basically just file + key = encrypted file and encrypted file + key = original file.

The simplest way would be to have one key that keeps changing but that idea is primitive and not really fun to make (easy type shi) so the main protocol was basically me adding stuff to the whole encryption part of it and deciding how it would go on. The main algorithm for the encryption was based on Aes-Gcm (which is a very well made symmetric encryption algo, so there was no point rewriting (not that it is easy) another algo.

So MFRP MFCrypt File Ratchet Protocol. The basic idea is that both people start with the same Root Key. When a file is encrypted, the Root Key and information about that specific file are used to derive a File Key. That File Key encrypts the file, and information from the encrypted result is then used to derive the next Root Key. The other person can independently do the same thing after successfully decrypting the file, meaning both sides move forward to the same next state without actually sending the new key to each other. In my head this sounded way simpler before I actually had to implement it.

So on the technical side we have a Root key which changes after each msg is encrypted and both the systems start with the same root key. This root key then generates a file key and the next root key, the file key encrypts the file and next root key is there for the file. The file bound ratchet which means the next key is derived from the file(it does not contain the file but we use the metadata to generate the key) , the key generation is done on both the machines differently so there will never be naked key in the file. The 'Meta Data' is bascially the Protocol version, file sequence number, the magic bytes, the nonce (who named this?) and the main cipher text

The Encrypted file creates a 'Fingerprint' which is used to create the next root key, so the root keys will always be file dependant (so decoding one msg wont lead u to the other). Now the 'fingerprint' is created by a hash function (because we need it to be a certain length). The root key generation is dependant on this 'fingerprint' and the last root key.

The de-encryption works the same way, we take the info and decide the key on the machine and then deencyrpt it and then read it and send again, if none of the visible(not encrypted) meta data does not match then the functions just dont work , the data that shld match and is visible is again the magic bytes and the version number and the key ratchet state

Rust was also a big reason I wanted to do this project. I had already been getting more interested in systems programming and MFCrypt gave me an excuse to work with binary data, file handling, a CLI, cryptographic libraries and state management all in one project. The actual encryption uses established stuff like AES-GCM, HKDF and SHA-256 because I am simply not good enough to write my own encryption algorithm :sob: .

Cool topic hopefully i do end up writing my own algorithm