[
https://issues.apache.org/jira/browse/HDFS-6134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14038415#comment-14038415
]
Yi Liu commented on HDFS-6134:
------------------------------
*1.*
{quote}
• 6. Because of #5, a possible attack would be to scan #1 files for IVs where
the 8 higher bytes match. Then, fast-forward them to a common counter point
(assuming files are long enough), then you’ll have more than one cypher-text
using the same encryption key and the same IV. The chances of this are 1/2^64,
but in cryptographic terms this is considered a high chance.
{quote}
CTR attack is not by finding two cipher-text using same encryption key and same
IV, it’s by ability of constructing file and make it encrypted by same Data key
and IV. The principle is as following: (Suppose we have two plain texts: P1 and
P2; Cipher texts: C1 and C2)
{code}
P1 XOR F(Key, IV) = C1
P2 XOR F(Key, IV) = C2
{code}
Absolutely C1 and C2 are known. To guess P2, if we just know IV (we can’t know
key, it’s secret), but don’t know P1, then we can’t get P2. But if we can
constructed P1 (then we know it), and make it encrypted by same Key and IV,
then we can easily know P2 through:
{code}
P2 = C2 XOR F(Key, IV) = C2 XOR (C1 XOR P1)
{code}
*2.*
*+1* for having two layer keys: EZ key and DEK :-). They are 3 points:
* It’s demonstrated in other traditional FS or Database, such as Oracle
transparent encryption. Fully agree with [~tucu00] "It’s a more secure
solution that EZ key can’t be accessed by client". Actually it’s also the
initial thought of two layer keys in HADOOP-10050,
* Truly support Key rotation, that’s very important. If only having EZ key,
even we have key versions, and for key rotation, we can use new version keys
for the new files, but for old files, they are still encrypted by the old
version keys (Unexpected user can still decrypt it). If we have two layer keys,
we can encrypt DEK keys using new EZ key version if necessary without decrypted
and encrypted the whole file.
* More easier management.
*3.*
{code}
KeyVersion generateEncryptedKey(String keyVersionName, byte[] iv)
KeyVersion decryptEncryptedKey(String keyVersionName, byte[] iv, KeyVersion
encryptedKey
{code}
We don’t need the iv? Parameter {{iv}} is for?
> Transparent data at rest encryption
> -----------------------------------
>
> Key: HDFS-6134
> URL: https://issues.apache.org/jira/browse/HDFS-6134
> Project: Hadoop HDFS
> Issue Type: New Feature
> Components: security
> Affects Versions: 2.3.0
> Reporter: Alejandro Abdelnur
> Assignee: Alejandro Abdelnur
> Attachments: ConceptualDesignProposal_2014-06-19.pdf,
> HDFSDataAtRestEncryption.pdf
>
>
> Because of privacy and security regulations, for many industries, sensitive
> data at rest must be in encrypted form. For example: the healthcare industry
> (HIPAA regulations), the card payment industry (PCI DSS regulations) or the
> US government (FISMA regulations).
> This JIRA aims to provide a mechanism to encrypt HDFS data at rest that can
> be used transparently by any application accessing HDFS via Hadoop Filesystem
> Java API, Hadoop libhdfs C library, or WebHDFS REST API.
> The resulting implementation should be able to be used in compliance with
> different regulation requirements.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
