chore: move message decryption into Veritech server #3784
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
github-actions
bot
added
A-si-settings
|
bors try |
tryBuild failed: |
sprutton1
reviewed
May 14, 2024
lib/veritech-server/src/config.rs
Outdated
| @@ -52,6 +55,8 @@ pub struct Config { | |||
|
|
|||
| cyclone_spec: CycloneSpec, | |||
|
|
|||
| decryption_key_path: CanonicalFile, | |||
There was a problem hiding this comment.
These aren't always paths. We pass them in as base64 strings in prod. SDF Server takes these in using the CryptoConfig object. Can we do that here, too? It will let us keep using our generated config file.
#[builder(default = "CryptoConfig::default()")]
crypto: CryptoConfig,
Edit: Although, on closer inspection that config struct doesn't have decryption keys in it so I'm not sure how this is working currently
This rather large change move the decryption of function execution requests from the Cyclone server to the Veritech server. Sensitive string redaction still takes place in the Cyclone server. Prior to this change, portions of the function execution requests would be encrypted before being passed into a Veritech client call using a a public/private keypair called the "Cylone encryption key". The reason for this naming is that the request portions would be decrypted in a Cyclone server before being passed to a language server for final execution. In order to remove any chance of a user-authored function being able to access such a decryption key, the request decryption activity is now handled back in the Veritech server before it sends the now fully decrypted request over a web socket to a Cyclone server. As a result, there is zero requirement for *any* message cryptography in the Cyclone server. The second task that was performed in the Cyclone server was secret substring redaction, using a `CycloneSecretStrings` Rust type. With this change, the secret substring redaction still takes place in the Cyclone server but now this is realized by adding the set of "sensitive" secrets as part of every Cyclone request. This is how the Cyclone server knows which strings to redact while not participating in the original decryption of the data. As a result of the change in responsibility, these encryption/decryption keys are now known as "Veritech encryption" and "Veritech decryption" keys. Consequently all variables, CLI arguments, and files in our source tree have been updated to eliminate any possibility of future confusion. Signed-off-by: Fletcher Nichol <fletcher@systeminit.com>
fnichol
force-pushed
the
fnichol/veritech-decryption
branch
from
8922d52
to
41ed163
Compare
|
bors retry |
tryBuild succeeded: |
|
bors try |
tryBuild succeeded: |
|
bors merge |
|
Build succeeded: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This rather large change move the decryption of function execution requests from the Cyclone server to the Veritech server. Sensitive string redaction still takes place in the Cyclone server.
Prior to this change, portions of the function execution requests would be encrypted before being passed into a Veritech client call using a a public/private keypair called the "Cylone encryption key". The reason for this naming is that the request portions would be decrypted in a Cyclone server before being passed to a language server for final execution.
In order to remove any chance of a user-authored function being able to access such a decryption key, the request decryption activity is now handled back in the Veritech server before it sends the now fully decrypted request over a web socket to a Cyclone server. As a result, there is zero requirement for any message cryptography in the Cyclone server.
The second task that was performed in the Cyclone server was secret substring redaction, using a
CycloneSecretStringsRust type. With this change, the secret substring redaction still takes place in the Cyclone server but now this is realized by adding the set of "sensitive" secrets as part of every Cyclone request. This is how the Cyclone server knows which strings to redact while not participating in the original decryption of the data.As a result of the change in responsibility, these encryption/decryption keys are now known as "Veritech encryption" and "Veritech decryption" keys. Consequently all variables, CLI arguments, and files in our source tree have been updated to eliminate any possibility of future confusion.