patrickandClaude Sonnet 5
0ea129e71c
seal/open (bzw. wrap/unwrap) in allen vier betroffenen Stellen binden ein Additional Authenticated Data an Chiffretext/DEK-Wrapper: ein Austausch zwischen zwei Kontexten faellt beim Entschluesseln auf, statt still zu funktionieren. - dms/internal/crypto/envelope.go + service.go: AAD = Tenant-Slug (bereits vorhandener Parameter in Service.Seal/Open, Signatur unveraendert -- keine der rund 30 externen Aufrufstellen musste angepasst werden) - archive/internal/backupcrypto/envelope.go + reposecret.go/file.go: gleiches Muster, AAD = Tenant-Slug - mail/internal/crypto/envelope.go + service.go + kekversions.go: gleiches Muster, AAD = Tenant-Slug (inkl. ARC-08 KEK-Versionsverwaltung) - internal/kek/master.go + store.go: wrap/unwrap sowie EncryptWithTenantKEK/DecryptWithTenantKEK binden AAD. Die drei echten externen Aufrufer angepasst: ldapsync (Tenant-ID + Zweck), webhook (Ziel-URL des Abonnements), account-api modulekeys (fester Zweck-Bezeichner -- SecretCipher-Interface aus internal/moduletrust reicht keine Datensatz-ID durch, eine Erweiterung wuerde in andere Module hineinwirken, bewusst nicht Teil dieser Kachel) Rueckwaertskompatibel: jedes open/unwrap versucht zuerst mit AAD, faellt bei Fehlschlag auf kein-AAD zurueck -- vor dieser Aenderung versiegelte Datensaetze bleiben lesbar. Bekannte, dokumentierte Grenze: ein Austausch zwischen zwei Datensaetzen DESSELBEN Mandanten/Kontexts bleibt unerkannt (identisches AAD) -- volle Bindung an den einzelnen Datensatz braeuchte eine Datensatz-ID an rund 30 Aufrufstellen, bewusst nicht Teil dieser kleinstmoeglichen Loesung. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>