{
"$type": "site.standard.document",
"bskyPostRef": {
"cid": "bafyreiafu3iayac5qyrou6zbhfbcdau5f57gdg3bjxgbo4q7m2etmjpnma",
"uri": "at://did:plc:haakkg7y3xdghcdmprxeexso/app.bsky.feed.post/3mf4ynhfxxpq2"
},
"path": "/t/aliasvault-open-source-e2ee-password-email-alias-manager/24436?page=9#post_177",
"publishedAt": "2026-02-18T10:00:36.000Z",
"site": "https://discuss.privacyguides.net",
"tags": [
"https://www.aliasvault.net/responsible-disclosure"
],
"textContent": "Thank you for sharing! Yes I also got a similar question on AliasVault’s subreddit regarding this published research. I commented on this yesterday, sharing it here as well for context:\n\n> We did review the ETH Zurich paper (which was published yesterday, 16th of February). AliasVault was not part of that research, however we did compare the findings against AliasVault’s architecture. One specific issue they found: “field swapping / ciphertext substitution” fortunately does not apply the same way to AliasVault.\n>\n> In contrast to many other password managers, AliasVault stores the entire vault as a single encrypted blob, not as separately encrypted per-field entries. That means the server can’t swap URL/password fields or tamper with individual parts without breaking integrity checks, making the client reject it.\n>\n> That said, we do take all security publications seriously. We actively review each one to see whether anything is applicable and apply hardening where needed. In fact, the latest AliasVault release 0.26.4 (released yesterday) already includes security improvements to the mobile login flow (public key verification) which was specifically mentioned by this research.\n>\n> As security is an ongoing process, questions like this are always welcome. Also if anyone believes they’ve found a potential issue with how AliasVault works or is designed, we also have a responsible disclosure process in place:\n> https://www.aliasvault.net/responsible-disclosure",
"title": "AliasVault: Open-Source E2EE Password & (Email) Alias Manager"
}