Skip to content

Commit 41d39f8

Browse files
ehsan6shaehsan6sha
committed
Update wnfs-comparison.md
1 parent c6f3052 commit 41d39f8

1 file changed

Lines changed: 91 additions & 0 deletions

File tree

‎docs/wnfs-comparison.md‎

Lines changed: 91 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -574,3 +574,94 @@ For your **encrypted IPFS pinning gateway**, I would recommend **keep Fula as th
574574
| **Performance – large / deep trees** | Single encrypted `PrivateForest` JSON per bucket; simple but may be heavy for millions of entries. | HAMT‑based `HamtForest`; scales well to very large private trees and sync scenarios. | For huge multi‑tenant trees, borrow HAMT ideas from **WNFS**; Fula is adequate for moderate scales. |
575575
| **Future‑proofing** | HPKE, BLAKE3, explicit versioning; easier migration to new suites and formats. | DSIs and traits help, but accumulators and RSA exchange keys are heavier to migrate. | **Fula** has a slight future‑proofing edge. |
576576
| **Overall security score (this audit)** | ~**9.0 / 10** – strong primitives and design; sharing and rotation now **fully integrated**. | ~**9.2 / 10** – very complete private filesystem model, especially for sharing and revisions. | For a **pinning gateway**, use **Fula** + selectively adopt WNFS design patterns. |
577+
578+
---
579+
580+
## 8. Central Authority Reliance for Encryption
581+
582+
This section focuses **only on encryption, decryption, and cryptographic features** — not on IPFS or pinning service availability. The question is: **which features break if a central authority (server, gateway, or trusted third party) is unavailable or compromised?**
583+
584+
### 8.1 Fula
585+
586+
| Feature | Central Authority Required? | Notes |
587+
| --- | --- | --- |
588+
| **Key generation** | ❌ No | `KeyManager::new()` generates keys locally using OS randomness. No server involved. |
589+
| **Content encryption** | ❌ No | AES‑GCM / ChaCha20‑Poly1305 encryption happens entirely on the client. |
590+
| **DEK wrapping (HPKE)** | ❌ No | HPKE wrapping uses local X25519 keys; no trusted third party needed. |
591+
| **Metadata encryption** | ❌ No | `PrivateMetadata` is encrypted locally with the per‑file DEK. |
592+
| **PrivateForest index** | ❌ No | The forest is encrypted locally and stored as a normal object; no special server logic. |
593+
| **Decryption (owner)** | ❌ No | Owner uses local `SecretKey` to HPKE‑unwrap DEK and decrypt content. |
594+
| **Sharing (create ShareToken)** | ❌ No | Sharer wraps DEK for recipient's public key locally; no server mediation. |
595+
| **Sharing (accept ShareToken)** | ❌ No | Recipient decrypts `ShareToken.wrapped_key` locally with own private key. |
596+
| **Share validation (expiry, scope, permissions)** | ⚠️ Partial | If enforced at gateway, relies on gateway; if enforced in client, no central authority. Current implementation enforces in `EncryptedClient` (client‑side). |
597+
| **Share revocation** | ⚠️ Partial | `FolderShareManager::revoke_share()` removes share from local state. If shares are distributed (e.g., via URL), revocation requires re‑keying the folder to truly prevent access. |
598+
| **Key rotation** | ❌ No | `KeyRotationManager` and `rotate_bucket()` operate locally; no trusted server. |
599+
| **Key escrow / recovery** | N/A | Not implemented. User is responsible for backing up `SecretKey`. |
600+
| **Trust assumptions** | Client device | Assumes the client device is not compromised. No trust required in storage provider or gateway for confidentiality. |
601+
602+
**Summary for Fula:**
603+
604+
- **All encryption, decryption, and key management are fully client‑side.** No central authority is required for core crypto operations.
605+
- Share revocation is **weak** without re‑keying: revoking a share from `FolderShareManager` only affects local state. A recipient who already has the `ShareToken` can continue to decrypt unless the folder's DEK is rotated.
606+
- The gateway is only a transport layer for encrypted blobs; it never sees plaintext keys or data.
607+
608+
---
609+
610+
### 8.2 WNFS
611+
612+
| Feature | Central Authority Required? | Notes |
613+
| --- | --- | --- |
614+
| **Key generation** | ❌ No | Keys are generated locally (per‑node ratchets, `TemporalKey`, `SnapshotKey`). |
615+
| **Content encryption** | ❌ No | XChaCha20‑Poly1305 encryption is client‑side. |
616+
| **Key wrapping (AES‑KWP)** | ❌ No | AES key wrap uses local `TemporalKey`; no server involved. |
617+
| **Name accumulator** | ⚠️ Setup | The `AccumulatorSetup` (RSA modulus) must be generated once, ideally via trusted setup or MPC. After setup, no central authority is needed for accumulation. |
618+
| **HamtForest storage** | ❌ No | HAMT nodes are stored as CIDs in a content‑addressed blockstore; no server logic. |
619+
| **Decryption (owner)** | ❌ No | Owner derives keys from ratchet state and decrypts locally. |
620+
| **Sharing (sharer side)** | ❌ No | Sharer encrypts `AccessKey` with recipient's RSA public key locally and stores in own private forest. |
621+
| **Sharing (recipient side)** | ❌ No | Recipient scans sharer's forest for share labels and decrypts with own RSA private key locally. |
622+
| **Share revocation** | ⚠️ Weak | Similar to Fula: once an `AccessKey` is shared, the recipient can access the data. Revocation requires re‑keying (ratchet advancement) and re‑encrypting affected nodes. |
623+
| **Exchange key discovery** | ⚠️ Public directory | Recipients' RSA public keys are stored in public exchange directories. These directories must be accessible, but are not a trusted authority — they are content‑addressed. |
624+
| **Key rotation (ratchet)** | ❌ No | Ratchet advancement is local; no server involvement. |
625+
| **Trust assumptions** | Client device + initial accumulator setup | Assumes client device is not compromised. Accumulator setup requires a one‑time trusted process. |
626+
627+
**Summary for WNFS:**
628+
629+
- **All encryption, decryption, and key management are fully client‑side.** No ongoing central authority is required.
630+
- **Accumulator setup** is a one‑time trust requirement: the RSA modulus must be generated securely (e.g., via MPC or trusted party). After setup, the system is decentralized.
631+
- **Exchange key discovery** uses public directories (content‑addressed), not a trusted server.
632+
- Share revocation is **weak** without ratchet advancement: once an `AccessKey` is shared, revocation requires re‑keying.
633+
634+
---
635+
636+
### 8.3 Comparison Table
637+
638+
| Aspect | Fula | WNFS | Notes |
639+
| --- | --- | --- | --- |
640+
| **Key generation** | Fully local | Fully local | Both use local randomness. |
641+
| **Encryption / decryption** | Fully local | Fully local | No server sees plaintext. |
642+
| **Key wrapping** | HPKE (local) | AES‑KWP (local) | Both client‑side. |
643+
| **Sharing (create)** | HPKE for recipient (local) | RSA OAEP for recipient (local) | Both client‑side. |
644+
| **Sharing (accept)** | Recipient decrypts locally | Recipient decrypts locally | No server mediation. |
645+
| **Share revocation** | Weak (re‑key folder DEK) | Weak (ratchet advancement) | Both require re‑keying to truly revoke. |
646+
| **Key rotation** | `rotate_bucket()` (local) | Ratchet advancement (local) | Both client‑side. |
647+
| **Trust setup** | None | One‑time accumulator setup | WNFS requires trusted RSA modulus generation. |
648+
| **Exchange key discovery** | Out of scope (bring your own) | Public directories (content‑addressed) | WNFS has a specified mechanism. |
649+
| **Features that break without authority** | None (for encryption) | None (for encryption, post‑setup) | Both are fully decentralized for core crypto. |
650+
651+
---
652+
653+
### 8.4 Verdict on Central Authority Reliance
654+
655+
**Both Fula and WNFS are designed for decentralized, client‑side encryption with no ongoing reliance on a central authority for core cryptographic operations.**
656+
657+
Key differences:
658+
659+
- **WNFS** requires a **one‑time trusted accumulator setup** (RSA modulus generation). After that, all operations are decentralized.
660+
- **Fula** has **no trusted setup requirement** — keys are generated locally with no special ceremony.
661+
- Both systems have **weak revocation semantics**: once a share is granted, true revocation requires re‑keying the shared data. This is inherent to capability‑based systems.
662+
- **Exchange key discovery** is explicitly specified in WNFS (via public directories); Fula leaves this to the integrator.
663+
664+
For an IPFS pinning gateway use case:
665+
666+
- **Fula's simpler model** (no trusted setup, HPKE for sharing) is easier to deploy in a decentralized manner.
667+
- If asynchronous offline sharing with public exchange directories is needed, **borrow the WNFS model** for discovery while keeping Fula's HPKE wrapping for the actual key exchange.

0 commit comments

Comments
 (0)