abhishekmauryaKsolves commented on PR #18337: URL: https://github.com/apache/iceberg/pull/18337#issuecomment-6011058561
> > Open question: local keys use `encryption.data-key-length`, while a KMS > > generated key uses the KMS client's own key spec (e.g. AWS dataKeySpec). > > These could differ; happy to add validation if reviewers want it. > > Yes, definitely, I think we need clarity and consistency here for the users. I'd support introducing a new parameter ~ `encryption.kek-length`, that is used for local kek generation. If the KMS key generation is toggled on, each KMS client needs to make sure it uses a spec corresponding to the value of this parameter. Agreed that the key length should be consistent. Before I implement this, a few design questions: 1. Should this go into this PR or a follow-up? It touches more than this change. 2. Today KeyManagementClient.generateKey(String wrappingKeyId) has no length argument, and AwsKeyManagementClient takes its length from the kms.encryption-algorithm / data key spec catalog properties. To make clients honor encryption.kek-length, the interface needs a way to receive the length (for example a new method generateKey(String wrappingKeyId, int keyLength), with the existing one deprecated per the iceberg-core deprecation policy). Is that what you have in mind? 3. Should encryption.kek-length default to the current 16 bytes, with valid values 16/24/32 like encryption.data-key-length? 4. On the Hive path the table properties are currently passed by hand (key-id and data-key-length from HMS). Both this and the toggle property would need to follow whichever approach is chosen there. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
