Vryjdfkk

I am creating a system in which there will be oe client and one server.

The client is periodically (every 5 or 10 secs) going to send a small amount of data to the server (with UDP).

I am able to securely place keys/passphrases on both the client and the server without anyone or anything else knowing what these keys/passphrases are. I will always have access to the server and if I lose access to the client, I can change the keys/passphrases easily enough on the server.

My security concerns are twofold:

1. I don't want anything other than my client to be able to submit things to the server.


2. I don't want the data that is in transit from my client to the server to be plaintext.

Am I able to get away with using symmetric encryption on the client and embedding some kind of identifiable and unique token in the payload that the server (when it has decrypted) can use to verify that the client is who it says it is? Or is an asymmetric (DTLS?) public/private key pair solution required? Or will neither of these do what I want?

What you called "concerns" in your question is what in the world of information security is usually referred to as "protection goals". In your case, you are looking for confidentiality (no man in the middle should be able to read the data exchanged) and authenticity (only known-good entities should be able to submit data).

Note that authenticity is usually defined to mean that a message or piece of data actually originates from the source it claims to originate from - and this is exactly the crux of your question. If you know that there will only ever be one client, distributing symmetric keys will be enough to guarantee both the confidentiality and the authenticity of your data (assuming the keys do not leak).

If, however, there are (or might be in the future) multiple clients (or servers, for that matter), you would need to either

1. Distribute different symmetric keys for each client-server relationship, or


2. Use the same symmetric key and use some other means to ensure the authenticity of the data exchanged (i.e., to make sure clients cannot send data claiming to be another client)

Therefore, using asymmetric encryption with a PKI issuing certificates to each participant in the scheme might be the more future-proof solution. This would allow you to properly sign messages with each client's private key to ensure authenticity.

Please note that either way, you are probably looking for more than just authenticity and confidentiality (integrity comes to mind - you probably do not want a potential man in the middle to be able to modify data exchanged between the clients and the server). Therefore, make sure to use a properly vetted, high-level crypto API implementing established algorithms and protocols for all your cryptographic operations.

(There are a lot of pitfalls in crypto. For example, in many cases, it is trivial for a man in the middle to capture a properly constructed message and replay it at a later point. Thinking of such attacks and defending against them by combining cryptographic primitives yourself is probably not a good idea).