LH*RE with Cached Encryption Keys: A Scalable Distributed Data Structure with Recoverable Encryption

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.