End to End Encryption SIG - 2022-10-22

Does anyone know OMEMO? Are the ciphers restricted to AES-128 and AES-256. or can better ones be used?

What's better

Good - question - simple answer: anything but AES? Something with pretty curves?

Or mabe I'm wrong - maybe it does support X25519 https://ianix.com/pub/curve25519-deployment.html but just not the code I was looking at... Anyone know?

test_h: AES is symmetric, 25519 is asymmetric, they are used for different use cases

hypothetically you can use an asymmetric cypher instead of a symmetric one, but it will be grossly inefficient for the same level of security

I withdraw the question and will come back when I've read the code more completely. It was my first look at the python-omemo code and I was surprised to see AES-128

# Prepare AES-GCM key and IV aes_gcm_iv = os.urandom(12) aes_gcm_key = os.urandom(16) aes_secret_data = aes_gcm_key if plaintext is not None: # Create the AES-GCM instance aes_gcm = Cipher( algorithms.AES(aes_gcm_key), modes.GCM(aes_gcm_iv), backend=default_backend() ).encryptor()

But that may be just a tiny part of the negotiation and exchange.

On a more birds eye view, I think my question was more like: is OMEMO a negotiation protocol where weak or maybe stronger ciphers can be chosen for any given connection, or does the protocol firmly specify all the ciphers?

https://xmpp.org/extensions/xep-0384.html The specification is here ^ test_h

Yes thanks; I read that. It's why I asked the question, because the spec says: "The encryption step uses authenticated encryption consisting of AES-256-CBC with HMAC-SHA-256." but the code seems to be saying AES-128 "aes_gcm_key = os.urandom(16)"

test_h: that's for the old version of OMEMO, AES-256-CBC + HMAC-SHA-256 is used since OMEMO 0.4.0, before that it was AES-128-GCM

What does code have to do to keep up these days :-) Thanks; so the answer is that OMEMO is NOT a negotiated protocol and the ciphers are fixed in the spec. Thanks for clarifying for me.

One more ignorant question from a crypto noob: OMEMO is a specification tailored to XMPP. If you stripped out the XMPP part for argument's sake, is it different from NoiseC as a protocol>

Well, clients negotiate the version of OMEMO to use and thereby negotiate the ciphers ;)

OK - the version gets negotiated - no problem.

Is NoiseC fundamentally similar to OMEMO-XMPP?

(apply grains of salt liberally.)

If you by "NoiseC" mean the Noise protocol then no.

is effective key length of 56 bit for AES-XTS generally considered secure for personal cybersecurity needs?..

and what does "effective" mean?..

I've been browsing a prominent AV vendor page and it says it offers software that can encrypt files using AES with this cipher mode... I lmao'ed but now I wonder how different "effective key length" is different from "key length"...

larma: You recently mentioned that you don't like Ox anymore. Could you elaborate what you don't like? I'm really hoping that MUC and file upload will get specified and clients will adapt it to end the Omemo key mess and make MAM usable for new clients.

https://crypto.stackexchange.com/questions/24210/128-bit-3des-key-and-aes-key-whats-the-difference > If a 128 bit triple DES key is created the amount of effective key bits - the bits actually used in the protocol - is 112 bits. This is because there is one bit (the least significant one) in each byte assigned to create odd parity. This way the correctness of the key can be validated with certainty if a bit is flipped by mistake. Some implementations require these parity bits to be set correctly, other implementations simply ignore the parity bits. it looks like effectiveness of the key measures how much enthropy the key's bits actually provide

Martin, I don't like the PGP part of it. PGP is a complex message and key format, which we don't make any use of. But using those complex formats adds a lot of complexty to implementations

trollge: That doesn't apply to AES though, it has a dense keyspace and doesn't do parity bits.

I know, it's DES-specific...

That being said, maybe somebody just used their DES key for AES by just doing a K || K. Then it would hold up but I do hope that's not the case.

Hmm, not sure if it makes implementations complex. I found it pretty straightforward compared to OMEMO which gives me headache when looking at the XEP only. 😂

I think the complexity is handled by the PGP lib and I am only doing the easy part.

🙂

That doesn't mean the complexity goes away and clients that can't use your PGP lib suffer doubly

Shouldn't there be a reasonable PGP lib for every language?

No?

Don't know. That's why I asked.

No there shouldn't and while I haven't exhaustively checked, I'd assume there isn't.

I doubt omemo will go away in favor of ox for a lot of reasons. One being the less privacy which doesnt mabe sense as default. Also the keys are harder to manage with ox unless you cut corners. Also library support. Is there actually anything outside of gnu? I dont have that much confidence in the project imo

