LH*RE is a Scalable Distributed Data Structure, first described in [JLS8]. We designed it to store many records protected through key encryption in a scalable file. As often, key management and in particular preventing the loss of keys is of utmost importance. LH*RE is an LH*‐scheme, hence stores records on behalf of clients on any number of servers addressed through the scalable distributed hashing of the record identifiers. LH*RE client encrypts each record using client chosen secret key cryptography. The client also encodes each key using the secret‐sharing. Shares are stored at servers, different for each share and randomly chosen. The client chooses the secret size, i.e., the number of shares. An attacker of a key has to locate all the secret‐sharing servers. The task appears overwhelming for an LH*RE file, typically on many servers. An authorized user may recover or revoke in contrast rather rapidly every key, lost, corrupted or of a missing encryptor. LH*RE frees in this way the users from the well‐known daring chores of the client‐side key maintenance. The LH*RE description in [JLS8] specifies a basic scheme and sketches variants for future work. The basic scheme uses a new encryption key for every record, minimizing the number of disclosed records if the unthinkable happened. The storage overhead of encryption, while different for each variant, is always negligible. The basic scheme has the highest insert, update, delete, and search message count costs. In [JLS8a], we analyze a variant lowering search and update costs. Below, we discuss next variant lowering also record insert and delete message count costs. The overall result is the message count per operation of basic LH*, i.e., without any encryption related message count overhead. For some applications, this may be a compelling advantage. The client caches the encryption key space with, at will, a single key for all the records or with a large number, e.g., a million keys. The key space can scale, as well as the secret size. We discuss the scheme algorithmic, performance and design criteria, including the rationale for choosing the key space size.
[1]
Sushil Jajodia,et al.
Secure Dynamic Fragment and Replica Allocation in Large-Scale Distributed File Systems
,
2003,
IEEE Trans. Parallel Distributed Syst..
[2]
Ethan L. Miller,et al.
POTSHARDS: Secure Long-Term Storage Without Encryption
,
2007,
USENIX Annual Technical Conference.
[3]
Witold Litwin,et al.
LH* RSP2P : A Scalable Distributed Data Structure for P2P Environment
,
2008
.
[4]
Witold Litwin,et al.
LH*—a scalable, distributed data structure
,
1996,
TODS.
[5]
Witold Litwin,et al.
LH*RS---a highly-available scalable distributed data structure
,
2005,
TODS.
[6]
R. Hu,et al.
Switched-current 3-bit CMOS 4.0-MHz wideband random signal generator
,
2005,
IEEE Journal of Solid-State Circuits.
[7]
Adi Shamir,et al.
How to share a secret
,
1979,
CACM.
[8]
Taieb Znati,et al.
SCAR - Scattering, Concealing and Recovering Data within a DHT
,
2008,
41st Annual Simulation Symposium (anss-41 2008).