PrivateNotebooks

Since RCloud 1.4 we support private (encrypted) notebooks. The way it works is that the contents of content$files is encrypted and stored as one special file "encrypted.notebook.content.bin.b64" in the gist.

b64 file format

.b64 files are ASCII files with an optional header starting with "## " and base64 encoded payload. Any leading lines starting with "#" are ignored for decoding. The header consists of comma-separated <key>:<value> pairs (space or tabs are allowed). If any of the characters %:, appear in either key or value, they are encoded using URI encoding. The contents of the header are stored in the "metadata" attribute of the decoded object and correspondingly are written into the header when serialized.

encrypted objects

encrypted objects have one or more of following metadata entries:

• cipher: mandatory, name of the cipher used, currently only "AES-256" is tested.
• sha1: mandatory, checksum of the object in decrypted form (such that it can be determined that a decryption was successful)
• encoding: optional, encoding of the payload. If not present, the payload is used as-is. "rds" denotes an R object serialized using R Data Serialization (see ?serialize in R).
• key.type: mandatory for notebook encryption, name of the processing type used. Currently only "group-hash" and "user-key" are supported (see below).
• salt: mandatory for for group-hash notebook encryption, salt used in constructing the encryption key
• group: mandatory for group-hash notebook encryption, ID of the group encrypting this notebook

group-hash encryption

Notebooks encrypted using group-hash encryption use AES-256 encryption based on a 256-bit key obtained from the SessionKeyServer by hashing the salt and the private group key that is stored in the SKS and never retrieved directly. SKS requires a valid token of a user belonging to the group in order to compute the notebook key. Since the notebook key is a hash, it cannot be used to attack the group key. Also it changes with every update of the notebook since a new salt is generated each time. This ensures that even if the user succeeds in intercepting the notebook key, it only allows him to view the version he already had access to, it doesn't allow decryption of any other versions of the notebook.

Technical considerations

Once the notebook is encrypted, gist modification requests no longer to to the back-end but have to be processed by RCloud. Therefore RCloud has to create the files object structure itself. This leaves only a small subset of entries compared to the version obtained form let's say the GitHub API.