Soatok
@Soatok@pawb.social
- Submitted 2 days ago to technology@lemmy.world | 0 comments
- Comment on The Revolution Will Not Make the Hacker News Front Page 3 weeks ago:
No, that’s like 20% of the blog post. This was a “2025 Retrospective” blog post. I always try to give a fun title to my end-of-year blogs. 2024’s was soatok.blog/…/the-better-daemons-of-our-professio…
- Comment on The Revolution Will Not Make the Hacker News Front Page 3 weeks ago:
You’re thinking of the wrong admin lol
- Comment on The Revolution Will Not Make the Hacker News Front Page 3 weeks ago:
Until the mods randomly decide to censor you, like they did with my post about tech companies disrespecting user consent.
- Comment on The Revolution Will Not Make the Hacker News Front Page 3 weeks ago:
Oh, fair. I just remember getting a LOT of notifications from both apps. I didn’t check the exact ratio,
- Comment on Announcing Key Transparency for the Fediverse - Dhole Moments 3 weeks ago:
why it this separate mechanism needed in the first place?
Because ActivityPub was not designed for E2EE. That’s the simplest answer.
The longer, and more technical answer, is that doing the actual “Encryption” part of E2EE is relatively easy. Key management is much harder.
I initially set out to just do E2EE in 2022, but got roadblocked by the more difficult problem of “which public key does the client trust?”.
- Comment on Announcing Key Transparency for the Fediverse - Dhole Moments 3 weeks ago:
It’s a building block to make E2EE possible at Fediverse scale.
I’ve written about this topic pretty extensively: soatok.blog/category/…/fediverse-e2ee-project/
If you can build in Federated Key Transparency, it’s much easier to reason about “how do I know this public key actually belongs to my friend?” which in turn makes it much easier to get people onboarded with E2EE without major risks.
- Submitted 3 weeks ago to technology@lemmy.world | 9 comments
- Submitted 1 month ago to technology@lemmy.world | 0 comments
- Comment on Don’t Use Session (Signal Fork) 11 months ago:
TL;DR from oss-security:
At a glance, what I found is the following:
- Session only uses 128 bits of entropy for Ed25519 keys. This means their ECDLP is at most 64 bits, which is pretty reasonably in the realm of possibility for nation state attackers to exploit.
- Session has an Ed25519 verification algorithm that verifies a signature for a message against a public key provided by the message. This is amateur hour.
- Session uses an X25519 public key as the symmetric key for AES-GCM as part of their encryption for onion routing.
Additional gripes about their source code were also included in the blog post.