Backup encryption is not using a key derivation function

[lunar-debian]

Hi!

The encryption mechanism used for backups is currently using the given password as the AES key as ASCII bytes, later padded with 0 to reach the required 256 bits.

This seriously reduces the encryption security as it makes the actual keyspace quite tiny. I haven't verified this, but I suspect passwords will silently be truncated to 31 characters in case they are longer.

Proper key stretching should be implemented. I see it's already implemented in crypto/lollipop/cryptfs.c and crypto/ext4crypt/KeyStorage.cpp, both with scrypt and PKDF2.

I guess one question is how to keep compatibility with older backups. In all cases, I guess trying twice, with derived key and then with the raw password would work.

[lunar-debian]

I've pointed this issue to a friend with proper experience in implemeting crypto algorithm whose reaction was the following:

ooooh, openaes does CBC with its own nonstandard made-up padding and header. How fun!
Oh, and this isn't even CBC!
If you model CBC as IV || CBC_ENCRYPT(IV, MSG) ...
they're doing HEADER || CBC_ENCRYPT(HEADER, IV || MSG)
that's going to give you one block of known plaintext at the start of every message.
trivial to find two messages encrypted with the same key that way.
oooooh, IV made from the ISAAC RNG, with a fallback to rand()!
and the padding on the last block is just a bunch of '0' bytes
wait, no , there's some kind of weird padding
ah, of course. They pad with a prefix of [00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f].
There's probably a padding oracle attack in there.
*with a prefix of [01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f].
Also the format is is malleable, but that's the least of your worries
summary: Don't use openaes. If you must use it, don't use it like this.

[rugk]

Well,… never build your own crypto!