3 ms·

It looks like voice packets are intended to be OCB2 (CryptState.cpp, cryptstate go package in Grumble). I haven't read the code through to figure out how to mou

by lvh 8y ago

It looks like voice packets are intended to be OCB2 (CryptState.cpp, cryptstate go package in Grumble). I haven't read the code through to figure out how to mount it (and it looks slightly funky), but if it does what it says on the tin there's a trivial, one-encryption-oracle-message forgery attack for that. Also: I don't think that means you shouldn't use Mumble. I just think someone should see if they can exploit that bug and then get someone to fix it :-) I went on their IRC and someone talked to me within 5 minutes, which is a Good Sign(TM). (I wish I had more time to just do random audits of open source projects, but the incentives aren't really lined up for that to happen, and I do more than a bit of open source work already.) [cryptstate]: https://github.com/mumble-voip/mumble/blob/4976c1ad2e0802755c15d051783403afc440b173/src/CryptState.cpp https://github.com/mumble-voip/mumble/blob/4976c1ad2e0802755... [ocb2-go]: https://github.com/mumble-voip/grumble/blob/master/pkg/cryptstate/ocb2/ocb2.go https://github.com/mumble-voip/grumble/blob/master/pkg/crypt... [ocb-forgery]: https://eprint.iacr.org/2018/1040.pdf https://eprint.iacr.org/2018/1040.pdf

zaroth 8y ago
Is it the last step of the encrypt function which would need an additional XOR operation added (XEX va XE for the encryption of the tag) to mitigate this attack? [1] S3(delta); XOR(tmp, delta, checksum); AESencrypt(tmp, tag, &encrypt_key); [1] - https://crypto.stackexchange.com/a/63642 https://crypto.stackexchange.com/a/63642
- lvh 8y ago
  The cryptographic answer is: yep, that sounds about right (with low confidence because the model violation is subtle). The cryptographic engineering answer is: use OCB3 instead which doesn't have this problem :)
bjoli 8y ago
Wow. When was it written? OCB3 is almost 8 years old. Wonder why it wasn't used.
- NikkiA 8y ago
  It was written in 2005, thus changing all the code to use OCB3 may be an unreasonable amount of breaking things that work.
  - bjoli 8y ago
    I don't know why they wrote it themselves, but if they don't want to use third party code, implementing OCB is faaaaaaaar simpler than implementing GCM or just about any other AEAD. But I suspect ChaCha20 would be a better fit since a stream cipher is a good fit for streaming audio.

by lvh 8y ago

zaroth 8y ago

Is it the last step of the encrypt function which would need an additional XOR operation added (XEX va XE for the encryption of the tag) to mitigate this attack? [1] S3(delta); XOR(tmp, delta, checksum); AESencrypt(tmp, tag, &encrypt_key); [1] - https://crypto.stackexchange.com/a/63642 https://crypto.stackexchange.com/a/63642

lvh 8y ago
The cryptographic answer is: yep, that sounds about right (with low confidence because the model violation is subtle). The cryptographic engineering answer is: use OCB3 instead which doesn't have this problem :)

bjoli 8y ago

Wow. When was it written? OCB3 is almost 8 years old. Wonder why it wasn't used.

NikkiA 8y ago
It was written in 2005, thus changing all the code to use OCB3 may be an unreasonable amount of breaking things that work.
- bjoli 8y ago
  I don't know why they wrote it themselves, but if they don't want to use third party code, implementing OCB is faaaaaaaar simpler than implementing GCM or just about any other AEAD. But I suspect ChaCha20 would be a better fit since a stream cipher is a good fit for streaming audio.