Don’t Use Session (Signal Fork)
Last year, I outlined the specific requirements that an app needs to have in order for me to consider it a Signal competitor. Afterwards, I had several people ask me what I think of a Signal fork called Session. My answer then is the same thing I'll say today: Don't use Session. The main reason I said to avoid Session, all those months ago, was simply due to…
http://soatok.blog/2025/01/14/dont-use-session-signal-fork/
=> More informations about this toot | More toots from soatok@furry.engineer
I amended the post to add a section here in response to a Twitter blue user, scriptjunkie, who thought I didn't understand how asymmetric cryptography works.
Comparing their usage of Ed25519 to an extremely inefficient CRC32 is the only way to adequately describe how YOLO their protocol design is.
=> More informations about this toot | More toots from soatok@furry.engineer
@soatok "If an attacker can arbitrarily substitute public keys in chosen plaintexts, the Ed25519 signature doesn’t really prove anything beyond “this wasn’t tampered with in-transit”."
isn't this not even proving that it wasn't tampered with, just that it wasn't non-maliciously corrupted?
=> More informations about this toot | More toots from bonzoesc@m.bonzoesc.net
@bonzoesc Yeah it's weaker than HMAC because you can just swap the public key with whatever one you want, and then you can generate an Ed25519 signature for which that payload is valid (under the public key you chose, assuming you chose one where you know the secret key).
=> More informations about this toot | More toots from soatok@furry.engineer
@soatok yeah, basically just validating that whatever tampered with your message didn’t know what they were doing
=> More informations about this toot | More toots from bonzoesc@m.bonzoesc.net
text/geminiThis content has been proxied by September (3851b).