Modern XMPP project discussion - 2023-01-03

Signal: 13952 92273 88486 28046 79070 67845 60766 65767 01577 24634 37214 07834 Looks the same as omemo for me... Matrix emoji verification?

hash commitments for DH, as described in RTC 6189 § 4.4.1.1 could be used instead, allowing for sufficiently secure very short codes. Telegram uses that during calls (displaying 3 emojis to be compared) and I think Matrix emoji verification is based on the same design. Translating the hash commitment into a small number of emojis from a preselected set of emojis that translate into single well-known words (so you can also have a text-only representation) sounds like a good option and I wanted to spec that out (in a generic way that would work for OMEMO but also for any other verification in the future). The important part about hash commitments for DH is that they have to be performed for a pair of users/devices: you'll have a different set of emojis for each contact. ✏

hash commitments for DH, as described in RTC 6189 § 4.4.1.1 could be used instead, allowing for sufficiently secure very short codes. Telegram uses that during calls (displaying 3 emojis to be compared) and I think Matrix emoji verification is based on the same design. Translating the hash commitment into a small number of emojis from a preselected set of emojis that translate into single well-known words (so you can also have a text-only representation) sounds like a good option and I wanted to spec that out (in a generic way that would work for OMEMO but also for any other verification in the future). The important part about hash commitments for DH is that they have to be performed for a pair of users/devices: you'll have a different set of emojis for each contact/verification attempt. ✏

larm, how is this different to something like, hash(sorted_fingerprints...)->[emoji/numeric code]

an attacker that knows how you are hashing can just generate private keys until the hash matches the correct one, so you'd need a very long emoji sequence for this to be secure.

Ah, right

the hash commitment variant doesn't have that issue, even with just 2 bytes of emoji randomness, the attacker would be detected in 99.998% of attempts

I like the ease of use of Signal's safety numbers. The emoji stuff is "clever", but also a bit "weird" to people.

A 6 digit code that changes when either party adds/removes a device seems very simple to explain

6 digits is also totally fine with the hash commitment approach

and is this something we could XEP?

2 bytes is 5 digits 😉

I guess, I haven't thought about the details in full yet. It's a DH scheme, so it's interactive by definition. Makes it very easy for use with calls (because interactive is easy when both sides are directly connected), but is harder in the async case

Oh, yeah, I guess I misremembered Signal. I thought they had a short code, but no

https://www.signal.org/blog/safety-number-updates/ (screenshot: https://www.signal.org/blog/images/verify-before-after.png )