# encrypted file sharing protocol

I am trying to design a file exchange protocol for learning purposes, inspired by PGP, but fixing some of its shortcomings.

Assuming the machine where the creation and decryption of the file happens are secure, the threat is a passive (reading file) or active (manipulating file) attacker on the line.

These attributes must be granted:

• only decryptable by the intended receiver
• receiver can verify sender identity
• any manipulation to the data will be noticed by the receiver

So we need encryption, authentication, and a signature. After the study of this paper and several other, more basic principles, my protocol draft currently looks like this:

• the masterkey is random and used to derive HMAC and symmetric cypher key.
• IV is random and included inside the MAC.
• algorithm agility metadata is added inside the public key encrypted part to denote what hash is used for signing and MAC, and before the IV to transmit the symmetric cipher algorithm and mode.
• the recipient is identified by public key fingerprint.

What are the dangers or flaws I did not think of in this protocol?

-
You have "recipient" in the wrong place and are missing "sender"; "recipient" should be put $\hspace{.95 in}$ into what is covered by the signature and "sender" should be put where "recipient" was. $\hspace{1.09 in}$ What purpose is "hash, sign" supposed to serve? $\;$ –  Ricky Demer Mar 5 '14 at 19:33
recipient IS inside what's covert by the signature, the signature is made over a hash of recipient and masterkey, that's what hash, sign is supposed to mean - see the linked paper, this proves to the recipiant that the message is intended for him by the signer, and that the signer is in fact in posession of the plaintext (because he has the secret key). is there really a need for a sender identifyer? if the signature checks out, sender is clear, if not, no harm done, right? –  Roya Mar 5 '14 at 20:58
Oh, I'd though signature was over what came after it, rather than what was above "hash, sign". $\:$ In that case, your protocol draft does not provide non-repudiation, and I'd have to think more about whether or not it provides authenticity. $\:$ There is a need for a sender identifier because otherwise an attacker could find a different verification key that will cause the signature to check out or claim to have the same signature verification key as the real sender. $\;\;\;$ –  Ricky Demer Mar 5 '14 at 21:14
ok, that's interesting, thank you. so the paper states that an attacker could create a key that would be different from the signers key, but produce the same signature over an arbitrary message, so possibly the original message, correct? But, if I understand correctly, to calculate such a key, he would need the message for which the signature should be valid with the second key. This is impossible, since the 'message' is actually the masterkey and the receiver, and this data is out of reach, encrypted with the receiving public key. –  Roya Mar 5 '14 at 22:20
ps. this is me talking about RSA, page 6 - I do not intend to use anything other than RSA here. –  Roya Mar 5 '14 at 22:24