Linda Lee


1) Lazy revocation: summarize this technique AND answer the question: what reason do the authors give for not re-encrypting old/unmodified data?

 

Lazy revocation is to delay re-encryption of a file until a file is updated. This is done to make revocation less expensive (it requires re-computing block hashes, re-signing root hashes, and other operations on top of re-encrypting the file). 

 

The authors’ reason for not re-encrypting unmodified data is that there is no significant loss in security if revoked readers can still read the unchanged files, since this is equivalent to the access that users had at the time before they were revoked. Of course, the meta-data needs to be changed so that revoked users don’t have write permissions.  

 

 

 

 

2) Key rotation: explain what this technique is AND what does it help with in the design of Plutus?

 

Key rotation a technique that allows for a sequence of keys with the owner of the key able to generate the next version of the key with a current version and for users of the key to be able to calculate previous versions of the key from the current version. 

 

Plutus uses key rotation to employ the notion of filegroups (a new group of files generated upon re-encryption) for lazy revocation. This technique allows the owner of the key to update their key when re-encryption is necessary and user of the key to remember only one key, but able to have access to a handful of older, related keys. It also generally reduces the number of keys in the system.

 

 

 

3) What do Merkle trees help with in Plutus?

 

 

Merkel trees help optimize Plutus by reducing the number of hashes which need to be updated when files are re-encrypted. Specifically, the root has contains information about block hashes and respective block keys (every file in Plutus is divided into small blocks and encrypted with a unique symmetric key called a file-block key).