2

I'm writing reliable UDP implementation and I want it to be secure. Also, I want to make use of elliptic curve cryptography. I don't have the proper education to really understand the math behind this kind of cryptography, but I understand how to use it (at least in general).

Given the next preconditions, is this algorithm secure? What steps can be skipped without compromising security?

(opt.) Is it ok for parties to use a single ECDSA key pair for all interactions in a long period of time? I mean do not change this key pair at all and use it to sign any messages.

Preconditions

  • Interaction is going between two parties A and B
  • Both A and B have predefined ECDSA key pair
  • Digital signature also works like a hash

Algorithm

  1. A computes and sends to B her epheremal ECDH public key
  2. B computes the shared epheremal ECDH secret and hashes it with SHA-256, using the key A sent her in step 1
  3. B randomly generates 256-bit static encryption key
  4. B encrypts her ECDSA public key and the static encryption key from step 3 using the epheremal secret from step 2 with AES-256 algorithm
  5. B signs the result from step 4 with her ECDSA private key
  6. B sends to A the result from step 4 alongside with the signature from step 5 and her epheremal ECDH public key
  7. A also computes the shared epheremal ECDH secret and hashes it with SHA-256, using the key B sent her in step 6
  8. A decrypts the result from step 4 using epheremal key from step 7 with AES-256 algorithm
  9. A checks the signature B sent her in step 6 using B's ECDSA public key she received in step 8
    • If something goes wrong (the signature is invalid or step 8 lead to corrupted data), A gives up
    • At this point, A has everything she needs to send messages securely
  10. A signs and encrypts her ECDSA public key using AES-256 algorithm with the static encryption key she received in step 8
    • A can also sign and encrypt some payload in this step
  11. A sends to B the result from step 11 with the signature
  12. B decrypts the ciphertext A sent her using AES-256 algorithm and checks the signature
    • If here something goes wrong, B gives up
  13. Now both A and B know ECDSA public keys of each other and the shared encryption key, so they can interact securely and be sure nobody can modify their messages
  • 2
    Is there a reason you need to design your own Kx? Why don't you simply use DTLS which likely already offers what you want to implement yourself? See also Why shouldn't we roll our own?. – Steffen Ullrich Oct 15 '19 at 19:26
  • Welcome to StackExchange! Unfortunately, Stack Exchange likes questions that can be answered in a single page. The scope of your question; analyzing your protocol under all possible error conditions assuming the attacker has knowledge of all state-of-the-art cryptographic attacks would be a better fit, for example, as a chapter in a PhD thesis. I think you either hire an expert capable of doing this work, or use a library with a well-tested implementation, for example DTLS which Steffen suggests. – Mike Ounsworth Oct 15 '19 at 20:43
  • 2
    "The key exchange scheme I suggest is really very likely TLS, but simpler." -- This implies that it is changed. Are you using a well known and battle tested algorithm? (If you are, why haven't you named it specifically?) If you are, then it is as secure as the crypto people tell us that it is. If not, then it is at least as insecure as the Crypto.SE people can determine. – Ghedipunk Oct 15 '19 at 21:57
  • 1
    Crypto.SE person (or rather, vulture) here. We don't generally do reviews of full designs. I recommend that you consider Noise, perhaps with Noise Explorer to explore the design space, and study prior literature on systems like MinimaLT and CurveCP. That said, if you can narrow it down to a specific question about a design narrower in scope than ‘here's my whole design, is it secure?’, that may be on-topic for Crypto.SE. – Squeamish Ossifrage Oct 15 '19 at 22:58
  • 1
    "I'm writing reliable UDP implementation and I want it to be secure." Why not use QUIC? It is basically UDP light features plus what is needed to have something similar to TLS (which is over TCP). If it is not for learning purposes, reusing something that exists or at least looking at it may be a better path. – Patrick Mevzek Oct 16 '19 at 6:20
2

Disclaimer: this is an answer for why this question is too broad. I am not attempting to actually answer the question because that would be, well, too broad.


In comments, you said:

I think that my question really belongs here and not in cryptography section because it contains nothing about custom techniques and algorithms. The key exchange scheme I suggest is really very likely TLS, but simpler. I want to know if this simplification I made is correct in general.

But, in fact, you are creating a custom technique. Everything in TLS is there for a reason. Believe me, the TLS people are obsessed with efficiency, especially with TLS 1.3; if they could remove something from TLS to make it simpler, they would. Designing a secure cryptographic protocol (that is, a protocol that makes use of cryptographic algorithms) is hard.

For example:

It is not easy to build a handshake protocol like TLS and build it properly.

The fact that you think your question is simple enough to ask on stack exchange, tells me that you should not be asking it at all.

I strongly suggest that you find a well-known implementation of a well-known protocol (like (D)TLS, IPSEC, etc), and use that, rather than trying to invent your own cryptographic protocol

| improve this answer | |

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