Daniel: > The current PR clarifies that though by putting it in the <key>. The key length is specified to be 16 bytes and the auth tag is just the rest.
Ah ok. Still not sure why the auth tag is appended to the key now instead of the payload. Seems like a lot of duplicated data for no real security benefit. > I think we should just store the last time we received a message from a device and if that age is above a certain threshold we should stop sending messages to that device. A date in PEP can be manipulated by the server admin. I like that idea. > For now I'd say if decryption fails try the next matching rid. The issue isn't with decryption failure, it's that you could encrypt to the wrong session when there's a (malicious?) deviceId collision. For example in a MUC, someone could make take their trusted deviceId/session/fingerprint and republish it under another deviceId that collides with someone else in the MUC, causing one of the members to no longer be able to decrypt messages to their deviceId, depending on how collisions are handled. The behavior depends on your trust logic and collision handling, which should probably be mentioned in the XEP. Sam: > In XMPP at least this is already covered by doing a disco#info on the device Oh good call. I see what Daniel was saying about users being tricked by nicknames though, so maybe it is best to omit it. On Sat, Oct 1, 2016 at 4:49 AM, Daniel Gultsch <[email protected]> wrote: > FYI: There is a pending PR [1] that rewrites the OMEMO XEP to use the > (well documented) Olm specification and also adds some minor > improvements that came up during the audit [2]. > > cheers > Daniel > > [1]: https://github.com/xsf/xeps/pull/251 > [2]: https://conversations.im/omemo/audit.pdf > > 2015-10-28 16:42 GMT+01:00 XMPP Extensions Editor <[email protected]>: > > The XMPP Extensions Editor has received a proposal for a new XEP. > > > > Title: OMEMO Encryption > > > > Abstract: This specification defines a protocol for end-to-end > encryption in one-on-one chats that may have multiple clients per account. > > > > URL: http://xmpp.org/extensions/inbox/omemo.html > > > > The XMPP Council will decide in the next two weeks whether to accept > this proposal as an official XEP. > > > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: [email protected] > _______________________________________________ >
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
