π Description
internal/cryptox/aesgcm.go (83 lines) implements AES-GCM encryption presumably used for encrypting sensitive stored fields (e.g. tokens). AES-GCM security depends entirely on never reusing a nonce with the same key β there's currently no test asserting nonces are generated with sufficient randomness/uniqueness, and no known-answer test vectors.
π§© Requirements and context
- Add a test asserting nonces are generated via a CSPRNG and are unique across many encryptions (statistical uniqueness check, not full formal proof).
- Add known-answer test vectors (encrypt/decrypt roundtrip with a fixed key/nonce/plaintext) to catch any accidental algorithm change.
- Add a doc comment on the encrypt function stating the nonce-reuse hazard explicitly.
Non-functional requirements
- Must be secure, tested, and documented.
- Should be efficient and easy to review.
π οΈ Suggested execution
1. Fork the repo and create a branch
git checkout -b test/aesgcm-nonce-reuse-protection
2. Implement changes
- Modify: create/extend
internal/cryptox/aesgcm_test.go with KAT vectors and a nonce-uniqueness test.
- Modify:
internal/cryptox/aesgcm.go β add the doc comment; fix only if a real reuse risk is found (e.g. a counter that can wrap).
3. Test and commit
go test ./internal/cryptox/... -v
- Cover edge cases: ciphertext tampering is rejected, wrong key on decrypt fails cleanly, empty plaintext roundtrips correctly.
- Include test output and details in the PR description.
Example commit message
test: add nonce-uniqueness checks and KAT vectors for AES-GCM helper
β
Acceptance criteria
π Security notes
This is the encryption primitive likely protecting stored OAuth/GitHub tokens (internal/github/token_store.go). A nonce-reuse bug would be a full confidentiality break for whatever it encrypts β treat any finding here as high severity.
π Guidelines
- Minimum 95% test coverage
- Clear documentation
- Timeframe: 96 hours
π Description
internal/cryptox/aesgcm.go(83 lines) implements AES-GCM encryption presumably used for encrypting sensitive stored fields (e.g. tokens). AES-GCM security depends entirely on never reusing a nonce with the same key β there's currently no test asserting nonces are generated with sufficient randomness/uniqueness, and no known-answer test vectors.π§© Requirements and context
Non-functional requirements
π οΈ Suggested execution
1. Fork the repo and create a branch
2. Implement changes
internal/cryptox/aesgcm_test.gowith KAT vectors and a nonce-uniqueness test.internal/cryptox/aesgcm.goβ add the doc comment; fix only if a real reuse risk is found (e.g. a counter that can wrap).3. Test and commit
go test ./internal/cryptox/... -vExample commit message
β Acceptance criteria
π Security notes
This is the encryption primitive likely protecting stored OAuth/GitHub tokens (
internal/github/token_store.go). A nonce-reuse bug would be a full confidentiality break for whatever it encrypts β treat any finding here as high severity.π Guidelines