crypto rfc: clean up e2e (#41)

rfcs/2021-01-26-crypto.md

@@ -47,7 +47,7 @@ The following only makes sense under the assumption that public keys are not rea
     Eve controls servers so this doesn't get sent to Alice, instead it is received by Eve
     7. Eve has to send to Bob via ABq encrypting with his Bpub. By controlling servers E could know ABq so she wouldn't have to decrypt it - she knows where to send. Even so she can't decrypt Bpub w/t Aprv. The problem [for Eve] is that Bpub and Aprv are generated on the clients, which she doesn't control.
 
-If keys were symmetric she could simply decrypt Bob's key with the key Alice sent out-of-band.
+If keys were symmetric Eve could simply decrypt Bob's key with the key Alice sent out-of-band.
 
 ### Where MITM attempt fails
 
@@ -65,21 +65,15 @@ TODO
 
 ## E2E encryption
 
-For E2E encryption of messages between SMP agents we should go with some robust [Authenticated Encyption](https://en.wikipedia.org/wiki/Authenticated_encryption) scheme following [Encrypt-then-MAC](https://en.wikipedia.org/wiki/Authenticated_encryption#Encrypt-then-MAC_(EtM)) approach. The good candidate is [TODO insert implementation from a good library here].
+For E2E encryption of messages between SMP agents we should go with some robust [Authenticated Encyption](https://en.wikipedia.org/wiki/Authenticated_encryption) scheme following [Encrypt-then-MAC](https://en.wikipedia.org/wiki/Authenticated_encryption#Encrypt-then-MAC_(EtM)) approach.
 
-Since we have a shared secret Apub, Bpub (if Apub is compromised connection should be shut down on Bob's side, see [above](#MITM-attempt-problem)) there is no point in using digital signatures over MACs for message authentication other than non-repudiation. Besides [digital signatures generally being less performant than MACs](https://crypto.stackexchange.com/a/37657), the non-repudiation quality I believe may in fact be more undesirable than not for many possible applications. If some applications require non-repudiation it can be implemented later on with digital signatures on application level. See a good answer on differences of MAC and digital signature qualities [here](https://crypto.stackexchange.com/a/5647).
+Since we have a shared secret Apub, Bpub (if Apub is compromised connection should be shut down on Bob's side, see [above](#-Where-MITM-attempt-fails)) there is no point in using digital signatures over MACs for message authentication other than non-repudiation. Besides [digital signatures generally being less performant than MACs](https://crypto.stackexchange.com/a/37657), the non-repudiation quality I believe may in fact be more undesirable than not for many possible applications. If some applications require non-repudiation it can be implemented later on with digital signatures on application level. See a good answer on differences of MAC and digital signature qualities [here](https://crypto.stackexchange.com/a/5647).
 
-Instead of using two assymetric key pairs, we'll use two AE symmetric keys set up in both directions per connection - one key per SMP queue (depending on chosen AE scheme a key here most likely will be a set of two separate keys - one for encryption algorithm and one for MAC). 
+Symmetric keys are generated per message and encrypted with receiver's public key (encryption key).
 
-For current purposes it should be good enough to share these keys during [handshake](#-Initial-handshake):
-
-    5*. B generates Bpub, Bprv, ABq, Bsym
-    6*. B --BAq-> A: Bpub, ABq, Bsym - encrypted with Apub
-    7. A generates Asym
-    8. A --ABq-> B: Asym
-    A & B can send messages to each other encrypted with symmetric keys Bsym and Asym respectively.
-
-Not necessarily in current scope, but in future these symmetric keys have to be rotated per session.
+Future considerations:
+- Generation of symmetric keys per session and session rotation;
+- Signature and verification of messages.
 
 ## E2E implementation