jdev - 2022-05-02

https://xmpp.org/extensions/xep-0420.html#affix_elements > Prevent known ciphertext and message length correlation attacks. The content of this element is a randomly generated sequence of random length between 0 and 200 characters. TODO: sane boundaries? Hmm, so I should change rpad to '200-messagelength%200' 🤔

https://files.mdosch.de/upload/zPDnDQiM8CUtYgpq9Vfe0zGK/pHxv-z42S7ykFzi6A5dxbg.jpg

BTW, why we have two jdev? 🤔

The old one got replaced with the new one because the old server was extremely old.

It isn’t in use any longer (AFAIK).

Wasn't it destroyed?

I don’t know.

About the first question, don't you think 200 chars is pretty long for the rpad?

Martin, mind that when generating the padding based on the message length, you need to count utf-8 bytes, not unicode codepoints btw ✏

He, i think I have to change that.

Should be OK now: > go build . && echo "☭"|./go-sendxmpp --ox martin@mdosch.de > Message length: 3 > Rpad length: 97 > Rpad: e1f49f122ccf5a860024a1eaabb8de9811d6d3a1ff89dc8f838d7b317c49f9011bea3dddf8f6bc4432c976947bbd42137cf25b870aad04680a0eda3d876bcdabb47b50a319f1ab87d4adcf460c4a98a91f9b25cf9b3150ccff1493960cbb72931e But I think I rather stick with padding to a multiple of 100 as 200 seems a bit exaggerated…

i have a server, which when in muc, the muc reflection of the message has 2 stanza-id nodes

one with a "by" attr of the muc jid, so archive of the muc

one with a "by" attr of the account of the user who sent the message

.. why why why

the spec is great about it

everything is written like it allows multiple stanza id elements

but then in the last sentence

The value of the 'by' attribute MUST be the XMPP address of the entity assigning the unique and stable stanza ID. For one-on-one messages the assigning entity is the account. In groupchats the assigning entity is the room.

no .. the assigning entity is whatever is in the by attr and not necessarily the room or account