You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@kudu.apache.org by "kirby zhou (Jira)" <ji...@apache.org> on 2022/04/06 07:20:00 UTC

[jira] [Comment Edited] (KUDU-3316) Store encrypted encryption keys in encrypted files

    [ https://issues.apache.org/jira/browse/KUDU-3316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17517893#comment-17517893 ] 

kirby zhou edited comment on KUDU-3316 at 4/6/22 7:19 AM:
----------------------------------------------------------

I see you add a fixed 32 byte length of EEK in the header. 

https://github.com/apache/kudu/blob/master/src/kudu/util/env_posix.cc

 
{code:java}
L268:
struct EncryptionHeader {
  EncryptionAlgorithm algorithm;
  uint8_t key[32];
}; {code}
In my opinion, EEK had better be of variable length.

 

 

If we use some kind of KMS to manage the EEK, the size of EEK may vary with different KMS. For example, KMS can encode the name and version of ZoneKey into EEK, and do some base64-encoding. The EEK may grows to hundreds of bytes.

 

Another problem,

The IV of AES-CTR is hard-coded in DoEncryptV,

https://github.com/apache/kudu/blob/master/src/kudu/util/env_posix.cc
{code:java}
L455:
Status DoEncryptV(const EncryptionHeader* eh,
                  uint64_t offset,
                  ArrayView<const Slice> cleartext,
                  ArrayView<Slice> ciphertext) {
  DCHECK_EQ(cleartext.size(), ciphertext.size());
  // Set the initialization vector based on the offset.
  uint8_t iv[16];
  InlineBigEndianEncodeFixed64(&iv[0], 0);
  InlineBigEndianEncodeFixed64(&iv[8], offset / kEncryptionBlockSize); {code}
From the security point of view, The first 8-octet of IV should be filled as random number and stored in file header.

 


was (Author: kirbyzhou):
I see you add a fixed 32 byte length of EEK in the header. 

 

In my opinion, EEK had better be of variable length.

 

If we use some kind of KMS to manage the EEK, the size of EEK may vary with different KMS. For example, KMS can encode the name and version of ZoneKey into EEK, and do some base64-encoding. The EEK may grows to hundreds of bytes.

 

Another problem,

The IV of AES-CTR is hard-coded in DoEncryptV,

  InlineBigEndianEncodeFixed64(&iv[0], 0);
  InlineBigEndianEncodeFixed64(&iv[8], offset / kEncryptionBlockSize);

From the security point of view, The first 8-octet of IV should be filled as random number and stored in file header.

 

> Store encrypted encryption keys in encrypted files
> --------------------------------------------------
>
>                 Key: KUDU-3316
>                 URL: https://issues.apache.org/jira/browse/KUDU-3316
>             Project: Kudu
>          Issue Type: Sub-task
>            Reporter: Attila Bukor
>            Assignee: Attila Bukor
>            Priority: Major
>




--
This message was sent by Atlassian Jira
(v8.20.1#820001)