Cryptography Weaknesses

[seaofmars]

Ovrdrive v2's cryptography has some weaknesses:

• Hardcoded salt: Salts don't have to be secret, but they really should be random per password/device. Currently an attacker cannot use a generic rainbow table against the digest, but they can make a rainbow table that works for every Ovrdrive.
• Custom KDF: This shouldn't be a significant issue but it'd be ideal to use a standardised KDF like PBKDF2 or, if the hardware can afford it, bcrypt.
• AES mode: From my understanding, disk blocks are encrypted with AES-256-CTR with the LBA as the counter.
  • This isn't a secure use of CTR. CTR requires that a given (IV, key) pair never repeats; using the LBA to derive the IV causes repeats whenever the same block is written to multiple times. Consequently, If an attacker obtains two versions of an encrypted block (say from two dumps of the SD card), XORing them together will cancel out the encryption and output the plaintext data in the two versions of that block, XORed together.
  • Full disk encryption is unfortunately complicated, and typically general-purpose block cipher modes shouldn't be used to do it. It would be best to use a mode specifically designed for FDE like those mentioned in the Wikipedia article for disk encryption theory. XTS is the most common, XEX is simpler but requires block sizes divisible by the cipher's block size, which should ^almost always be the case with SD cards.
  • CTR is malleable; with knowledge (or a guess) at what a piece of ciphertext says, an attacker can modify it to produce their desired plaintext, with no further secret information.

I would also suggest adding a cautionary notice to the readme mentioning that this project hasn't been audited.

Ovrdrive is no doubt a passion/toy project of yours and these may not be concerns to you, which is utterly fair. I just thought I would let you know!