[_]: chore/update internxt-crypto dependency to version 1.6.0 and adjust encryption#72
Conversation
📝 WalkthroughWalkthroughChangesMail encryption v3 migration
Estimated code review effort: 3 (Moderate) | ~25 minutes Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
ESLint install timed out. The project may have too many dependencies for the sandbox. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Deploying mail-web with
|
| Latest commit: |
b08cf35
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://d435fa8f.mail-web-ea0.pages.dev |
| Branch Preview URL: | https://feat-crypto-1-6.mail-web-ea0.pages.dev |
|
There was a problem hiding this comment.
Warning
CodeRabbit couldn't request changes on this pull request because it doesn't have sufficient GitHub permissions.
Please grant CodeRabbit Pull requests: Read and write permission and re-run the review.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/services/mail-encryption/index.ts`:
- Around line 105-115: Update decryptForCaller and the related decryption paths
to detect and support v2 envelope shapes in addition to v3, using a
version-specific fallback or equivalent migration path for existing stored mail.
Preserve current v3 behavior and add or retain a v2 regression fixture covering
decryption of legacy envelopes.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 2e3c677f-4a8f-404d-a393-34b3bf4c2dfd
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (7)
package.jsonsrc/components/compose-message/hooks/useComposeSend.test.tssrc/components/compose-message/hooks/useDraftMessage.test.tssrc/hooks/mail/useAttachmentsSessionKey.test.tsxsrc/services/mail-encryption/index.test.tssrc/services/mail-encryption/index.tssrc/services/sdk/mail/mail.service.test.ts
| private decryptForCaller(envelope: EncryptionBlock, keypair: HybridKeyPair, address: string) { | ||
| const wrapped = this.findKeyFor(envelope.wrappedKeys, address); | ||
| return decryptEmailHybrid( | ||
| { | ||
| encText: envelope.encryptedText, | ||
| encPreview: envelope.encryptedPreview, | ||
| encAttachmentsSessionKey: envelope.encryptedAttachmentsSessionKey, | ||
| }, | ||
| wrapped, | ||
| keypair.secretKey, | ||
| ); |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | 🏗️ Heavy lift
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '\n== AGENTS.md ==\n'
sed -n '1,240p' AGENTS.md
printf '\n== mail-encryption files ==\n'
git ls-files 'src/services/mail-encryption/*' 'src/services/mail-encryption/**/*' | sed -n '1,200p'
printf '\n== outline of src/services/mail-encryption/index.ts ==\n'
ast-grep outline src/services/mail-encryption/index.ts --view expanded
printf '\n== relevant search for v2/v3/mail encryption symbols ==\n'
rg -n "v2|v3|decryptEmailHybrid|encryptedAttachmentsSessionKey|preview-key|preview key|mail-encryption" src/services/mail-encryption src -g '!**/dist/**'Repository: internxt/mail-web
Length of output: 19495
🏁 Script executed:
#!/bin/bash
set -euo pipefail
sed -n '1,220p' src/services/mail-encryption/index.tsRepository: internxt/mail-web
Length of output: 8496
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf 'AGENTS exists: '; test -f AGENTS.md && echo yes || echo no
printf 'Index exists: '; test -f src/services/mail-encryption/index.ts && echo yes || echo no
wc -l AGENTS.md src/services/mail-encryption/index.tsRepository: internxt/mail-web
Length of output: 264
🌐 Web query:
"decryptEmailHybrid encAttachmentsSessionKey v2 v3 internxt crypto"
💡 Result:
Internxt utilizes advanced cryptographic methods to secure user data, including emails and file attachments [1][2]. The functions decryptEmailHybrid and related encryption methods are part of the internxt/crypto repository, which provides client-side, end-to-end encryption for Internxt's ecosystem [1]. Key aspects of their implementation include: 1. Hybrid Encryption: The codebase includes functions like encryptEmailHybrid and decryptEmailHybrid to manage secure email communication [1]. This hybrid approach typically involves using asymmetric cryptography for key exchange and symmetric encryption for the actual content [1]. 2. Post-Quantum Security: Internxt has implemented Kyber-512, a NIST-selected post-quantum encryption standard, to protect files and data against potential future quantum computing threats [2][3]. 3. File Encryption: File storage relies on deterministic key generation from user mnemonics, bucket IDs, and file indices, typically using AES-256-CTR for stream encryption [4][5]. 4. Versioning: Internxt uses versioning for various services, such as public sharing (e.g., inxt-v2 vs. inxt-v3) [6]. While specific terms like encAttachmentsSessionKey are common in secure messaging platforms (often associated with XChaCha20-Poly1305 in projects like Session [7]), Internxt's internal implementation focuses on its own proprietary crypto-services to ensure zero-knowledge privacy [2][3]. The v2 and v3 references in the Internxt ecosystem often correspond to protocol upgrades, such as improvements to sharing mechanisms or specific crypto-service iterations [6]. Developers should refer to the official internxt/crypto and associated drive-web repositories for the most current implementation details and library structures [1][4].
Citations:
- 1: https://github.com/internxt/crypto
- 2: https://help.internxt.com/en/articles/10522070-what-encryption-does-internxt-use
- 3: https://blog.internxt.com/post-quantum-cryptography/
- 4: https://deepwiki.com/internxt/drive-web/13.1-file-encryption-and-decryption
- 5: https://github.com/internxt/drive-web/blob/fd513f44/src/app/network/NetworkFacade.ts
- 6: [PB-6542] Add new sharings drive-web#1996
- 7: https://www.cclsolutionsgroup.com/post/examining-session-desktop-attachments
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '\n== v2 mentions in mail-encryption tests ==\n'
rg -n "v2|encryptedAttachmentsSessionKey|decryptEmailHybrid|preview" src/services/mail-encryption/index.test.ts
printf '\n== mail-encryption test file (relevant sections) ==\n'
sed -n '1,260p' src/services/mail-encryption/index.test.ts
printf '\n== repo-wide v2 encryption envelope mentions ==\n'
rg -n "version:\s*'v2'|version:\s*\"v2\"|encryptedAttachmentsSessionKey|decryptSummaryPreview|decryptEnvelope" src -g '!**/dist/**'Repository: internxt/mail-web
Length of output: 13777
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '\n== envelope type references ==\n'
rg -n "type EncryptionBlock|interface EncryptionBlock|EncryptionBlock" src . -g '!**/dist/**' -g '!**/node_modules/**'
printf '\n== mail service / sender-side version handling ==\n'
sed -n '300,380p' src/services/sdk/mail/mail.service.test.ts
sed -n '1,240p' src/services/sdk/mail/index.ts
printf '\n== any migration / legacy v2 logic ==\n'
rg -n "legacy|v2|v3|version" src/services src/hooks src/components -g '!**/dist/**'Repository: internxt/mail-web
Length of output: 30792
🌐 Web query:
"site:github.com internxt crypto email-crypto v2 v3 encryptEmailHybrid decryptEmailHybrid encAttachmentsSessionKey"
💡 Result:
The methods encryptEmailHybrid and decryptEmailHybrid are part of the internxt/crypto repository and are designed for end-to-end email encryption using hybrid cryptography [1]. Key findings from the Internxt codebase include: - Hybrid Email Cryptography: encryptEmailHybrid and decryptEmailHybrid allow for secure email processing by leveraging both ECC (Elliptic Curve Cryptography) and, in newer implementations, post-quantum algorithms like Kyber [1][2]. - Asymmetric Encryption Service: Internxt has integrated Kyber as a provider within their asymmetric encryption service to support hybrid encryption, as seen in their server-side and web-client repositories [2][3][4]. - encAttachmentsSessionKey: While not explicitly detailed as a standalone public function in the provided snippets, the codebase uses hybrid encryption patterns to handle keys and attachments [1][5]. In the context of Internxt's architecture, encrypted session keys are frequently managed alongside primary encryption keys (ECC/Kyber) to secure file or email attachments [6][5]. - Code Context: The internxt/crypto library provides the core logic for these hybrid operations [1]. In implementations such as drive-web, the system generates keys (both ECC and Kyber) and encrypts them using AES for secure storage or recovery [6][5]. These functions are used to ensure that email content is encrypted at the client side before being transmitted, preserving privacy by using the recipient's public keys for encryption and the sender's/recipient's private keys for the respective encryption/decryption workflows [1].
Citations:
- 1: https://github.com/internxt/crypto
- 2: internxt/drive-server-wip@5f70d15
- 3: internxt/drive-server-wip@6ad4ad2
- 4: internxt/drive-server-wip@c11dde4
- 5: https://github.com/internxt/drive-web/blob/090e120d/src/utils/backupKeyUtils.ts
- 6: https://github.com/internxt/drive-web/blob/fd513f44/src/app/crypto/services/keys.service.ts
Preserve v2 envelope support. These decrypt paths only handle the v3 envelope shape; add a versioned fallback or migrate existing stored mail before release, and keep a v2 regression fixture.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/services/mail-encryption/index.ts` around lines 105 - 115, Update
decryptForCaller and the related decryption paths to detect and support v2
envelope shapes in addition to v3, using a version-specific fallback or
equivalent migration path for existing stored mail. Preserve current v3 behavior
and add or retain a v2 regression fixture covering decryption of legacy
envelopes.



Update crypto to v1.6 and adjust accordingly