undefined | Better HN

0 pointsCiPHPerCoder9y ago0 comments

> The only whitepaper I could find for the whole system was for ShadowChat, which says they use AES-256-CBC to encrypt the chat.

Okay.

> AES is a symmetric encryption algorithm, and a strange choice for a chat protocol.

No, it's the standard choice.

Signal uses AES-256-CBC + HMAC-SHA-256, for example.

> Furthermore, CBC is not great at hiding patterns, and chat will often have a lot of patterns.

That's not true. CBC mode isn't great at hiding patterns with IV reuse. Solution: Don't reuse IVs.

The problem with CBC mode is that it's unauthenticated, and as a result is often susceptible to padding oracle attacks that allow messages to be decrypted byte-at-a-time.

https://paragonie.com/blog/2015/05/using-encryption-and-auth...

A better mode would be GCM, or maybe GCM-SIV, or scrap AES entirely in favor of ChaCha20-Poly1305.

0 pointsCiPHPerCoder9y ago0 comments

> The only whitepaper I could find for the whole system was for ShadowChat, which says they use AES-256-CBC to encrypt the chat.

Okay.

> AES is a symmetric encryption algorithm, and a strange choice for a chat protocol.

No, it's the standard choice.

Signal uses AES-256-CBC + HMAC-SHA-256, for example.

> Furthermore, CBC is not great at hiding patterns, and chat will often have a lot of patterns.

That's not true. CBC mode isn't great at hiding patterns with IV reuse. Solution: Don't reuse IVs.

The problem with CBC mode is that it's unauthenticated, and as a result is often susceptible to padding oracle attacks that allow messages to be decrypted byte-at-a-time.

https://paragonie.com/blog/2015/05/using-encryption-and-auth...

A better mode would be GCM, or maybe GCM-SIV, or scrap AES entirely in favor of ChaCha20-Poly1305.

0 comments

3 comments · 1 top-level

kewde9y ago· 2 in thread

It's not voiding the cryptographic doom principle, that's one thing. The HMAC is dealt by OpenSSL it seems and is the hash of the timestamp, destination and encrypted payload. It's appended outside of the encrypted payload. https://moxie.org/blog/the-cryptographic-doom-principle/ https://github.com/shadowproject/shadow/blob/master/src/smes...

On the other hand I agree to switching over to a different mode to eliminate padding oracle attacks.

The IV are 16 random bytes generated by OpenSSL's RAND_bytes. https://github.com/shadowproject/shadow/blob/master/src/smes...

CiPHPerCoderOP9y ago

If one of the project devs is reading this thread:

https://github.com/shadowproject/shadow/blob/f3fa333f8377688...

That's really hard to read.

Also, don't use OpenSSL: https://paragonie.com/blog/2016/05/how-generate-secure-rando...

kewde9y ago

Hi,

Yes we're always where the critics are, they are or best source of information.

I'm very happy to see our work being reviewed. I'm not an expert cryptographer but I am capable of understanding it. (fyi I didn't code it).

Our memcmp in constant time is not the prettiest, but it's short so we roll with it :P

This project started around 2014, LibSodium was still very small back then and OpenSSL, in ours view, remains the defacto standard. Is there any particular reason on why we should move away from RAND_bytes() ?

1 more reply

j / k navigate · click thread line to collapse