ralphmI'm having this discussion on E2E encryption with michael on Twitter, but what he describes about key exchange sounds like a bug. https://twitter.com/mickael/status/1093128804728557570
ralphmThis isn't inherent to the protocol, is it?
jonas’does it use multi-item PEP?
dwdNo, the key exchange stuff is pretty rubbish.
ZashPEP and MAM on login adds a bit, not sure how significant it is
dwdThis isn't helped by the key service really needing more smarts than just a big PEP blob anyway.
ZashMulti-item was less commonly supported by servers before, so would have been a pain to deploy if it was required
ralphmdwd: but is it as bad as mickael describes?
pep.ralphm, bundles are only needed on session init
pep.So they get fetched at that time
pep.But session init doesn't happen often
dwdralphm, Well, I don't know about how loaded blatting out a big blob actually makes a server.
ralphmpep.: Yeah, that was my thought, too.
jonas’I think the increased message size in MAM is probably more worrisome
pep.Well that's an issue with e2ee at all right?
jonas’that affects bandwidths (memory, disk and network) and disk storage
jonas’pep., yes, that’s kind of the point
ralphmjonas’: well, I am not surprised about encrypted stuff being bigger in general
KevDepends if it's hitting disk for PEP each time or something, I imagine.
ZashThe real problem is that everything is hitting the disk for way more stanzas now than in the past
dwdKev, And if not, the memory pressure is probably greatly increased.
ralphmBut this isn't a property of which protocol we use for e2e, is it?
KevMessage size? No. Key exchange details? Yes.
ralphmThe increase in MAM storage, I mean.
Kev(Or ln -s No Not\ Entirely)
ralphmRight, if the key exchange is suboptimal, then that's a thing we can look into. I'm surprised that mickael says the impact would be 'huge'.
dwdralphm, Yes, it can be. MLS, for instance, would be hugely more efficient in bandwidth terms where OMEMO is used within MUCs, for example.
dwdralphm, But I would personally just treat OMEMO as the experiment it is, and await MLS patiently, and do things properly then.
ralphmI don't think we are talking about group chats at this point, though.
pep.If you don't have to reencrypt for each device, certainly yes :)
goffidwd: I forgot to ask you about that by the way, is there any progress and where can we follow them?
pep.ralphm, for 1:1 you still encrypt for each of your recipient's devices
dwdgoffi, MLS has an IETF working group, and is taking time - lots of effort in the low-level crypto.
ralphmpep.: sure, but what's this about 100s of PreKeys?
dwdralphm, That's a property of most of these algorithms, including MLS. Each device must upload a bunch of prekeys, and a new session takes one.
pep.I'm not exactly sure about prekeys, maybe Syndace can chime in, and why we need 100. I guess that's when people want to start a session with you, and how often you need to renew them
pep.(renew them > the prekeys)
ZashWhat happens if two sessions are started using the same prekey?
dwdralphm, My sketch of a XEP for MLS, for instance, says that servers provide a keying service and hand out a single prekey for each device on demand.
KevAlthough even 'having 100 prekeys' doesn't necessitate our current mechanism.
KevRight, that'd do it.
dwdZash, Nothing - in principle. But it makes the cryptanalysis much harder.
pep.Zash, that happens regularly, because we don't have reliable message delivery. So some clients will use the same prekey until they get an ACK from the other side
ralphm(for reference, the WG is here: https://datatracker.ietf.org/wg/mls/)
dwdralphm, Note that for each session, the requester will grab all the prekeys, pick a set (one from each device), and then use them. On successful session start, the called device then removes the set from the prekey blob and re-uploads. This new bundle is then pulled by each device.
Daniel> ralphm, My sketch of a XEP for MLS, for instance, says that servers provide a keying service and hand out a single prekey for each device on demand.
This is probably the 'proper' solution. For omemo we deliberately decided against an omemo component in favor of faster adoption. But learning about the limitations of PEP and how fast we can role out components if we need to (http upload) this is one of the regrettable features of omemo.
DanielOr not that much regrettable but rather 'lessons learned'
dwdDaniel, For sure - and I would note that this is a fine design if treated as an experiment.
ralphmdwd: sure, but how often does one have a new session? That's still not a common thing, is it?
dwdralphm, Every new conversation.
pep.Is it some security thing I don't understand, or is it a limitation, or?
Zashpep.: What thing?
dwdpep., I would think so. The ratcheting means you can re-use a session for lengthy periods, but you'd need to store a fair chunk of cryptographically-sensitive state, so I'd think you'd discard that after a period of inactivity in a conversation and start anew later.
ralphmDaniel: when do sessions expire in Conversations?
dwdpep., That said, I've not looked at what OMEMO implementations actually do. The spec more or less says "use libsignal", so it's hard to tell.
pep.I would assume in OMEMO session initiation is not something that happens often, judging by how easy it is to lose messages when negociating a new one. If the other side starts a new session and drops the old one, and I don't, I'll send a message and they won't be able to read it.
Zashpep.: Cryptosystems usually need something like a 3-way handshake. As I understand it, prekeys are the first step in that. (Is that the "what"?)
Danielralphm: they don't
ralphmDaniel: so in Conversations, a session between two users doesn't change keys, until you add/remove devices, or explicitly want to use a new key?
DanielA session is something that exists between devices. So adding a new device will create an additional session and not change something about the existing ones
DanielBut the ratchet for each session is of course moved forward on every received message
ralphmright, I'm trying to understand what the actual traffic behaviour is, with respect to our current key exchange, and whether this is worse in some implementations than others
SyndaceUgh not reading for a day and 500 messages with a lot about OMEMO >.<
Danielralphm: regarding the Twitter?
ZashSyndace: Enjoy your FOMO :)
pep.Syndace, stop slacking off!
DanielThis is I assume about the prekeys
ralphmI Slack off all the time, I call it market research, or work, depending who's asking.
DanielSo on login due to broken pep a client doesn't know if the prekey list on the server is up to date and will update it
DanielWhich as I just mentioned on Twitter is something one could probably fix now that pep isn't broken
ralphmso without session resumption (XMPP session, not OMEMO), this might be often
Andrew Nenakhovhas left
Andrew Nenakhovhas left
Andrew Nenakhovhas left
Ge0rGI wonder why people insist on PFS, deniability and per-device keys. If you just have a per-account key that is shared between your devices, you can have such a simple e2ee scheme.
ZashGe0rG: Because PFS has more marketing behind it and looks better for ültraparanoid cryptonerds :)