Replies: 1 comment
-
I've implemented this before with OpenSSL, and yes RSA is likely the move. We could store the private key as a secret in the Kubernetes cluster in which the external adapter is running and mount it into the application. Because K8s secrets aren't as safe as the word secret would lead you to believe (they're base64 encoded, but not encrypted), we can encrypt them at rest (https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) in case someone hacks our cluster's etcd state store. Additionally, we can use something like HashiCorp Vault (https://www.hashicorp.com/blog/injecting-vault-secrets-into-kubernetes-pods-via-a-sidecar) to inject the secret just-in-time when it is needed. |
Beta Was this translation helpful? Give feedback.
-
Currently the oracles use a shared personal access token. This limits us in certain requests. See: OctobayArchive/chainlink-adapters#10
The idea is to encrypt user's access token in the client, using a public key for which the involved oracle has the private one. This requires to generate a key pair for each oracle and store the public keys on chain with their other information, available to the frontend through our subgraph. Access tokens should be read-only and expire quickly.
I have never implemented this and I don't know even what questions to ask.
Isn't this enough: https://nodejs.org/api/crypto.html#crypto_crypto_generatekeypair_type_options_callback
What type then? RSA?
Beta Was this translation helpful? Give feedback.
All reactions