Hi Paul and all, On Freitag, 6. Oktober 2017 10:12:02 CEST Paul Schaub wrote: > I'm currently working on JET-OMEMO, which will hopefully specify how to > use OMEMO with JET to encrypt Jingle Transports. > > One thing I'm not sure about is, whats the best way to encrypt the > Transport Key. Initially I planned to treat the key as a message body. > The resulting <encrypted/> element would then be added as a child to the > <security/> element. I don't think this is a particularly elegant method > though. > > First of all the OMEMO encryption scheme already contains a symmetric > AES-128 key, which normally encrypts the message In encrypted messaging, > this key is encrypted using the OMEMO ratchet. By treating the Transport > Key as a message body, we introduce one unnecessary encryption layer. > Ideally the Transport Key is directly encrypted with the ratchet. There > are multiple ways to achieve this. > > As a first option, we could just create a Key Transport Message as it is > already described in XEP-0384. This prevents us from choosing ciphers > other than AES-128-GCM-NoPadding though, since this is the symmetric key > type "hard-coded" in OMEMO currently.
I would go with the simplest solution. IANAC (I Am Not A Cryptographer), but AES-128-GCM-NoPadding sounds fine to me. There’s no need to add complexity where none is needed. (That’s not to say to remove the mechanisms for negotiating the symmetric cipher altogether; but in the context of OMEMO, for the time being, only that one cipher makes sense. If OMEMO evolves to support different symmetric ciphers, that’ll be a namespace bump anyways, I suspect.) > In order to fix the issue mentioned above, we could introduce cipher > agility for the symmetric key used in OMEMO. This would allow the usage > of different ciphers in OMEMO and simultaneously in OMEMO Key transport > messages. My advice: Don’t touch OMEMO for this. > Alternatively, we could skip OMEMOs symmetric encryption layer in the > context of JET-OMEMO, so that the JET Transport Key is directly > encrypted with the ratchet. This sounds sketchy to me though. Even > though libsignal gives you direct access to the ratchet, we'd use OMEMO > in a way in which it is normally not used. That sounds like more complexity for implementations. I’d avoid that unless there’s a requirement for that. I don’t think that’s the case here. > Ideally we would solve OMEMOs incapability of encrypting arbitrary > elements altogether, but that's probably a bigger construction site? Indeed :-). kind regards, Jonas
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
