A sealed value is bound to its key but not to its place

[vmillet-dev]

Vault::seal_bytes calls encrypt(nonce, plaintext) with no associated data, so a sealed value is bound to the key and to nothing else. The GCM tag says "this was sealed by someone holding the key". It never says "this belongs in this row, in this column".

Anyone who can write the database file can therefore shuffle sealed values around, and the application opens every one of them and calls the result genuine.

Demonstrated

UPDATE notes SET content = title against a copy of the library, with no key at all:

RELOCATION 4/4 relocated ciphertexts still authenticate

The same shape covers the rest: swapping two notes' titles, copying one note's body over another's, moving an attachment's bytes onto a different attachment record, or rolling a value back to a ciphertext captured from an older backup. a_tampered_value_is_refused_rather_than_opened still passes throughout — it flips a byte, which is a different attack from moving an intact value.

Why it is worth fixing even though the threat model is "a file read at rest"

Confidentiality holds here; this is integrity. But the library is the place people keep the command that worked, and a note that silently becomes a different note is a nastier failure than one that refuses to open. The backups make the rollback variant realistic: an old devbox.sqlite3 sits right there, sealed under the same master key, so values from it paste cleanly into today's file.

Shape

• Pass AAD binding each value to its identity: note_id || column for a note field, the space or folder id for a name, the attachment id for a file's bytes. seal/open grow a context argument, and the call sites are the only places that know what the context is.
• ⚠️ This is a format change. Every value already on disk was sealed with empty AAD and will not open under a context. Decide between a migration that rewrites every sealed value — which is a full re-encrypt, with the atomicity problem Decide whether the database is encrypted at rest, and against what #26 avoided — and a version flag in vault.json that keeps reading old values without AAD while writing new ones with it. The second is cheaper and leaves the old rows attackable until they are next written.
• Whatever is chosen, seal/open should stop being callable without a context, or the next feature will forget it the way this one could not have remembered it.

Done when

Moving an intact sealed value to another row, another column or another file is refused, and a test moves one to prove it.

[vmillet-dev]

Décision (Valentin) : migration complète au prochain déverrouillage.

Pas de drapeau de version qui laisserait les anciennes lignes déplaçables : chaque valeur scellée est réécrite avec son contexte, en une passe, à l'ouverture qui suit la mise à jour.

Ce que cela impose, et qui n'était pas dans le ticket :

• ⚠️ L'atomicité est le problème, et elle n'a pas de forme simple — c'est exactement ce que Decide whether the database is encrypted at rest, and against what #26 avait évité. La base peut se faire en une transaction ; les pièces jointes sont des fichiers à côté, donc la passe est base + N fichiers et ne peut pas être une seule unité.
• Il faut donc un marqueur repris plutôt qu'un tout-ou-rien : la version de format vit dans vault.json, et n'est avancée qu'une fois la passe finie. Une passe interrompue laisse un mélange des deux formats, et la lecture doit donc accepter les deux pendant la migration — le drapeau écarté comme régime permanent revient comme état transitoire, ce qui est une autre chose.
• Une pièce jointe réécrite l'est à côté puis renommée, jamais en place : fs::write tronque, et une coupure au milieu d'un fichier de 10 Mo le perd.
• La passe se fait après quick_check et après backup::rotate — la copie du jour doit précéder la réécriture, pas la suivre.
• Elle a besoin d'être visible : sur une bibliothèque de plusieurs milliers de notes ce n'est pas instantané, et un gate qui semble figé est un gate qui se fait tuer au gestionnaire des tâches.

seal / open cessent d'être appelables sans contexte, comme le ticket le demandait.

[vmillet-dev]

Conception, avant d'écrire

Décision (Valentin) : les exports restent hors du changement. Un bundle protégé est un seul payload scellé avec une clé à lui — il n'y a pas de ligne à laquelle le lier, et déplacer une valeur à l'intérieur voudrait dire resceller le blob entier de toute façon. Aucun gain d'intégrité, et tous les fichiers protégés déjà écrits restent lisibles. transfer/protect.rs et FORMAT_VERSION ne bougent pas.

