Attached: 1 image
The "Don't Use Session (Signal Fork)" post shows a tragic lack of understanding of basic cryptographic primitives and Session's protocol. The post claims the signature validation code of a message "reduced the utility of Ed25519 to that of a CRC32". But immediately following the quoted blob, you'll see that the message sender public key that validated the message is used to identify the sender.
If you try to "forge" a message with your own key, it won't show up as from someone else or in their conversations, it will show up as from you! That's the literal basic use case of a signature. It proves who it came from. While a CRC32 could be calculated for any message, even with a forged sender. This shows the post completely misses the point of asymmetric cryptography signature schemes.
The post may be correct with the AES encryption to public keys, however, so I'd still regard both Session and the post with suspicion until a more thorough analysis can be done.
https://github.com/session-foundation/session-android/blob/75e2b87278cc378e21b77b27fa1a2aa773d25520/libsession/src/main/java/org/session/libsession/messaging/sending_receiving/MessageDecrypter.kt#L58-L62
scriptjunkie
All GNU social JP content and data are available under the