XSF Discussion - 2024-02-24

Daniel: for the read state sync, maybe we could reuse the stanza-id element. This way we also get the by attribute which is useful as a sanity check

"Our rekeying approach is modeled after ratcheting, a technique that consists of deriving a new session key from other keys and ensuring the cryptographic state always moves forward in one direction. PQ3 combines three ratchets to achieve post-quantum encryption." https://security.apple.com/blog/imessage-pq3/

> "Our rekeying approach is modeled after ratcheting, a technique that consists of deriving a new session key from other keys and ensuring the cryptographic state always moves forward in one direction. PQ3 combines three ratchets to achieve post-quantum encryption." > > https://security.apple.com/blog/imessage-pq3/ When is quantum proof encryption coming to XMPP? ↺

when you write a XEP

> when you write a XEP That's not a good plan ↺

When its coming to tls, it will automatically come to xmpp connections too I guess.

Meanwhile, pidgin had one time pad encryption like 2005

That's not only quantum save, its like the next best imagianble encryption besides not saying anything. 🙂

Also keep in mind proprietary encryption (so signal and WhatsApp and Apple and Google RCS etc etc etc) is entirely useless when they can just push any app updates whenever they want

TLS is entirely useless when an adversary can mitm your server and request a new cert from LE or such, and your host trusts this

So use channel binding and/or dane

> Also keep in mind proprietary encryption (so signal and WhatsApp and Apple and Google RCS etc etc etc) is entirely useless when they can just push any app updates whenever they want Is there an open source encryption protocol which is end 2 end, quantum proof and that doesn't compromise previous communications in case keys are stolen? ↺

AES?

> TLS is entirely useless when an adversary can mitm your server and request a new cert from LE or such, and your host trusts this All e2ee protocols are entirely useless if they can read on the end device, just saying... Nothing is 100% Time again for https://github.com/maqp/tfc ↺

topgun: https://github.com/maqp/tfc

Damn Menel beat me

The only remotely *secure* digital messaging solution 😉

>> TLS is entirely useless when an adversary can mitm your server and request a new cert from LE or such, and your host trusts this > All e2ee protocols are entirely useless if they can read on the end device, just saying... Nothing is 100% > Time again for https://github.com/maqp/tfc Google can now scan your screen..it uses that to give you Google maps tips. Os this working against this threat? Maybe . solution would be encryption ar the keyboard level, and you see what you tip on the keyboard,.and the keyboard is open source so you know it can't read what you see. But thinking well of that, If the other side s screen is being read automatically this is also useless ↺

Read the link first before speculating, it's quite funny and educating too ✏

(and off topic)

topgun: it actually is a working solution against that yes lol

The computers on both ends that can decrypt the messages can't access the internet so they are assumed to be compromised and it doesn't matter

> The computers on both ends that can decrypt the messages can't access the internet so they are assumed to be compromised and it doesn't matter If they can't access the internet how can they receive the messages? ↺

https://xmpp.org/extensions/xep-0174.html 😀

topgun: did you read it yet? They can only receive thanks to a one-way octocoupler