Skip to content

Conversation

@ggershinsky
Copy link
Contributor

@ggershinsky ggershinsky commented May 26, 2021

A set of fresh data encryption keys is generated for each data file (in formats that support native encryption). The data keys are wrapped centrally (eg in the driver), potentially via KMS interaction, and stored in the manifest key_metadata entry for this data file. The data keys are delivered via NativeFileEncryptParams objects (see #2638) to the workers that perform data file writing/encryption.

@rdblue @jackye1995 @RussellSpitzer @flyrain @aokolnychyi

@jackye1995
Copy link
Contributor

Should we combine this with the #2638 you published? They are not long and reader of this PR has to have context of that one anyway.

@ggershinsky
Copy link
Contributor Author

The idea behind the split was to use the #2638 to highlight the challenge of encryption key passing, and to discuss the difference between native and stream encryption parameters. So it keeps only the minimal set of classes required to focus on these discussion topics.
This pull request will keep growing (currently it covers only the write path). I'll cross-reference the two prs.

@ggershinsky ggershinsky changed the title Core: call native encryption API Core: Apply encryption basics to writers and readers Nov 4, 2021
@ggershinsky
Copy link
Contributor Author

Replacing with an updated version #5544

@ggershinsky ggershinsky deleted the call-native-encryption branch June 20, 2023 07:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants