accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Allen (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-980) support pluggable codecs for RFile
Date Fri, 01 Feb 2013 22:06:12 GMT


Michael Allen commented on ACCUMULO-980:

The design I'm seeing here is that each RFile will have its own encryption key embedded with
in its own crypto header block.  That key (call it an RFile encryption key) will be in turn
encrypted to a different key handled by an outside entity (this is where that SecretKeyEncryptionStrategy
class comes into play).  Should that external key become compromised, then *presumably* the
only thing that needs to be rekeyed is the RFile encryption key; however, I don't think HDFS
works that way, because one can only write a file once, correct?  If you really wanted to,
you could "rekey" the RFile encryption key by creating a new copy of the RFile with its encryption
key decrypted by the old key and re-encrypted to the new key.  The rest of the RFile would
not have to be decrypted and re-encrypted but the file would presumably have to be copied.

If this were a grave concern, then the way to solve it would be to make the crypto block an
external file to the RFile rather than something embedded inside it.  The only problem with
that structure is the possibility of the RFile becoming separated from its companion crypto
block, and general untidiness putting lots of little files everywhere causes.  Since these
files generally aren't dealt with directly by users or administrators, maybe this is the direction
to go?
> support pluggable codecs for RFile
> ----------------------------------
>                 Key: ACCUMULO-980
>                 URL:
>             Project: Accumulo
>          Issue Type: Improvement
>            Reporter: Adam Fuchs
>            Assignee: Adam Fuchs
>             Fix For: 1.6.0
>         Attachments: RFile-Changes-Proposal-V1.pdf
> As part of the encryption at rest story, RFile should support pluggable modules where
it currently has hardcoded options for compression codecs. This is a natural place to add
encryption capabilities, as the cost of encryption would likely not be significantly different
from the cost of compression, and the block-level integration should maintain the same seek
and scan performance. Given the many implementation options for both encryption and compression,
it makes sense to have a plugin structure here.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message