Fix incorrect crypto and key details in documentation - #125
Merged
Conversation
paskal
force-pushed
the
fix-doc-accuracy
branch
from
August 20, 2026 07:33
e79c345 to
e17a43a
Compare
Previously, README described server-side encryption as AES-256-GCM and PIN hashing as bcrypt cost 14, while `app/messager/crypt.go` uses NaCl secretbox (XSalsa20-Poly1305) and `app/messager/messager.go` calls bcrypt with `bcrypt.DefaultCost`, which is 10. It also claimed 32-byte random key generation, where the browser generates a 128-bit key in `crypto.js` and `store.GenerateID` produces a 12-character base62 id, and said the server rejects unencrypted content from web clients, where `validator.IsBase64URL` only checks the alphabet and a minimum length consistent with an IV plus tag. The API examples still showed UUID keys. CLAUDE.md described storage keys as UUIDs and the IP anonymisation hash as 12-char HMAC-SHA1, while `app/store/store.go` generates 12-character base62 IDs and `app/server/middleware.go` truncates an HMAC-SHA256 to 8 hex chars. Its data flow also described encryption and decryption as always happening in MessageProc, which holds for the API path only: `ClientEnc` messages are stored as received and handed back as ciphertext, and the browser decrypts them after the server has already deleted the record. The `MakeSignKey` comment still referred to AES256 as well.
paskal
force-pushed
the
fix-doc-accuracy
branch
from
August 20, 2026 07:47
e17a43a to
d3c6c65
Compare
umputun
approved these changes
Aug 20, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Documentation in README.md and CLAUDE.md describes several security properties that do not match the implementation.
app/messager/crypt.gouses NaCl secretbox, XSalsa20-Poly1305; the file itself says so at line 15.app/messager/messager.go:236callsbcrypt.GenerateFromPasswordwithbcrypt.DefaultCost, which is 10.crypto.js,generateKey) andstore.GenerateIDproduces a 12-character base62 id; nothing generates a 32-byte random key.validator.IsBase64URLchecks the base64url alphabet and a minimum length consistent with an IV plus tag, so it validates the shape of a ciphertext envelope rather than establishing that the content is encrypted.app/store/store.go:29generates a 12-character base62 id.app/server/middleware.go:84-88uses HMAC-SHA256 truncated to 8 hex characters.MessageProcencrypts every message. That holds for the API path only, sinceClientEncmessages are stored exactly as the browser sent them (app/messager/messager.go:140-141).The
MakeSignKeycomment still referred to AES256 as well.Documentation only, no behaviour change.
The e2e job fails on this branch for a reason unrelated to it: the playwright driver can no longer be installed, which has been breaking every run since 1 July. #126 fixes that, and its e2e run is green.