We have

  • a HMAC key (128 bit/16 bytes)
  • an AES key (128 bit/16 bytes)
  • an AES IV (128 bit/16 bytes)
  • a random salt (128 bit/16 bytes)

Each packet is signed with a HMAC (SHA256)

After each packet is sent, all those keys are packed together into a 64 byte array (HMAC + AES Key + AES IV + salt). Take the SHA512-hash of that nonce. Take the result and:

  • xor the first 16 bytes with the HMAC
  • xor the second 16 bytes with the AES key
  • xor the third 16 bytes with the AES IV
  • xor the fourth 16 bytes with the salt

The keys are generated using the Windows's Random Number Generator and shared via RSA with OAEP padding (PKCS #1 v2.1).

  • 1
    $\begingroup$ Related, possibly a duplicate: Perfect Forward Secrecy with Pre-shared Key $\endgroup$
    – otus
    Commented Jun 11, 2014 at 16:33
  • 2
    $\begingroup$ Please make sure to provide a specific technical question in the body of the question. The title is for, well, a title -- and does not replace to need to ask a specific question in the body of the question. $\endgroup$
    – D.W.
    Commented Jun 11, 2014 at 19:58
  • $\begingroup$ Why should anyone bother to analyze this protocol? What advantage does the scheme have over TLS? What problem are you trying to solve, that is not already solved by existing protocols? $\endgroup$ Commented Jun 17, 2014 at 22:33
  • $\begingroup$ I do crypto for fun and I keep learning more and more, this scheme obviously has no advantage over TLS. I am challanged to make a secure protocol and I'm getting closer and closer everyday, my goal is creating a secure encryption scheme which provides confidentiality, integrity, authentication & forward secrecy and that not by just copying TLS. Why should anyone bother to analyze? Those people who're kind enough to spend a minute of their freetime to help others and for that they get reputation & points, this is just how stackexchange works, doesn't it? $\endgroup$
    – hl3mukkel
    Commented Jun 18, 2014 at 8:13

1 Answer 1


No, this protocol does not provide perfect forward secrecy. Record the initial key transport message (shared via RSA-OAEP). If the attacker later gets access to the corresponding RSA private key, and decrypts the original key transport message, the entire symmetric key evolution sequence for that session will trivially unfold.

  • $\begingroup$ Ah thanks, any ideas for counter-measures against this? $\endgroup$
    – hl3mukkel
    Commented Jun 11, 2014 at 17:08
  • 3
    $\begingroup$ @hl3mukkel, use a key exchange protocol like Diffie-Hellman. $\endgroup$
    – otus
    Commented Jun 11, 2014 at 17:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.