“why signal instead of matrix”

their cryptographic protocol has some truly baffling decisions that they never go ahead and justify.

My personal favorite is the part where they have an authenticated encryption scheme that encrypts with a commonly broken mode of AES, and authenticated with a heavily truncated MAC and signed with ed25519

The MAC doesn’t provide any security benefits because it has been truncated so much

easy pick over whatever the fuck telegram is doing but ffs it’s not a signal replacement

if telegram is leaving exposed wires around your house, matrix is like not having GFCI or ground

@charlotte@akko.chir.rs i've been using xmpp with omemo for chats and video/audio calls (conversations app on android, and movim web client for desktop) i've been very impressed, honestly the a/v stuff is better on that than signal; making an international call with them is just a bad idea in most cases.

checked out omemo and they are doing almost the same thing, except instead of signing they are truncating the mac to the lowest amount the spec allows why is it truncating it at all.

why do they keep forgetting to include rationale on cryptographic decisions

I want to know why you thought truncating the mac was a good idea

okay so the reason they use AES-CBC is because of signal

I also know where the 16 and 8 byte numbers come from

The signal spec does say that it is “acceptable” to truncate the MAC to 128 bits to reduce message size. and that with “careful analysis” MAC truncations up to 64 bits could in theory be acceptable

Of course the “message size reduction” argument is bogus. Both omemo and matrix bloat the encrypted data by 33%, blowing any argument of space savings squarely out of the water.

@charlotte why don't they, idk, compress pre-encryption or something normal like that #krokodili

god we made the mistake of looking at xmpp

what the fuck is the version of omemo used by a popular client

gist is: that client uses a version of the OMEMO spec that is like 4 years out of date, and is missing an entire fucking rewrite

I would also like to point at the construction omemo version 0.3.0 is using. And the implementation of it in conversations

It quite literally uses the signal protocol and the real libsignal but instead of doing the obvious thing and protecting messages with it they used it as a glorified keywrap? what the fuck

so what does this modification get you?

I presume you can just send the same ciphertext to multiple recipients in a MUC but now you’re just digging at the bottom of the barrel.

the change also results in you being able to do some fun shenanigans that aren’t possible in the signal protocol with no way for others to notice. And it’s technically already fixed! just not in the real world

oh yeah i also find it funny how conversations has “message overhead” as one of the criteria, and they forget to mention that due to how shit the protocol serialization format is, there is a flat 33% overhead on all encrypted data. this also applies to matrix

@charlotte what on earth are they doing that their serialization format adds 33% automatically?

@orman their serialization formats are text based, so they encode 6 bits per byte instead of 8

@charlotte ...and this is supposed to be a serious application?

@orman @charlotte I don’t know about matrix, but XMPP uses XML to send data in band, so it needs to be serialized as text. I’m pretty sure Matrix uses json or something

@orman oh you would be surprised how much does this

at some point you get excited about protocols not doing this

email does this, most web based things (except http) do this, you name it

@mcneb10 @charlotte there must surely be a way to include a binary payload in an XML doc with some extension or something.

@charlotte I know email does it, but email has the excuse of being ancient and of an era where "why would you want to" was a valid question

@orman @mcneb10 base64 encoding or not using xml

the latter is the preferred option because xml sucks

@charlotte What’s wrong with AES-256-CBC? It’s still commonly used. The MAC truncation thing is weird but it doesn’t make it useless. Also, ed25519 is pretty good and won’t be broken until we have quantum computers. I am looking at the latest spec version if that affects things

@charlotte @mcneb10 *cries in embedded dev*

@mcneb10 aes-256-cbc is very difficult to correctly implement both due to how aes works and how pkcs#7 padding works

the mac is truncated to 8 bytes which is short enough to force a collision to occur in a reasonable timeframe

there is no issue with ed25519 here but it should be noted that signal doesn’t sign messages like that

