0

This question is a result of a fair amount of work, and it significantly affects some decisions we may make moving forward with the way we share public keys.

We have a backend server built in Node, and it issues public keys using an uncompressed base64 encoded key. We use these public keys to create secret keys that can be used to encrypt our payloads. This is trivial in Node (and using the browser's crypto package) using a ECDH key pair as follows:

const b64ServerPublicKey = "BDnHVd+/0f+JIQihtVONQ4le9bNJtnU01as7Y1ucIFn+SNnDpV/2f7P2tcD8OaBDfTAV6qjqBURFsxD+WcRcoGY=";

const b64ClientPublicKey = key_pair.getPublicKey("base64", "uncompressed"); //for sending to server

const secret_key = key_pair.computeSecret(b64ServerPublicKey, "base64", "base64");

Unfortunately, we are trying to build key exchange code in other languages (like Java), and it's far from trivial. Java only seems to want to deal with encoded X.509 public keys, so we can't create or parse the base64 uncompressed / unencoded keys without constructing the keys manually. I found this article which shows how to encode/decode to/from ECPublicKey objects using the X/Y coordinates on the curve, but I needed to prepend a 0x04 byte and increment the offset by 1. Am I missing an easier way to do this, or should we change the way our Node server generates public keys? I'm worried as we support other languages, we are going to run into similar issues.

mfbudos
  • 1
  • 1
  • 3
  • [This](https://stackoverflow.com/a/56170785/9014097) is a compact conversion that may be of interest to you. – Topaco Feb 09 '21 at 19:56
  • This seems to confirm my complaint that this certainly isn't easy/clean. Some of these examples don't address the leading byte, and others are reliant on bouncycastle (which I'm trying to avoid). Thanks for the reference. – mfbudos Feb 10 '21 at 20:49

0 Answers0