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
Alexander Vtyurin
  • 21
  • 2
  • 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?](https://security.stackexchange.com/questions/18197/why-shouldnt-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
  • This will probably get better traction over at [crypto.se] than over here. You're asking for security implications, but honestly our answer is: Don't roll your own crypto. (See also the last section of [Crypto's page about what is on topic there](https://crypto.stackexchange.com/help/on-topic)) – Ghedipunk Oct 15 '19 at 21:08
  • @MikeOunsworth nice to meet you. Unfortunately, I can assume, you didn't even read my question. As far as I can see, there is nothing so special about the algorithm I mentioned: it only uses well-known primitives and techniques with well defined and tested behavior. There is no custom encryption or any non-trivial steps in it. Question summary is: given this DH scheme and this order of simple actions, can one assume it's connection secure? – Alexander Vtyurin Oct 15 '19 at 21:13
  • @SteffenUllrich hey, thanks for your reply! I'll get my look into DTLS. Never heard of it before. There are two problems I can see from here in using it: 1. I don't want to use old stuff, like RSA. 2. My reliable UDP implementation uses `fountain codes`, which make it not really the `datagram` protocol. – Alexander Vtyurin Oct 15 '19 at 21:19
  • @Ghedipunk, hey there! Thanks for your comment. 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. – Alexander Vtyurin Oct 15 '19 at 21:21
  • @Ghedipunk And also, the optional question I've mentioned (about persistent ECDSA certificate) should be really answered here. – Alexander Vtyurin Oct 15 '19 at 21:26
  • If you want to know how changing a cryptographic system will affect that system, then you _definitely_ want to ask the Crypto people, and not us. Our answer is: Don't! – Ghedipunk Oct 15 '19 at 21:26
  • @Ghedipunk no, there is nothing about *changing* a cryptographic scheme. – Alexander Vtyurin Oct 15 '19 at 21:28
  • @Ghedipunk in simple words my question is: is it possible for two parties to agree on epheremal shared secret via ECDH and than agree on some strong random static key and exchange ECDSA certificates only in one request-response interaction with the given algorithm details (like hashing epheremal shared secret and encrypting the signatures). – Alexander Vtyurin Oct 15 '19 at 21:33
  • 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](https://noiseexplorer.com) 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 06:20
  • @SqueamishOssifrage thank you for the references you left. I'll give them a try! Finally some meaningful comment. – Alexander Vtyurin Oct 16 '19 at 09:08
  • @PatrickMevzek because QUIC is made with ARQ. It is heavy tuned ARQ but it still waits for ACK packets to make progress. Using fountain codes one can create another kind of transmitter which makes progress constantly without waiting for ACK packets. I have a working POC in Kotlin at github `seniorjoinu/reliable-udp' showing this technique. Now I want to make it in Rust but with some additional features, like security. – Alexander Vtyurin Oct 16 '19 at 09:14
  • "with some additional features, like security. " : security is not something you can slap on an existing product. it needs to be taken into account from the beginning, at the design phase. – Patrick Mevzek Oct 16 '19 at 13:55

1 Answers1

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

Mike Ounsworth
  • 58,107
  • 21
  • 154
  • 209