andyFlow, yeah, that's pretty much the idea behind KeyTransportElement. It should be super easy to extend/reuse OMEMO-core to encrypt whatever the user may want. We're thinking about also writing a spec for this
dwdhas joined
intosi has left
intosi has joined
Zashhas left
Zashhas joined
dwdhas left
Flowandy: that's what I thought. btw I see that "messageelement" is explained in means of terms and used in 4.5, but it's nowhere stated what it is in terms of XML. Is it the 'encrypted' element qualified by the omemo namespace?
andyFlow, yes. 4.5 states "This is all serialized into a MessageElement, which is transmitted in a <message> as follows:" with the example right after it. Should I make this more explicit somehow?
andyMaybe include the term MessageElement in the name of the example or something?
andyWell one could infer its XML structure from the schema, given the information from the glossary description mentioning it's an OMEMO element, which itself is an <encrypted/> element in the omemo NS, and that it has a <payload/>
Flow<encrypted/> element: An OMEMO element that contains encrypted data. Its <payload/> element contains human readable text, similar to a message stanza's body element.
intosi has left
intosi has joined
Flowandy: Sure, I'm just suggesting what could be improved
andyYes, I understand
FlowAnd right now, I'm missing an explicit statement what a MessageElement is
andyThe problem with that approach is that a KeyTransportElement is also contained in an <encrypted/> element, so I think calling it EncryptElement would lead to confusion
FlowI also think that MessageElement is not a good name. I would simply refer to it as "<encrypted/> element" in text. That is was most XEPs do in similar cases.
FlowAlso the statement that it contains a chat message is wrong, if you want to extend it at some point
andyHow is it wrong? MessageElements are defined as containing chat messages. That's their explicit purpose
FlowIf you say: MessageElement is an <encrypted/> with <payload/> then yes
Flowandy: Not really no
andyOMEMO element -> An <encrypted> element in the urn:xmpp:omemo:0 namespace. Can be either MessageElement or a KeyTransportElement
MessageElement -> An OMEMO element that contains a chat message. Its <payload>, when decrypted, corresponds to a <message>'s <body>.
KeyTransportElement -> An OMEMO element that does not have a <payload>. It contains a fresh encryption key, which can be used for purposes external to this XEP.
Bundle
andyso a Message element is an <encrypted/> element in the omemo ns, which has a <payload/> that contains the chat message
andyMaybe I'm missing something because I've been working with this stuff for months, but that seems pretty clear to me?
andyoh, and ignore that stray 'Bundle' at the end there. copy/paste fail :X
Flowandy: It's not crystal clear for someone new to OMEMO as it could be.
ralphmhas left
FlowNeither the schema nor the examples are considered normative in XEPs
FlowSo you should write something like "a MessageElement is a <encrypted/> element which MUST posses a <payload/> containing the encrypted chat message".
FlowI think MessageElement MUST also have a <header/> which at leat one </key> at at most one <iv/>
ralphmhas left
Flowexactly one <iv/>
andyOkay. I actually didn't know the schema wasn't normative. I'll make the definitions clear in the text then
andyThanks.
tim@boese-ban.dehas left
tim@boese-ban.dehas joined
Flowandy: Although it's not that of an issue, I did understand what you meant when I was first reading the XEP a few weeks ago, I now wondered e.g. what exactly an message element is. I didn't found an answer in the text (while the examples and the schema provide a good idea of what it is).
dwdhas left
andyFlow, I understand. I appreciate the opinion of a fresh pair of eyes. After you've been working on something for quite a while, a lot of things just seem obvious to you, that might confuse people that are new to the matter
Flowandy: another question, what' is the value of a <key/> element in a MessageElement? The encrypted key for the <payload/> encrypted with the rid devices pubkey?
andyPrecisely
andyOr rather, it's not encrypted with the rid pubkey
dwdhas left
andyit's encrypted in the long-standing axolotl session with the rid device
Flowvalueable information that should go into the xep
Flowand what's the value in case of a KeyTransportElement?
andyFlow, would you say it's preferable to explicitly state these things a) in the glossary, b) in the section where it's used, c) both ?
FlowI'd say never do c) and in this case I would go with b)
andyOkay
FlowThe glossary is mostly to introduce terms maybe unknown to readers and to give them a quick idea about what the term is about.
andyI see. I guess I've been treating it more like a place to dump definitions
andyBut that makes sense
andyIn a KeyTransportElement, the <key/> is a fresh, unused key, again encrypted with the sid<->rid session
dwdhas left
andyI guess I'll move these definitions into the relevant sections and expand a bit on them
danielhas joined
dwdhas left
dwdhas left
ralphmhas left
danielhas left
danielhas joined
andyFlow, how do you like this: "This is all serialized into a MessageElement. The MessageElement consists of an <encrypted/> element in the urn:xmpp:omemo:0 namespace, which MUST contain a <header> element and a <payload/> element. The <payload/> element contains the encrypted chat message's <body/>. The <header/> element is tagged with an sid attribute and MUST contain one <iv/> element, containing the common IV used to encrypt the <payload/>. It also contains one <key/> element for each recipient, of which there MUST be at least one. The <key/> elements are each tagged with an rid attribute, and contain the key used to encrypt the <payload/> which is encrypted using the long-standing session the sender shares with the recipient's device corresponding to the rid." ?
Flowandy: better. :) You should mention that the data is base64 encoded. I also don't like "contain the message's <body/>" element.
FlowI did not like "correspondents to <body/>" too. I know what you are trying to tell here. I would simply re-use the definition of the body element here.
danielhas joined
danielhas joined
andyokay
dwdhas left
FlowIt is certainly not the message's <body/> element, because <payload/> only provides a subset of the features the <body/> element provides.
andyYes, I wasn't very happy with that either
andyYou're right
FlowAlso it is unclear what should happen if a message stanza has a <encrypted/>+<payload/> and a <body/> element
Flowso re using the definition from rfc 6121 5.2.3: the <payload/> element contains encrypted human-readable XML character data.
intosi has left
ralphmhas left
andyDone. Also added to the Sending a key section: "This is all serialized into a KeyTransportElement. The KeyTransportElement is defined analogously to the MessageElement, but it MUST NOT contain a <payload>. The encrypted key contained in the <key/> elements is thus unused and can be used by other protocols."
andyIs that clear enough? I don't think it'd be a good idea to repeat the entire definition
ralphmhas left
dwdhas left
dwdhas left
soulianehas left
foss81405971has left
waqashas joined
dwdhas left
dwdhas left
dwdhas left
dwdhas left
Tobiashas joined
arunehas left
arunehas joined
dwdhas left
xnyhpshas left
dwdhas left
dwdhas left
dwdhas left
dwdhas left
dwdhas left
dwdhas left
dwdhas joined
artyhas left
artyhas joined
dwdhas left
dwdhas left
dwdhas left
dwdhas left
dwdhas joined
artyhas left
artyhas joined
stpeterhas joined
ralphmhas left
ralphmhas left
dwdhas left
ralphmhas left
daurnimatorhas joined
dwdhas left
dwdhas left
soulianehas joined
Flowandy: It's fine by me. I just wanted to make sure that the <key/> element never holds two different types of keys, .e.g pub and private key.
dwdhas left
andyAh. Maybe I should explicitly mention that they're 128-bit symmetric keys.
Tobiashas left
andyOr maybe it would be better to make that a minimum, rather than a fixed size. I had actually been thinking about this before. How to make sure this is a flexible as possible without adding a complex request-response type of negotiation...
danielhas joined
artyhas left
Flowandy: doesn't this mostly depend on axolotl?
FlowAt one point in the future OMEMO may need to negotiate the axolotl version used.
andyFlow, I am referring to the payload key. That's pretty much independent from axolotl, as axolotl is only used to encrypt the key itself. But we can of course choose whatever key we want to put in there
andyAt the moment, OMEMO uses 128bit AES-GCM for payload encryption, and thus the keys are 128 bit
Flowahh
Flowright
andyBut since the KeyTransportElement is/should be independent of the encryption OMEMO uses for its chat messages, we should think about making this "extensible"
Lancehas joined
Flowandy: question is, does is need to be negotible?
Flowor would <payload mode='aes-gcm-256'> be sufficent?
andyI *really* don't want it to be. Negotiation is kind of a pain to do
andyWell as far as I'm aware, GCM is currently only specified for 128bit block ciphers. And switching away from an AEAD mode would bring a lot of extra complications. So I don't feel too badly about fixing the payload encryption to this one specific cipher/mode combinations
FlowRight, but you should prepare that devices may want to announce that they support $cipher in case aes-gcm-128 became insecure
danielhas joined
andyIn that case we would probably want to bump the namespace version I think?
Flownot sure, I would maybe simply have devices announce what they support additionally to aes-gcm-128, and add a optional mode attribute to <encrypted/>
FlowBut I'd like to hear what zash and thjis say about this
andyMy main concern at this point is that I don't want to limit extension protocols (e.g. if somebody decides to spec full-stanza encryption based on OMEMO) to this certain block size, which is why I was thinking about mandating that implementations provide a minimum of 128bit keys. That way if somebody wants to do aes-ctr/hmac-sha-3 encrypt-then-authenticate or whatever, they can.
andyFlow, well the problem I see with that is that it's much more complicated than just simple "i can also do aes-ctr 256", because that's not authenticated encryption anymore. Which means you'd have to also specify integrity protection, which involves a KDF and a MAC. And at that point you're kinda negotiating complex cipher suites, which would need to be well-defined ahead of time, etc...
Flowassuming the sender wants authenticated encryption
andyAnd I guess you'd want to put that information into PEP, rather than transmit it in-band
Flowthe capabilities in pep, of course. but what's actually used within <encrypted/>
andyYou pretty much never don't want authenticated encryption if you know what you're doing [citation needed]
SamWhitedtries to think of a use case for that... one probably exists, just not likely in chat.
FlowI won't argue with that :)
andyYou also don't want your users having to worry about what encryption is used in the back end, especially if different ciphers may have not just different strengths but also different kinds of security guarantees...
andySo you would have to define some sort of prioritization list or something... It just gets kinda ugly
FlowMy point was that you may want to provide an upgrade path regarding the used encryption method in OMEMO that doesn't require an namespace bump.
andyI mean crypto agility is nice, don't get me wrong. I just don't really think the benefits are worth the cost in this scenario
SamWhitedTying it to a namespace bump seems clean to me. It gives you a nice guarantee that you'll definitely be able to talk to the other client, no matter what.
SamWhited(assuming you both support the same namespace)
andyYeah, I don't really have a problem with the idea that a specific protocol version is tied to one specific cipher suite
andyIf people really do have special needs regarding the cipher usage, they can always extend the protocol
FlowSo devices need to register to multiple PEP nodes if we have multiple OMEMO namespaces. Not sure if that's what we want.
xnyhpshas left
andyHm, that's true
andyI'll think about this for a while
FlowI mean we sure will have another OMEMO namespace because protocol changes. But I'm not sure if tying a encryption to namespace is a good idea. Why not say: "This is the default is nothing else is specified. This is how devices can announce support for other modes, and this is how you use them. And make sure your library selects the best suiting mode if multiple are possible".
intosihas left
FlowI'm not sure how long aes-128 is considered to be secure. ~2030 seems to be the common answer. But http://www.keylength.com/en/compare/ also says 2015
intosi has joined
intosi has left
ZashSource?
andyAccording to the BSI
andygerman federal office for information security
Flowbut i'm not sure if the site simply misreads the BSI paper
FlowAnd I personally think that AES-128 is fine for the next 1-2 decades.
FlowBut who can foresee the future without having the right car.
ZashPretty sure I read somewhere than AES-128 is good enough until AES is broken.
SamWhitedThis is probably true.
dwdhas left
SamWhitedAES-128 is fine; I suspect that weaknesses in the protocol will be found before we break 128, and if 128 is broken it's not going to be long before 256 is broken too since it's such a tiny entropy difference (though I can't remember how many extra bits you get off the top of my head... 8 or 16 maybe)
Zash And AES-256 was supposedly more broken than AES-128
andyI can't actually find any reference to 128bit not recommended after 2015 in that BSI publication
SamWhitedI doubt that too, but unless I have hardware AES I like to play it on the save side. Side channel and timing attacks like the ones people have hypothisized exist in AES-256 are hard to use in practice. It would probably require a targeted attack, at which point it's easier to just steal your phone.
SamWhitedBut I'm just speculating wildly when it comes down to it.
andyThere are some scenarios in which aes-192 and aes-256 are less secure than aes-128, that's correct.
SamWhitedandy: Are there actually proven? I've only ever read about supposed timing attacks and what not.
andySamWhited, A. Biryukov und D. Khovratovich, Related-Key Cryptanalysis of the Full AES-192 and AES-256, Asiacrypt 2009, LNCS 5912/2009, 1-18
waqashas left
SamWhitedFound it; thanks.
andyI'm actually not sure whether AES-128 has been broken further since then as to be weaker than the complexity reduction the authors offer here
Ge0rGsteal your phone... or unscrew your MBP hard disk... https://twitter.com/i0n1c/status/658761878861139968
andyActually they apparently reduced the complexity even more for those longer block sizes.
andyBut keep in mind these are related-key attacks
andySo, not really applicable here (unless the entropy source of the generating client is severely broken)
SamWhitedWhich has been a problem in Android in the past... but there's also not much we can do about that.
andyWell hopefully more than just android clients will adopt OMEMO :P
SamWhitedI wonder how iOS handles entropy. /me goes to find out.
SamWhitedYah, forgot that this wasn't the Conversations room for a moment there.
andyHehe
waqashas joined
andyalso, Ge0rG, scary
goffihas left
Flowhas left
dwdhas left
dwdhas left
ralphmhas left
artyhas joined
dwdhas left
Martinhas left
ralphmhas left
ralphmhas left
Martinhas joined
Martinhas left
ralphmhas left
tim@boese-ban.dehas joined
Lancehas joined
Laurahas left
ralphmhas left
Lancehas joined
Flowhas joined
tim@boese-ban.dehas joined
ralphmhas left
edhelashas joined
edhelashi everyone :)
foss81405971has left
MattJEvening
ralphmhas left
edhelasI'll try to take some times to work on a new version of Bookmarks
edhelasI was wondering if it's possible to just allow bookmarks of URI, then we can actually bookmark everything (from a chatroom, to a url, a pubsub node…) ?
SamWhitedThere's a new version of bookmarks (or will be)? What were the changes?
arunehas left
andySamWhited, it's just brainstorming at this point, I believe. This scratchpad was also posted over in the Conversations channel: https://lite5.framapad.org/p/OlHwr5GBlY
SamWhitedOh nifty, I missed that.
Alexhas left
Alexhas joined
SamWhitedhas left
SamWhitedhas left
SamWhitedhas left
xnyhpshas left
edhelasSamWhited, I'm working on it :) I'd like to publish it in the upcoming days/week, I have to fix some stuffs on my client before that
XSF Discussion - 2015-10-27