hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rushabh S Shah (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (HADOOP-14705) Add batched reencryptEncryptedKey interface to KMS
Date Fri, 18 Aug 2017 17:44:00 GMT

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

Rushabh S Shah edited comment on HADOOP-14705 at 8/18/17 5:43 PM:
------------------------------------------------------------------

{quote}
If it is reused, and if CryptoCodec uses SecureRandom, the random numbers generated in DefaultCryptoExtension#generateEncryptedKey
may become predictable.
{quote}
Thats a good question and a valid security concern.
As far as {{DefaultCryptoExtension#generateEncryptedKey}} is concerned, here is the workflow
to generate {{secureRandom}} bytes.
{{DefaultCryptoExtension#generateEncryptedKey(String encryptionKeyName)} --> {{OpensslAesCtrCryptoCodec#generateSecureRandom(byte[]
bytes)}} --> {{OsSecureRandom#nextBytes(byte[] bytes)}} --> {{OsSecureRandom.fillReservoir(int
min)}}.
All {{OsSecureRandom#fillReservoir(int min)}} does is read random bytes from {{/dev/urandom}}.
{code:title=OsSecureRandom.java|borderStyle=solid}
 private void fillReservoir(int min) {
    if (pos >= reservoir.length - min) {
      try {
        if (stream == null) {
          stream = new FileInputStream(new File(randomDevPath)); // randomDevPath = /dev/urandom
        }
        IOUtils.readFully(stream, reservoir, 0, reservoir.length);
      } catch (IOException e) {
        throw new RuntimeException("failed to fill reservoir", e);
      }
      pos = 0;
    }
  }
{code}
The whole workflow assumes we take default values from {{hadoop.security.secure.random.impl}},
{{hadoop.security.random.device.file.path}} and {{hadoop.security.crypto.cipher.suite}}


was (Author: shahrs87):
{quote}
If it is reused, and if CryptoCodec uses SecureRandom, the random numbers generated in DefaultCryptoExtension#generateEncryptedKey
may become predictable.
{quote}
Thats a good question and a valid security concern.
As far as {{DefaultCryptoExtension#generateEncryptedKey}} is concerned, here is the workflow
to generate {{secureRandom}} bytes.
{{DefaultCryptoExtension#generateEncryptedKey(String encryptionKeyName)} --> {{OpensslAesCtrCryptoCodec#generateSecureRandom(byte[]
bytes)}} --> {{OsSecureRandom#nextBytes(byte[] bytes)}} --> {{OsSecureRandom.fillReservoir(int
min)}}.
All OsSecureRandom#fillReservoir(int min) does is read random bytes from "/dev/urandom".
{code:title=OsSecureRandom.java|borderStyle=solid}
 private void fillReservoir(int min) {
    if (pos >= reservoir.length - min) {
      try {
        if (stream == null) {
          stream = new FileInputStream(new File(randomDevPath)); // randomDevPath = /dev/urandom
        }
        IOUtils.readFully(stream, reservoir, 0, reservoir.length);
      } catch (IOException e) {
        throw new RuntimeException("failed to fill reservoir", e);
      }
      pos = 0;
    }
  }
{code}
The whole workflow assumes we take default values from {{hadoop.security.secure.random.impl}},
{{hadoop.security.random.device.file.path}} and {{hadoop.security.crypto.cipher.suite}}

> Add batched reencryptEncryptedKey interface to KMS
> --------------------------------------------------
>
>                 Key: HADOOP-14705
>                 URL: https://issues.apache.org/jira/browse/HADOOP-14705
>             Project: Hadoop Common
>          Issue Type: Improvement
>          Components: kms
>            Reporter: Xiao Chen
>            Assignee: Xiao Chen
>         Attachments: HADOOP-14705.01.patch, HADOOP-14705.02.patch, HADOOP-14705.03.patch,
HADOOP-14705.04.patch, HADOOP-14705.05.patch, HADOOP-14705.06.patch, HADOOP-14705.07.patch,
HADOOP-14705.08.patch
>
>
> HADOOP-13827 already enabled the KMS to re-encrypt a {{EncryptedKeyVersion}}.
> As the performance results of HDFS-10899 turns out, communication overhead with the KMS
occupies the majority of the time. So this jira proposes to add a batched interface to re-encrypt
multiple EDEKs in 1 call.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: common-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-issues-help@hadoop.apache.org


Mime
View raw message