# Lokale verschlüsselte Pakete

Experimenteller lokaler Baustein, **kein fertiger privater Remote-Workflow**.
`private-package` verschlüsselt eine reguläre Datei von höchstens 1 MiB mit einem
neuen zufälligen AES-256-GCM-Schlüssel. Go erzeugt die Nonce; Repository-ID,
Epoche und Dateityp sind authentisierter Kontext. Keine Passwortableitung,
Wallet- oder Identitykey-Konvertierung, keine Serverkommunikation.

```sh
mf private-package new-id
mf private-package seal --file recovery-input.json --output /backups/package.json --key-dir /separate/protected/key-1 --repo mf:private:REPLACE_WITH_64_LOWERCASE_HEX --epoch 1 --kind recovery
mf private-package open --file /backups/package.json --output /restores/recovered.json --key-dir /separate/protected/key-1 --repo mf:private:REPLACE_WITH_64_LOWERCASE_HEX --epoch 1 --kind recovery
```

`new-id` liefert eine zufällige öffentliche Repositorykennung, keinen Schlüssel.
`seal` legt im ausdrücklich genannten Schlüsselverzeichnis exklusiv eine neue
`recovery.key` an. Jeder neue Export benötigt ein eigenes neues Schlüsselziel.
Ein vorhandener, fehlgebildeter oder unsicher gespeicherter Schlüssel wird nie
überschrieben oder regeneriert. `open` benötigt einen vorhandenen gültigen
Schlüssel. Schlüssel stehen weder in Befehlszeilenargumenten noch in stdout.

Ausgabeverzeichnisse müssen vorhanden und vertrauenswürdig sein; neue
Schlüsselverzeichnisse entstehen mit 0700. Unter Linux gelten UID-/Modusprüfungen
für Schlüssel- und Ausgabeverzeichnisse, Schlüsseldateien benötigen 0400 oder
0600. Neue Dateien erhalten 0600. Windows-Sicherheit hängt weiterhin von den
ACLs des Benutzerverzeichnisses ab; eine Windows-KeyStore-Integration ist dies
nicht. Quell- und Schlüsseldateien müssen begrenzte reguläre Dateien sein;
Symlinks und Spezialdateien werden abgewiesen.

Die erwartete Repo-ID, Epoche und Art (`object`, `manifest`, `recovery`) müssen
beim Öffnen aus einem unabhängig behaltenen Recoveryzettel stammen. Alle drei
Werte sind ausdrücklich erforderlich. Allein aus einem fremden Envelope
übernommener Kontext wäre kein unabhängiger Schutz gegen Paketverwechslung.
Erst nach vollständiger Authentifizierung entsteht eine neue Klartextdatei;
falscher Schlüssel, veränderter Kontext, beschädigte Bytes und unbekannte
Kodierung erzeugen keine Ausgabe. Vorhandene Ausgaben werden nie ersetzt.

Schlüssel und verschlüsseltes Paket liegen in getrennten Verzeichnissen und
sollten auf getrennten geschützten Sicherungsmedien verwahrt werden. Bei einem
Fehler während der Paketausgabe bleibt ein bereits installierter Schlüssel
erhalten; ihn nicht ungeprüft löschen oder einen vorhandenen Export ersetzen.
Ein Syncfehler nach Installation wird als unklarer Durability-Ausgang gemeldet.
Ohne Schlüssel ist das Paket nicht wiederherstellbar. Mit Schlüsselzugriff sind
dessen Inhalte lesbar. Lokaler Administrator und kompromittierter Client sind
weiterhin Vertrauensgrenzen; rückstandsfreies Entfernen aus RAM ist nicht garantiert.

Das Paket vergibt keine Remote-Schreibrechte, signiert keine Identität, ersetzt
keinen aktuellen Membershipcheckpoint und stellt keine ganze Repositoryhistorie
automatisch wieder her. Dafür sind eigene geprüfte Backup-/Restore- und
Private-Sync-Pfade erforderlich. Bekannte Schlüsseldateinamen `identity.key`,
`recovery.key`, `private.key` werden vor öffentlichem Snapshotupload auch innerhalb
von Unterverzeichnissen abgewiesen; zusätzliche eigene Secrets müssen weiterhin
außerhalb von Quellprojekten liegen.

[Verschlüsselungs-/Remoteentwurf](PRIVATE_REMOTE_DESIGN.md) ·
[Schlüsselablage](KEY_STORAGE.md) · [Recoveryentwurf](RECOVERY_DESIGN.md)