Note contents are revealed to the server

[kjvalencik]

Burnernote is not end-to-end encrypted, allowing a malicious server or MitM on TLS to read contents of notes. This is not solvable with the current design of performing encryption on the server. However, the required APIs are available in WebCrypto.

Proposal

Create Secure Note

In the client:

1. Generate an AES key
2. Encrypt the contents of the note with that key
3. Export the key and encode (hex or base64url is fine)
4. Upload the encrypted note contents to the server
5. Provide a URL with the AES key as a fragment. Fragments are not sent to the server when a URL is visited

Read a secure note

In the client:

1. Download the encrypted note from the server
2. Decode and import the AES key from the URL fragment
3. Decrypt the note

Optional Improvements

The above is sufficient for end-to-end encryption, but could be improved at the cost of additional complexity.

Protect Ciphertext

The proposal above keeps the plaintext and key secret, but still allows an external attacker to download the ciphertext with only the URL (no fragment). This allows an offline attack of the ciphertext. It also leaks metadata about the plaintext (e.g., it's length) even if the attacker is unable to decrypt it.

An additional shared signing key can be generated. This key is shared with the server when a secure note is created, but not shared when a note is viewed.

The rough idea:

• Client generates a signing key
• Client uploads the signing key with the encrypted note
• On view, when fetching the ciphertext, the client uses the shared secret to sign a token containing the note id and a timestamp.
• The server uses the shared secret uploaded previously to verify the signature on the token. It additionally checks that the timestamp is within a tolerance. Only after validation does it provide the ciphertext.

This could also be done with an asymmetric key (e.g, RSA) to prevent the sharing secret from being sent to the server. But, in practice this doesn't provide any benefits:

• An attacker that is able to see the signing secret in transit could see the ciphertext at the same time
• Someone that is able to view the signing secret in the database could also view the ciphertext