Ancestors

Written by Soatok Dreamseeker on 2025-01-15 at 04:24

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

Toot

Written by Soatok Dreamseeker on 2025-01-16 at 03:29

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

Descendants

Written by lizard appreciator on 2025-01-16 at 03:34

@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

Written by Soatok Dreamseeker on 2025-01-16 at 03:35

@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

Written by lizard appreciator on 2025-01-16 at 03:46

@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

Written by ⬡-49016 on 2025-01-16 at 03:56

@soatok trying to understand scriptjunkies point here, and (even though they make some very questionable claims like a signature automatically proving identity) don't they have a somewhat valid point?

as you mentioned:

Then, once you have a trusted public key, you use that to validate a signature on the message. Because you have a separate mechanism and process for figuring out which public key is correct, a valid signature is proof that the message is authentic.

and if it understood scriptjunkie's post correctly and the assumption below holds true, session does this, but just the other way around: it b) establishes that X's message was signed by X's public key (where X is unknown), and a) has already established OOB that A's public key belongs to A, and only if X's public key is A's public key X's message gets authenticated as A's message, which seems like they're doing the same two steps, but just in... reverse order?

like, that bit of code alone is definitely not enough, but this assumes that session does a separate check somewhere that only inserts messages in A's conversation if the OOB-established public key matches the one in the message packet (which has to have been confirmed to have a valid signature from the public key before), but if that assumption holds true, it'd be a very weird but still secure way to do it, or not?

there was zero evidence provided for that claim, so unless that is given this aspect shouldn't be trusted either, but it thinks there is an actually valid point in there

=> More informations about this toot | More toots from lexi@catcatnya.com

Written by Soatok Dreamseeker on 2025-01-16 at 04:07

@lexi If the recipient had the Ed25519 public key for the sender, OOB, they wouldn't need to embed it in plaintextWithMetadata.

In fact, it never does anything further to validate senderEd25519PublicKey.

You can check yourself: https://github.com/session-foundation/session-android/blob/75e2b87278cc378e21b77b27fa1a2aa773d25520/libsession/src/main/java/org/session/libsession/messaging/sending_receiving/MessageDecrypter.kt#L44-L56

Instead, it returns a Pair<plaintext, x25519publickey>.

This is then returned to the UI: https://github.com/session-foundation/session-android/blob/75e2b87278cc378e21b77b27fa1a2aa773d25520/libsession/src/main/java/org/session/libsession/messaging/sending_receiving/MessageReceiver.kt#L81-L88

More specifically, this public key is parsed out as sender in https://github.com/session-foundation/session-android/blob/75e2b87278cc378e21b77b27fa1a2aa773d25520/libsession/src/main/java/org/session/libsession/messaging/sending_receiving/MessageDecrypter.kt#L44-L56

And the only check in isValid() is that it's non-empty: https://github.com/session-foundation/session-android/blob/75e2b87278cc378e21b77b27fa1a2aa773d25520/libsession/src/main/java/org/session/libsession/messaging/messages/visible/VisibleMessage.kt#L32-L34 + https://github.com/session-foundation/session-android/blob/75e2b87278cc378e21b77b27fa1a2aa773d25520/libsession/src/main/java/org/session/libsession/messaging/messages/Message.kt#L46-L50 (via inheritance)

=> More informations about this toot | More toots from soatok@furry.engineer

Written by Soatok Dreamseeker on 2025-01-16 at 04:10

@lexi The burden is placed upon the UI, or on the user if the UI fails to catch it, rather than the signature algorithm itself.

It's not a reasonable protocol design, and it's not a sane way to build a security product.

=> More informations about this toot | More toots from soatok@furry.engineer

Written by Bill Ricker on 2025-01-16 at 04:32

@soatok 《extremely inefficient CRC32》🔥

=> More informations about this toot | More toots from BRicker@fosstodon.org

Written by tekhedd on 2025-01-16 at 07:04

@soatok But that's why we love you. You summarize very well, in a way that is easy to understand if you're willing to look up the parts you don't get, and neither patronizingly oversimplified or arrogantly ignoring the complexity.

"Using the public key to verify" I mean, reading it I had this growing sense of horror...the whole thing sounds like a beginner's exercise in "inserting holes for us to exploit later..."

=> More informations about this toot | More toots from tekhedd@byteheaven.net

Written by LightlySearedOnTheRealityGrill on 2025-01-16 at 15:58

@soatok I think a demo, say for an even smaller seed or a elliptic curve on a smaller prime field like GF(2**127-1) with a 64bit seed would go a long to quell doubts about your claim here.

Because, sad to say, I have problems imagining how the "modified version of Pollard’s rho" in your blog post is supposed to operate.

=> More informations about this toot | More toots from zeri@chaos.social

Written by Soatok Dreamseeker on 2025-01-16 at 16:01

@zeri I plan on that this weekend

=> More informations about this toot | More toots from soatok@furry.engineer

Written by Soatok Dreamseeker on 2025-01-16 at 16:21

@zeri I've added a note to the blog to make this question apparent to readers, and to publicly commit to writing a PoC: https://soatok.blog/2025/01/14/dont-use-session-signal-fork/#edit-2025-01-16

=> More informations about this toot | More toots from soatok@furry.engineer