Open Source Components
MyPwdTool isn't fully open source — but the parts that matter most for trust, the sync protocol and the encryption itself, are published under the MIT license for independent review.
Why not the whole app?
Publishing the entire application as open source would make it trivial to take the compiled app, strip out the parts that make sync sustainable to run (see Subscription & Pricing), and redistribute copies that never contribute anything toward keeping the relay online. The rest of the app — the UI, the browser extensions, the AutoFill integration — stays proprietary for that reason.
Why open the sync and encryption code specifically?
Because that’s exactly the part you have to trust without being able to see it otherwise. The whole point of MyPwdTool’s design is that the relay server, and MyPwdTool as a company, can never read your data — see Security & Encryption and Synchronization for the full explanation. That’s a strong claim, and strong claims about encryption shouldn’t have to be taken on faith. Publishing the actual key derivation, per-field encryption, sync-envelope encryption, and relay-protocol client code — for both the Swift (macOS/iOS) and Kotlin (Windows) implementations — under the MIT license means anyone can read exactly what these apps do with your master password and your data, line by line, without needing to trust a marketing page.
The relay itself is open source too
The client-side files below aren’t the whole story — the relay server they talk to, e2eerelay, has been fully open source from the start, not just partially. It’s the small Go server that stores and forwards the encrypted sync messages between your devices, and its entire codebase — not a curated subset — is public at github.com/ThibaultDucray/e2eerelay. Between the relay’s full source and the client-side crypto/sync code published here, the complete path your data takes — encrypted on your device, moved by the relay, decrypted on your other device — is open for review end to end, even though the surrounding apps themselves aren’t.
What’s covered
Each file below is licensed under MIT — see the LICENSE-SYNC-CRYPTO.md alongside them for the
exact terms. Everything else in either app remains proprietary and is not published. The
links below serve the real, current source files directly from this site’s build — they’re not
copies that can silently drift out of date.
Swift (macOS / iOS)
- LICENSE-SYNC-CRYPTO.md
- CryptoManager.swift — key derivation (PBKDF2), DEK wrapping, per-field AES-256-GCM encryption
- SyncManager.swift — the sync engine: pairing, polling, applying inbound changes, device revocation, key rotation
- SyncModels.swift — the wire format
- SyncCrypto.swift — the sync message envelope encryption (Sync Group Key / AES-256-GCM)
- SyncStore.swift — local sync configuration storage
- SyncOutbox.swift — the durable outbound message queue
- RelayAPIClient.swift — the HTTP client for the relay’s API
Kotlin (Windows / Linux)
- LICENSE-SYNC-CRYPTO.md
- CryptoManager.kt
- SyncManager.kt
- SyncModels.kt
- SyncCrypto.kt
- SyncStore.kt
- SyncOutbox.kt
- RelayAPIClient.kt
- RelayError.kt
- RelayModels.kt
- Base64Url.kt
- ChallengeResponse.kt
Both implementations are cross-verified against each other byte-for-byte on their wire format and cryptographic output, so a macOS device and a Windows device sharing a sync group are provably speaking the exact same protocol — not just “compatible in practice.”