@charlotte @orman XMPP does send video and audio data out of band as a binary data stream (fortunately) and can still encrypt it. Most images are sent as links as well and the ones that aren’t are transferred out of band

@charlotte Yeah omemo is a huge stopping block for any XMPP client developer. I hope they address it eventually. As for the HMAC, that decision is ridiculous. SHA1 has serious collision issues and it uses more bytes than that, now I get it.

@mook @charlotte Yeah XMPP is awesome. I’m very excited for muji (multi user calls)

@mcneb10 the original posts weren’t about omemo, real world omemo is worse in some ways

@mcneb10@wetdry.world @charlotte@akko.chir.rs oh very cool haven't heard of that

@orman @charlotte XMPP is also ancient. And there is a thing called "Efficient XML Interchange" (which is also specified for use with XMPP) that allows to encode XML in binary and will then also have the base64 turned back into its original bytes. It's just not used anywhere in practice, because people rarely need this for instant messaging.

@charlotte that makes me feel better about not getting that mbedtls psa api change working.

crypto library documentation is the most frustrating thing I encounter on a daily basis.

@pixelschubsi @orman smaller messages are easier and faster to transmit over slow and unreliable connections, which is especially important in messengers as people’s main communication devices tend to be on such networks some of the time

@charlotte @orman Link-layer frames typically transfer more than 1KB. Most IM messages are well below this size even with 100% overhead. For most links, you either are able or unable to retrieve that one full frame, no matter if it has 300 bytes or uses its full capacity of 1200 bytes.

Except for file sharing, which can obviously be larger, but also doesn't use Base64 in XMPP either.

@pixelschubsi @orman yeah so based on messages I have received in my friend group chat, they all tend to be all at least 1kB big

@pixelschubsi @orman even then, larger frame sizes still have larger changes of being corrupted or dropped

@charlotte @orman 1KB content or incl. overhead? My Mastodon instance is literally limiting the messages here to 500 chars which, if I don't pack it with emojis, will be less than 1KB raw content as well. And most of my IM messages are shorter than my toots.

Of course you can always have longer texts as well, but I still doubt that for IM, network issues happen while you fetch a single message, except for absurdly inefficient data formats (and +33% Base64 doesn't count as such)

@charlotte @orman technically true, but for most wireless links you're in waiting most of the time so it's just statistically very unlikely to lose connectivity within the transfer of the frame no matter its size.

@pixelschubsi @orman “lose connection” is not the same as “losing packets” or “corruption”, which do not imply the former

@charlotte @orman yes, but if you remain connected, losing a frame or a frame being corrupted usually only means you'll get it a few ms later, which realistically doesn't matter. Only if you lose connectivity (no matter if the last frame was transferred correctly or failed) you'll have to reconnect and then you may have packet loss in the upper layers which will cause further delays.

@charlotte @orman I'm not saying better encoding would be bad, I just say that in practice, it's probably a non-issue. And in practice, people have probably put well more thought about running XMPP on constrained networks than they have for Signal, see for example https://www.isode.com/whitepaper/operating-xmpp-over-hf-radio-and-constrained-networks/

@charlotte @orman Oh, and Signal and most other messengers are also using XMPP for most users, because Apple's and Google's push notification systems are based on XMPP as well. While they might not push the content itself through the push notification (and so it's not Base64 encoded) the overhead of then connecting to the server to fetch the message in a separate connection is probably more significant than 33%.

@charlotte @orman Now you make me wonder how much of this is encryption overhead and how much of that encryption overhead could be saved by using MLS.

@charlotte @orman 1KB - 33% base64 - 64 bytes encryption = ~600 bytes, would mean you didn't send a single message with less than 600 byte payload in your group?

@charlotte Nice to know, Charlotte!

@charlotte @mook Dino already has it implemented apparently. I haven’t been able to find any other clients that do though

@pixelschubsi @charlotte Oh is *that* why I end up getting toast for messages that then fail to actually load within the app?