Encryption key handling broken in sell() workflow

[tfius]

Summary

The sell() function in packages/skill/src/skill.ts has critical issues with encryption key handling that make the escrow workflow non-functional.

Problems

1. Encryption key not stored after generation

At line 149, a random encryption key is generated:

const encryptionKey = ethers.randomBytes(32);

But at lines 197-198, there's a TODO:

// TODO: Store encryption key securely for later release
// In production, use escrow keystore (encrypted, crash-recovery safe)

Impact: After sell() returns, the encryption key is lost. The seller cannot reveal it to the buyer after escrow is funded.

2. Swarm-native encryption key embedded in reference

The uploadToSwarm() method (lines 366-392) uses Swarm-native encryption when encrypt: true:

if (encrypt) {
  headers['Swarm-Encrypt'] = 'true';
}

With Swarm-native encryption, the returned reference format is:

reference = content_hash + encryption_key (64 bytes + 32 bytes)

Impact: Anyone with the full swarmRef can decrypt the data immediately. There's no way to withhold the key for the escrow reveal phase.

3. Key mismatch in sell() workflow

sell() generates TWO different keys:

1. encryptionKey at line 149 (never used for actual encryption)
2. Swarm-native key embedded in reference at line 153

The keyCommitment at line 169 is computed from the first key:

const keyCommitment = ethers.keccak256(encryptionKey);

But this key has nothing to do with the Swarm-encrypted data!

Impact: Even if the seller reveals the committed key, it cannot decrypt the Swarm-encrypted data.

Expected Behavior

The escrow workflow should be:

1. Seller encrypts data with key K (application-level encryption, NOT Swarm-native)
2. Seller uploads encrypted blob to Swarm (without Swarm-Encrypt header)
3. Seller creates escrow with keyCommitment = hash(K)
4. Buyer funds escrow
5. Seller reveals K on-chain
6. Buyer downloads blob and decrypts with K

Suggested Fix

Option A: Don't use Swarm-native encryption for escrow

• Encrypt data with encryptionKey before upload
• Upload without Swarm-Encrypt: true
• Store encryptionKey securely for later reveal

Option B: Split Swarm reference

• Upload with Swarm-Encrypt: true
• Split reference into content_hash (share) and key (reveal later)
• Use the embedded key as the escrow key

Files Affected

• packages/skill/src/skill.ts - sell() and uploadToSwarm() methods

Related

• The CLI (sx escrows create) has a similar issue - it generates a random key unrelated to actual data encryption

[tfius]

Solution Implemented in ade CLI

The ade CLI (https://github.com/datafund/ade) implements Option A from this issue and is fully functional.

How ade sell works:

ade sell --file ./data.csv --price 0.1 --yes

1. Local encryption - Encrypts file with AES-256-GCM (not Swarm-native)
2. Content hash - keccak256(encryptedData) stored on-chain
3. Key commitment - keccak256(key || salt) for commit-reveal scheme
4. Upload to Swarm - Plain POST /bytes without Swarm-Encrypt header
5. Store keys - Encryption key, salt, swarmRef saved to OS keychain:
   • ESCROW_<id>_KEY
   • ESCROW_<id>_SALT
   • ESCROW_<id>_SWARM

Key reveal with ECDH (bonus feature):

# Seller reveals key encrypted for specific buyer
ade escrows reveal-key 42 --buyer-pubkey 0x02abc... --yes

The revealed key can be ECDH-encrypted so only the buyer can decrypt it (not visible on-chain to others).

Buyer flow:

ade buy 42 --yes

1. Funds escrow
2. Waits for key reveal (polls chain)
3. Downloads from Swarm
4. Verifies content hash
5. Decrypts (supports both raw key and ECDH-encrypted key)

Relevant code:

• Encryption: src/crypto/escrow.ts
• Swarm upload: src/swarm.ts (no Swarm-Encrypt header)
• Sell flow: src/commands.ts - sell()
• Key storage: src/escrow-keys.ts
• ECDH: src/crypto/fairdrop.ts

This can serve as a reference implementation for fixing the skill.ts workflow.