-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: encrypt user credentials in Datastore #144
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if we are treating the cipher properly here. LGTM otherwise.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, we probably don't need the verification part of aes-gcm, but we'll survive the overhead
@@ -40,6 +40,14 @@ You also need a Ed25519 key pair that you can generate by running `cargo run -- | |||
|
|||
Now save it to GCP Secret Manager under the name of your choosing (e.g. `mpc-recovery-key-prod`). This name will be referred to as `GCP_SM_KEY_NAME`. | |||
|
|||
You also need to grab the AES cipher key that was printed after `Cipher 0:`; it should like this: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need both this and the JSON private key?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, one is for encryption, and the other is for multi-party stuff
Fixes #134
aes-gcm is a pretty poor choice for this, but I needed something high-level due to time constraints. Let me know if there is a good alternative.
Ignoring nonce for now, but we should probably use it to salt the results