Asymmetric or symmetric - which makes sense in this scenario? Announcing the arrival of Valued Associate #679: Cesar Manara Planned maintenance scheduled April 23, 2019 at 23:30 UTC (7:30pm US/Eastern)Encrypting sensitive data in software and storing/decrypting it on a serverServing data from an encrypted database over an encrypted connectionAsymmetric / end to end encryption for web messaging appWhat benefit to use different encryption key (passphrase) for different customers?Asymmetric Encryption for Multiple Recipients?Brute force symmetric knowing asymmetricStoring sensitive info in DB with Public/Private Asymmetric keysHow to protect an application from attackers with full read-access to the db?Distribution of keys for a python messaging applicationSymmetric encryption for data protection
Improvising over quartal voicings
Is there night in Alpha Complex?
How to resize main filesystem
Why not use the yoke to control yaw, as well as pitch and roll?
Dinosaur Word Search, Letter Solve, and Unscramble
Lemmatization Vs Stemming
Unicode symbols with XeLaTeX and Lato font
Who's this lady in the war room?
calculator's angle answer for trig ratios that can work in more than 1 quadrant on the unit circle
geoserver.catalog.FailedRequestError: Tried to make a GET request to http://localhost:8080/geoserver/workspaces.xml but got a 404 status code
"Destructive power" carried by a B-52?
Who's the Giant Batman in the back of this dark knights metal Batman picture?
malloc in main() or malloc in another function: allocating memory for a struct and its members
How does Billy Russo acquire his 'Jigsaw' mask?
Proving that any solution to the differential equation of an oscillator can be written as a sum of sinusoids.
Why did Bronn offer to be Tyrion Lannister's champion in trial by combat?
How can I prevent/balance waiting and turtling as a response to cooldown mechanics
How to show a density matrix is in a pure/mixed state?
How to name indistinguishable henchmen in a screenplay?
Hide attachment record without code
How to make an animal which can only breed for a certain number of generations?
JImage - Set generated image quality
Why are two-digit numbers in Jonathan Swift's "Gulliver's Travels" (1726) written in "German style"?
New Order #6: Easter Egg
Asymmetric or symmetric - which makes sense in this scenario?
Announcing the arrival of Valued Associate #679: Cesar Manara
Planned maintenance scheduled April 23, 2019 at 23:30 UTC (7:30pm US/Eastern)Encrypting sensitive data in software and storing/decrypting it on a serverServing data from an encrypted database over an encrypted connectionAsymmetric / end to end encryption for web messaging appWhat benefit to use different encryption key (passphrase) for different customers?Asymmetric Encryption for Multiple Recipients?Brute force symmetric knowing asymmetricStoring sensitive info in DB with Public/Private Asymmetric keysHow to protect an application from attackers with full read-access to the db?Distribution of keys for a python messaging applicationSymmetric encryption for data protection
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;
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:
- I don't want anything other than my client to be able to submit things to the server.
- 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?
encryption asymmetric
New contributor
add a comment |
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:
- I don't want anything other than my client to be able to submit things to the server.
- 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?
encryption asymmetric
New contributor
1
Hi and welcome to the site! Good question! Unfortunately, requests for off site resources like learning material is off topic so I took the liberty to remove that part of the question. If you disagree, you can roll back.
– Anders
2 hours ago
add a comment |
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:
- I don't want anything other than my client to be able to submit things to the server.
- 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?
encryption asymmetric
New contributor
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:
- I don't want anything other than my client to be able to submit things to the server.
- 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?
encryption asymmetric
encryption asymmetric
New contributor
New contributor
edited 2 hours ago
Anders
50.5k22144167
50.5k22144167
New contributor
asked 3 hours ago
Hy-Hy-
132
132
New contributor
New contributor
1
Hi and welcome to the site! Good question! Unfortunately, requests for off site resources like learning material is off topic so I took the liberty to remove that part of the question. If you disagree, you can roll back.
– Anders
2 hours ago
add a comment |
1
Hi and welcome to the site! Good question! Unfortunately, requests for off site resources like learning material is off topic so I took the liberty to remove that part of the question. If you disagree, you can roll back.
– Anders
2 hours ago
1
1
Hi and welcome to the site! Good question! Unfortunately, requests for off site resources like learning material is off topic so I took the liberty to remove that part of the question. If you disagree, you can roll back.
– Anders
2 hours ago
Hi and welcome to the site! Good question! Unfortunately, requests for off site resources like learning material is off topic so I took the liberty to remove that part of the question. If you disagree, you can roll back.
– Anders
2 hours ago
add a comment |
1 Answer
1
active
oldest
votes
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
- Distribute different symmetric keys for each client-server relationship, or
- 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).
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "162"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Hy- is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f207815%2fasymmetric-or-symmetric-which-makes-sense-in-this-scenario%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
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
- Distribute different symmetric keys for each client-server relationship, or
- 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).
add a comment |
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
- Distribute different symmetric keys for each client-server relationship, or
- 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).
add a comment |
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
- Distribute different symmetric keys for each client-server relationship, or
- 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).
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
- Distribute different symmetric keys for each client-server relationship, or
- 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).
answered 2 hours ago
TheWolfTheWolf
903512
903512
add a comment |
add a comment |
Hy- is a new contributor. Be nice, and check out our Code of Conduct.
Hy- is a new contributor. Be nice, and check out our Code of Conduct.
Hy- is a new contributor. Be nice, and check out our Code of Conduct.
Hy- is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Information Security Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f207815%2fasymmetric-or-symmetric-which-makes-sense-in-this-scenario%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
Hi and welcome to the site! Good question! Unfortunately, requests for off site resources like learning material is off topic so I took the liberty to remove that part of the question. If you disagree, you can roll back.
– Anders
2 hours ago