⚠️ Conséquence à assumer par écrit : seal / open ne peuvent donc pas devenir strictement inappelables sans contexte, contrairement à ce que le ticket demandait. Il reste une porte, et elle sert à une chose. La forme retenue : seal_bytes / open_bytes bruts deviennent pub(crate) et portent un nom qui dit ce qu'ils sont (seal_payload / open_payload), et seuls transfer/protect.rs et transfer/file.rs les appellent. Tout ce qui touche une ligne passe par la paire à contexte.

Le contexte, en type et pas en chaîne

Un &str libre inviterait "". Un enum ferme la liste et rend une colonne scellée de plus impossible à ajouter sans la déclarer :

pub enum Aad<'a> {
    NoteTitle(&'a str), NoteContent(&'a str), NoteSource(&'a str),
    SpaceName(&'a str), FolderName(&'a str),
    NoteItem { note: &'a str, position: i32 },
    NotePlaceholder { note: &'a str, name: &'a str },
    GlobalPlaceholder(&'a str),
    AttachmentName(&'a str), AttachmentBytes(&'a str),
}

⚠️ L'encodage est préfixé en longueur, pas délimité : un nom d'espace ou de dossier est du texte libre, donc un séparateur choisi se retrouverait un jour dedans et deux contextes différents produiraient les mêmes octets.

La migration

• Elle tourne au déverrouillage, après quick_check et après backup::rotate — la copie du jour doit précéder la réécriture, sinon la seule copie saine est déjà réécrite.
• Le marqueur est une version dans vault.json, avancée uniquement quand la passe entière est finie.
• ⚠️ Tant que le marqueur est en retard, open accepte les deux formats : contexte d'abord, puis repli sans AAD. C'est exactement le régime transitoire que l'option « drapeau de version » proposait comme permanent, et tu l'as écarté comme permanent — ici il est borné par le marqueur, et le repli devra être supprimé dans une version ultérieure, pas laissé à traîner.
• La base en une transaction ; les fichiers de pièces jointes après le commit, écrits à côté puis renommés (fs::write tronque, et une coupure au milieu d'un fichier de 10 Mo le perd).
• ⚠️ La passe est idempotente grâce à la double lecture : une valeur déjà reliée se rouvre avec son contexte et se réécrit à l'identique. Donc une interruption entre le commit et la fin des fichiers se rattrape simplement en refaisant tout au lancement suivant.
• Elle doit être visible : sur plusieurs milliers de notes ce n'est pas instantané, et un gate qui semble figé est un gate qu'on tue au gestionnaire des tâches.

Le test qui compte

UPDATE notes SET content = title sur une copie, sans clé — la démonstration du ticket — doit refuser d'ouvrir. Et le test existant a_tampered_value_is_refused_rather_than_opened reste, il couvre une autre attaque (un octet retourné, pas une valeur intacte déplacée).

[vmillet-dev]

Abandonné pour 0.3.1 (décision de Valentin) : trop de changement pour ce que ça rapporte ici.

Sorti de la milestone, remis au Backlog. Ce qui l'a fait tomber, pour que personne ne le rouvre sans revoir le calcul : la migration complète retenue touchait ~58 sites d'appel de scellement, un type de contexte nouveau, une passe base + fichiers de pièces jointes avec marqueur repris, une double lecture transitoire à supprimer ensuite, et une progression au gate. Le tout pour une faille dont le modèle de menace est « quelqu'un a déjà le fichier ».

⚠️ Ce qui reste vrai et qu'il ne faut pas oublier en relisant ce ticket fermé de fait :

• La confidentialité tient — rien ici ne rend une note lisible. C'est une faille d'intégrité : qui peut écrire le fichier peut déplacer une valeur scellée intacte d'une ligne à l'autre, et l'application l'ouvre et la donne pour authentique.
• La variante la plus réaliste reste le retour en arrière : une ancienne devbox.sqlite3 est dans backups/, scellée sous la même clé maîtresse, donc ses valeurs se recollent proprement dans le fichier du jour.
• a_tampered_value_is_refused_rather_than_opened ne couvre pas ça : il retourne un octet, ce qui est une autre attaque.

Si ça revient un jour, la version moins chère existe et avait été proposée : un drapeau de version dans vault.json, écriture avec contexte, lecture des deux formats, et les anciennes lignes restent déplaçables jusqu'à leur prochaine réécriture. Ça ne coûte pas de migration — seulement les sites d'appel.