242 lines
4.5 KiB
Markdown
242 lines
4.5 KiB
Markdown
Yes — **you can, and this is actually a *very strong* pattern** in your model.
|
||
But it only works if you are precise about **what is being trusted** and **what is being hidden**.
|
||
|
||
The short version:
|
||
|
||
> **Yes: you can store encrypted blocks from a personal domain inside a public domain, safely, as long as encryption is treated as content and keys are never part of federation.**
|
||
|
||
Below is the clean, formal way to do it.
|
||
|
||
---
|
||
|
||
# Encrypted Block Storage Across Domains
|
||
|
||
---
|
||
|
||
## 1. Core principle (non-negotiable)
|
||
|
||
> **Public domains may store bytes they cannot interpret, validate, or decrypt — but never assert meaning for them.**
|
||
|
||
The *meaning* stays private.
|
||
The *storage* is outsourced.
|
||
|
||
---
|
||
|
||
## 2. What is actually stored in the public domain
|
||
|
||
The public domain stores:
|
||
|
||
* **Encrypted ASL blocks**
|
||
* Content-addressed by ciphertext hash
|
||
* Snapshot-pinned
|
||
* Garbage-collectable under public policy
|
||
|
||
It does **not** store:
|
||
|
||
* Keys
|
||
* Key identifiers
|
||
* Decryption metadata
|
||
* Plaintext hashes
|
||
* Domain semantics
|
||
|
||
---
|
||
|
||
## 3. Encryption model (minimal and safe)
|
||
|
||
### 3.1 Block encryption
|
||
|
||
Before block sealing:
|
||
|
||
```
|
||
plaintext_block
|
||
→ encrypt(K)
|
||
→ ciphertext_block
|
||
→ BlockID = HASH(ciphertext_block)
|
||
```
|
||
|
||
Important:
|
||
|
||
* Encryption happens **before sealing**
|
||
* BlockID is over ciphertext
|
||
* Deterministic encryption is NOT required
|
||
* Randomized AEAD is fine
|
||
|
||
---
|
||
|
||
### 3.2 Key ownership
|
||
|
||
* Keys belong **only** to the personal domain
|
||
* Keys are **never federated**
|
||
* Keys are not referenced by ArtifactIndex entries
|
||
|
||
Encryption keys are **out-of-band capability**.
|
||
|
||
---
|
||
|
||
## 4. How the public domain sees these blocks
|
||
|
||
From the public domain’s perspective:
|
||
|
||
* These are opaque blocks
|
||
* They are indistinguishable from random data
|
||
* They have no semantic index entries
|
||
* They cannot be interpreted or replayed
|
||
|
||
This is good.
|
||
|
||
---
|
||
|
||
## 5. How your personal domain references them
|
||
|
||
Your personal domain keeps:
|
||
|
||
* ArtifactIndex entries referencing ciphertext BlockIDs
|
||
* Decryption metadata *locally* (or derivable)
|
||
* Snapshot-pinned authority over interpretation
|
||
|
||
Example:
|
||
|
||
```
|
||
Artifact(personal-photo-archive)
|
||
→ BlockID(ciphertext)
|
||
→ Decrypt with K
|
||
```
|
||
|
||
---
|
||
|
||
## 6. Cross-domain reference mechanics
|
||
|
||
There are **two distinct references**:
|
||
|
||
### 6.1 Storage reference (public domain)
|
||
|
||
Public domain:
|
||
|
||
* Owns physical blocks
|
||
* Manages retention
|
||
* Applies GC per its policy
|
||
|
||
No semantic claims.
|
||
|
||
---
|
||
|
||
### 6.2 Semantic reference (personal domain)
|
||
|
||
Personal domain:
|
||
|
||
* Owns ArtifactKey → ArtifactLocation
|
||
* Owns decryption
|
||
* Owns provenance
|
||
* Owns meaning
|
||
|
||
---
|
||
|
||
## 7. Trust & threat model (explicit)
|
||
|
||
### Public domain can:
|
||
|
||
* Delete data (availability loss)
|
||
* Rate-limit access
|
||
* Mirror data
|
||
|
||
### Public domain cannot:
|
||
|
||
* Read content
|
||
* Forge artifacts
|
||
* Alter meaning
|
||
* Impersonate you
|
||
|
||
If they delete data, integrity still holds — availability is a *separate* concern.
|
||
|
||
---
|
||
|
||
## 8. Federation and publication rules
|
||
|
||
### What you publish to public domain
|
||
|
||
You publish:
|
||
|
||
* Encrypted blocks
|
||
* Optional block size metadata
|
||
* No ArtifactIndex
|
||
* No TGK edges
|
||
|
||
This is **storage federation**, not semantic federation.
|
||
|
||
---
|
||
|
||
### What you never publish
|
||
|
||
* Plaintext artifacts
|
||
* PERs
|
||
* Index entries
|
||
* Keys
|
||
* Origin attestations
|
||
|
||
---
|
||
|
||
## 9. Optional: Explicit Storage-Only Contract (recommended)
|
||
|
||
To make this explicit, define:
|
||
|
||
```text
|
||
StorageOnlyContract {
|
||
provider_domain : DomainID
|
||
consumer_domain : DomainID
|
||
retention_terms : enum
|
||
confidentiality : "opaque-bytes-only"
|
||
}
|
||
```
|
||
|
||
This contract is:
|
||
|
||
* Snapshot-pinned
|
||
* Signed by both domains
|
||
* Human-auditable
|
||
|
||
---
|
||
|
||
## 10. Recovery flow (important)
|
||
|
||
If you later need to recover:
|
||
|
||
1. Fetch ciphertext blocks from public domain
|
||
2. Verify hash
|
||
3. Decrypt with private keys
|
||
4. Reconstruct artifacts via personal index
|
||
5. Replay snapshots
|
||
|
||
Public domain never learns anything.
|
||
|
||
---
|
||
|
||
## 11. Why this is safe even under hostile public domains
|
||
|
||
Because:
|
||
|
||
✔ Integrity is content-addressed
|
||
✔ Meaning is private
|
||
✔ Keys never cross domains
|
||
✔ No trust in storage provider
|
||
✔ Replay remains deterministic
|
||
|
||
This is **zero-knowledge storage federation**.
|
||
|
||
---
|
||
|
||
## 12. One-sentence takeaway
|
||
|
||
> **Public domains can safely store your encrypted blocks as opaque content, while all meaning, authority, and trust remain entirely within your personal domain.**
|
||
|
||
---
|
||
|
||
If you want next, we can:
|
||
|
||
* Specify **key derivation & rotation** compatible with snapshots
|
||
* Define **encrypted block GC safety**
|
||
* Model **multi-provider encrypted storage**
|
||
* Show **how to publish selectively decrypted subsets later**
|
||
|
||
This is a powerful capability — and you’re using it correctly.
|
||
|