Conversation

Notices

1. Embed this notice
   Dan Goodin (dangoodin@infosec.exchange)'s status on Thursday, 16-Jan-2025 04:28:47 JST Dan Goodin

   A fork of the Signal Messenger known as Sessions has omitted several important security properties found in the original source code, making it a less secure alternative, a researcher says. The deficiencies include:

   -- no forward secrecy

   • insufficient Entropy in Ed25519 Keys
   • no in-Band Negotiation for Message Signatures
   • using Public Keys as AES-GCM Keys

   Stay away from this offering unless you really, really, really know what you're doing:

   https://soatok.blog/2025/01/14/dont-use-session-signal-fork/

   • Embed this notice
     scriptjunkie (sj@social.scriptjunkie.us)'s status on Thursday, 16-Jan-2025 04:28:46 JST scriptjunkie

     in reply to

     @dangoodin That post totally misunderstands signature schemes and how they are used.
     https://social.scriptjunkie.us/@sj/113834017119054709

   • Embed this notice
     Robert Gützkow (robertguetzkow@infosec.exchange)'s status on Thursday, 16-Jan-2025 11:33:34 JST Robert Gützkow

     in reply to

     • scriptjunkie

     @sj @dangoodin the signature should be validated with a key that you know belongs to the legitimate sender. If you just use the public key that is contained within the very same message you are trying to validate then what is stopping an attacker from supplying a key of their choice?

   • Embed this notice
     scriptjunkie (sj@social.scriptjunkie.us)'s status on Thursday, 16-Jan-2025 11:33:34 JST scriptjunkie

     in reply to

     • Robert Gützkow

     @robertguetzkow @dangoodin I think you're assuming there's another "from" address in the message or connection context or something. There isn't. The public key *is* the identifier of the sender. There's no separate "from" address. The attacker can't put a different key into a message "from" Alice. It would no longer be a message from Alice. It would (accurately) be a message from the attacker.

   • Embed this notice
     scriptjunkie (sj@social.scriptjunkie.us)'s status on Thursday, 16-Jan-2025 12:04:26 JST scriptjunkie

     in reply to

     @dangoodin Oh and if the hop crypto is really broken the worst case thing that happens is that the network could see IPs of who sent and received messages through their nodes if they had entry/exit nodes. Quick! Everybody rush back to Signal... where the network sees the IP of who sent and received all messages and the *phone numbers* of who sent and received messages, which is far more sensitive, personal, and identifying.

     Just once what I would give for people to understand the log/speck principle.

   • Embed this notice
     scriptjunkie (sj@social.scriptjunkie.us)'s status on Thursday, 16-Jan-2025 22:17:28 JST scriptjunkie

     in reply to

     • Robert Gützkow

     @robertguetzkow @dangoodin sharing a public key out of band is literally how you start chatting with someone

   • Embed this notice
     Robert Gützkow (robertguetzkow@infosec.exchange)'s status on Thursday, 16-Jan-2025 22:17:29 JST Robert Gützkow

     in reply to

     • scriptjunkie

     @sj @dangoodin how would you know whether or not the public key belongs to Alice? Usually in protocols you would have a handshake at the beginning where you'd verify that the sender can sign a message properly. The public key of the sender would have to be known prior and out of band (think certificates like in TLS). Here they just place the public key in the message and use it for the signature verification. As far as I can see, there is nothing in the snippet ensuring that the public key belongs to the sender we are expecting to communicate with.