Feature: Add cryptographic signatures to chat messages #18

Activity

1. melvincarvalho commented on Jan 11, 2026

   

   melvincarvalho

   on Jan 11, 2026

   ContributorAuthor

   More actions

   Analysis of SolidOS Chat Signature System

   Strengths ✅

   1. Simplicity

   • Clean integration - just one extra triple (sec:proofValue)
   • Reuses existing message fields for signing (no duplication)
   • Minimal dependencies (@noble/curves is well-audited)

   2. Standard-ish Approach

   • Uses https://w3id.org/security# vocabulary
   • Schnorr on secp256k1 aligns with Bitcoin/Nostr ecosystem
   • JSON serialization is predictable

   3. Backwards Compatible

   • Unsigned messages still work (just get red background)
   • Gradual adoption possible

   ---

   Weaknesses ⚠️

   1. Signing Object is Fragile

   msg = { id, created, content, maker }

   • What if fields are added later? Signature breaks
   • No versioning or canonicalization
   • Order-dependent JSON serialization could cause issues across implementations

   2. Private Key Storage is Problematic

   <#me> solid:privateKey "HEX_KEY" .

   • Stored as plaintext literal in pod
   • Pod server admin can read it
   • If ACL wrong, key leaks publicly
   • No encryption at rest
   • No hardware key support

   3. No Key Binding to WebID

   • Public key stored separately from WebID profile
   • No cryptographic proof that key belongs to that WebID
   • Someone could claim any public key

   4. Verification is Fire-and-Forget

   getPublicKey(creator).then(publicKey => {
     if (!verifySignature(...)) debug.warn('invalid signature')
   })

   • Only logs warning, doesn't update UI for invalid signatures
   • No distinction between "unsigned" vs "invalid signature" (both could be attacks)
   • Async verification means UI might render before verification completes

   5. No Replay/Timestamp Protection

   • Same message content + timestamp = same signature
   • No nonce or sequence number
   • Could potentially replay old messages

   6. Red Background UX

   • Punishes users who haven't set up keys
   • New users see all their messages in red
   • Doesn't distinguish "no key setup" from "tampered message"

   ---

   Security Concerns 🔒

   Issue	Risk	Impact
   Plaintext private keys	High	Full impersonation if pod compromised
   No key rotation protocol	Medium	Can't recover from key compromise
   Mutable message fields	Medium	Edit message → signature invalid → looks tampered
   No revocation	Medium	Can't invalidate compromised keys
   JSON serialization order	Low	Cross-implementation incompatibility

   ---

   Recommendations for solid-chat/app

   1. Improve Signing Object

   // Add version and sort keys for consistency
   const msg = {
     v: 1,  // Version for future changes
     content,
     created,
     id,
     maker
   }
   const canonical = JSON.stringify(msg, Object.keys(msg).sort())

   2. Better UI States

   🔒 Verified (green) - signature valid
   ⚠️ Unsigned (grey) - no signature present  
   ❌ Invalid (red) - signature failed verification
   🔑 No key (blue) - author has no public key
   

   3. Consider Podkey Integration First

   • Don't store private keys in pod
   • Use browser extension for signing
   • Pod only stores public key

   4. Add Key Binding

   # In WebID profile, cryptographically bind key
   <#me> sec:assertionMethod <#key1> .
   <#key1> a sec:JsonWebKey2020 ;
       sec:controller <#me> ;
       sec:publicKeyHex "..." .

   5. Handle Edited Messages

   • Re-sign on edit, or
   • Store original signature + edit history, or
   • Mark edited messages differently

   ---

   Overall Rating: 6/10

   Good MVP approach, gets the job done, but has security gaps that matter for a decentralized system where you can't trust the server. The Podkey extension approach is the right direction for production use.