> I doubt omemo will go away in favor of ox for a lot of reasons. Who said it should? Ox is the successor of 0027 and not of OMEMO. > One being the less privacy which doesnt mabe sense as default. There are people who would trade forward secrecy and deniability for working MAM. I think Ox is good enough for a default encryption to have no unencrypted messages stored on the server and those who need whistle blower or political activist grade security could enable OMEMO.

> Also the keys are harder to manage with ox unless you cut corners. Not sure what you mean by this. Ox should get the ability to transfer the encrypted private key via pep (like an autocrypt setup message). But I don't know of any client implementing it yet. > Also library support. Is there actually anything outside of gnu? I dont have that much confidence in the project imo I am using protonmail/gopenpgp and there is also Sequoia.

Can you please stop referring to people who want forward secrecy only the ones being whistleblowers or something? I get if you dont like the privacy community but lets not devalue the conversation like this.

MSavoritias (fae,ve)‎: u sure you didn't confuse your recipient?

> Can you please stop referring to people who want forward secrecy only the ones being whistleblowers or something? I didn't say that. I called it whistle blower grade security. I didn't say people who want it have to be whistle blowers. > I get if you dont like the privacy community but lets not devalue the conversation like this. I also didn't say I don't like them. I just like to have a choice to also use encryption without FS and stuff which makes mam usable on new devices. Either you got me wrong or you want to push me into a corner where I look like I want to take you FS and stuff away. So far I assume the first and hope you read my messages again more carefully.

Martin: just hiding the complexity in a library doesn't mean it's not there. As a whole thing I would say OX is more complex to implement than OMEMO. Yes, often enough there are libraries that can take a lot of the work from you. I'm also not saying that OMEMO is much better in this regard, but its complexity is mostly due to cryptographic complexity of its properties. I'm rather proposing to build a simple encryption protocol with the same properties as OX, just minus the PGP stuff: One asymmetric key per user used for both, signing an encrypting, public key and encrypted private key on PEP. Asymmetric key is used to encrypt a symmetric key, which is then used to SCE encrypt the content. You probably want to use ed25519/x25519 for asymmetric and ChaCha or similar for symmetric, which would give you great performance even on low end devices.

Indeed using ed25519/x25519 keys with Ox is a lot faster than RSA 4096bit. But it seems programs using gnupg are especially slow. No idea if sequoia is better in this regard.

But I think the Ox creators did choose PGP because it is already widespread and has existing libs and they don't have to invent their own crypto.

Thanks dequbed : noob level question rephrased - If a team was looking at using the Noise protocol for the AKE part of a chat/AV application, and could also use "OMEMO minus XMPP" as a protocol that might give them interoperability with XMPP, are there clear reasons to use the Noise protocol over OMEMO-XMPP?

(I know OMEMO is more than handshake, but this question just focuses on that part.)

(("might give them interoperability" now or some day in the future.))

test_h: I think the thing that you are missing is there is absolutely nothing wrong or weak about AES

It's even safe against the non-existent theoretical "quantum computers"

moparisthebest, some AES methods are weak against wrong usage of them, for instance using AES-CBC without integrity checks.

For me, "quantum computers" died with Schrodinger's cat :-)

Sure some modes aren't good, but AES is fine

OK AES is fine, and OMEMO 0.4.0 is fine AES. I'm a noob who knows nothing about the NoiseP and little about OMEMO except that if they had the crypto equivalent in their handskake they might be in a better position to interoperate with XMPP/OMEMO. So is NoiseP fundamentally different from the AKE in OMEMO.

> some AES methods are weak against wrong usage of them, for instance using AES-CBC without integrity checks. Link Mauve: u mean cipher codebook mode? Isn't it purely theoretical mode that should never be used irl because of its awful anti-cryptanalysis properties?

No taking in account CBC-like modes as XTS

trollge, dunno, I’m not really good at cryptography, but it’s the only AES mode available on the AES engine of the Wii, so it’s the one I’ve played with the most.

Oh it stands for Cipher blockChaining... all good with that one

trollge, I’m not aware of anything wrong if you check the integrity of the data, e.g. through a hash mechanism.

Thanks dequbed : noob level question rephrased - If a team was looking at using the Noise protocol for the AKE part of a chat/AV application, and could also use "OMEMO minus XMPP" as a protocol that might give them interoperability with XMPP, are there clear reasons to use the Noise protocol over OMEMO-XMPP? (I know OMEMO is more than handshake, but this question just focuses on that part.) (("might give them interoperability" now or some day in the future.))