Is the E2E RFC an accurate description of the E2E implementation in v20?

💻 Development
1

I’m working on a new client (CLI/daemon) that supports E2E encryption. Before I get into the details I want to make sure that https://github.com/nextcloud/end_to_end_encryption_rfc/blob/master/RFC.md accurately reflects the E2E implementation in NextCloud v20.

2

cc @tobiasKaminsky @rullzer

3

@tobiasKaminsky, @rullzer -

I do have some specific questions -

  1. What is the order of operations for uploading a new file? The “Update metadata file” section indicates that locking comes before uploading. -

After locking was successful, the client will upload the encrypted file and afterwards the metadata file. If both files are uploaded successfully, the client will finish the operation by sending an unlock request.

However in the “Uploading new files” section the locking the folder operation is in step 4, after uploading the file in step 2.

  1. How do I handle creating a new folder in an encrypted folder (a sub-directory). The same as uploading a new file? Something else?

  2. Can I upload multiple encrypted files with only a single update to the metadata file? Imagine a client that polls for updates to the local file system every 30 seconds. Multiple new files are found in an E2E encrypted folder. Can I -

  1. Lock the directory (assuming a lock comes first, see above).
  2. Encrypt, create UUIDs, and upload multiple files.
  3. Add the metadata for the multiple files to the metadata file.
  4. PUT the updated metadata file.
  5. Unlock the folder?

  1. Should openSSL clients append the tag during encryption? In the Implementation details the difference between the encryption behavior in openSSL and Android is identified but a standard isn’t set. The pseudocode seems to indicate that openSSL clients should append the tag.

  2. How should a client handle permanently losing its e2e-token while a lock is in place? Obviously the client would attempt to prevent this.

Can you confirm these details match the current implementation?

  • The use of a 128-bit key and IV.
  • The use of AES/GCM/NoPadding.
  • UUIDs must not have the traditional '-' and must follow /^[0-9a-fA-F]{32}$/.
  • The use of a 2048 RSA for the private key
  • The defined constants for encryption/decryption -
    saltLength: 40 bytes
    iterations: 1024
    keyLength: 32 bytes (256 bit)
    ivDelimiter: "|"

Thanks,
Craig