Some questions about E2EE implementation

GSoC Projects Encrypted Notes
1

Hey,

First, thanks for building Joplin. I've had some questions about the threat model / implementation of the end to end encryption:

  1. Are encrypted item headers, especially the field identifying the master key used for an item, authenticated as part of the encrypted payload or AEAD associated data?

    I am asking because the encrypted item format appears to include metadata that tells the client which master key to use. I would like to understand whether this metadata is integrity-protected against modification by an untrusted sync target.

  2. Can a malicious or compromised sync target influence which master key or recipient key a client uses when encrypting data?

This follows from the previous question: if key identifiers or key material can be supplied or modified through the sync target, it would be useful to know what checks prevent key-substitution attacks.

  1. For note sharing, how are recipient public keys authenticated? Are users expected to verify keys out of band, or is the sync target trusted to provide the correct public key?

because the sharing model seems to involve public keys being distributed via the sync target. I could not tell from the documentation whether the sync targte is part of the trust model for public-key authenticity.

  1. Since sharing public keys appear to be stored in plaintext on the sync target, what prevents a malicious sync target from replacing a recipient public key and causing shared content to be encrypted to an attacker-controlled key?

This is the concrete attack scenario I am trying to understand: whether a server that controls sync data could replace a recipient’s public key before sharing is established.

  1. Is there a specific reason why unused master key blobs cannot be deleted? Is this a cryptographic requirement, a sync compatibility issue, or technical debt?

because old encrypted master key blobs remaining on the sync target may still matter if a weak or reused master password is later cracked, especially if the sync target keeps historical data.

  1. How is the e2ee implementation maintained today?

I am asking because the e2ee implementation seems to be a GSOC contribution, so I asked myself who currently owns or reviews this code, whether there is ongoing cryptographic maintenance.

Again thanks for developing this and kind regards.

2

hey, thanks for writing these out. the first question overlaps with some recent work i did in EncryptionService.

encrypted item headers store the encryption method and master key ID separately from encrypted content. content is authenticated, but outer header isn’t currently included as associated data.

Joplin uses the key ID from that header to find a key for decryption, if it’s missing, decryption stops, and using a different key should fail content authentication. the supplied-key path i added also checks that its key ID matches the one in the header.

my project uses the same format with a separate note-lock key, so keeping key ID tied to decrypted key bytes was something we had to handle too, i haven’t gone deep enough into sharing public-key flow or old E2EE key cleanup to answer those parts confidently yet.