[
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: [email protected]
For additional commands, e-mail: [email protected]
