Show HN: Closing the public-key authenticity gap in our E2EE social network (mosslet.com)

3 points|by mosspigletdev|2d ago|2 comments|Read full story on mosslet.com

I’ve been building a privacy-first social network for some time now, as a healthier alternative to Big Social, and it has at times felt like a Sisyphean task. The latest gap I’ve been confronting is key authenticity, and while it hasn’t been an actual security issue we have effectively closed it. Cheers.

Comments (2)

2 shown

1. jimmiew|1d ago|context

Cool. The key-change part feels especially important. Also agree with that “tamper-evident, signed history of keys” — it makes key changes safer, more visible, and easier to reason about.
The other key challenge is recovery. Users will lose devices and keys, so multi-key design is necessary, but it has to be done without quietly reintroducing server trust.
2. mosspigletdev|19h ago|context

I think I understand what you’re referring to and agree that key recovery is a challenge, especially for a zk system.
Mosslet sidesteps that by deriving your key from your password rather than per-device, so if you lose your device you don’t lose your key. And then you do have the ability to generate a recovery code that is also ZK and you can use that code to get back into your account if you lose your password. However, if you lose your password and your recovery code (or never generated one), then the tradeoff is losing access to your account.
Regarding the key transparency work, if you lose your device that you verified with you don’t lose that verification either. It flows like this:
When you first verify a friend, your browser computes their fingerprint and seals it with a key derived from your password. The server stores that encrypted blob. Sign in on any device and your browser re-derives the key from your password (Argon2id, in-browser), unseals the pin locally, and re-checks it against the key in use. So losing your device never makes you re-verify your friends from scratch.