I have a client application that communicates with a server through a web API.
The data being communicated is not personally sensitive (no passwords, credit card details, usernames, etc). It's just challenge/response queries between client/server related to client license information (serial key, hardware fingerprint, etc).
For example, client sends a "here's my serial key" message to the server through the API and receives a response indicating whether it is valid or not.
I want the inputs/outputs of the API to be encrypted, so plain-text serial/hw data is never sent over the network/internet.
Here is my question:
Assuming a 100% compromised client application, is there any actual benefit to implementing asymmetric encryption (public/private key encryption), over simply having some random-character string stored in the app (and also on the server) to XOR the data instead?
Assume in this scenario that in the former case the attacker has RE'd the application and has full access to the public key stored within, and can use it to encrypt their own API queries, and the same goes for the latter case (they have the random-character string and can use it to XOR their own API queries).
If a random-character string used to XOR-encrypt data is sufficiently long and random, what would be the benefit of using asymmetric encryption in a fully compromised app where the attacker knows the public key?