node.db4o.crypt issues: node.db4o.crypt is encrypted in CTR mode. This is a standard and widely used mode. It essentially creates a one-time pad, with no feedback, by encrypting the block number and then XORing that with the plaintext. It is therefore easy to implement for stuff that needs random access, and secure as long as you never reuse the sequence number. However, if we have: - Defrag using the same key (can happen now, but the old data shouldn't be recoverable without the other issues) - Backups using the same key (auto-backups, will happen soon) - Wandering logs (e.g. BTRFS) - Data journaling (most modern filesystems have the option) - Block remapping (flash, disk)
Then we have the possibility that we have two blocks on disk encrypting differnet data with the same key and the same sequence number. Which is VERY BAD, allowing very powerful cryptanalytic attacks: The XOR of the two blocks of ciphertext will be the same as the XOR of the two blocks of plaintext! A very similar weakness was used by MI5 in the 60s to decrypt thousands of soviet messages (reused one-time pads). Options: - Introduce an IV. Store it somewhere in the file e.g. at the beginning, or maybe duplicated. Change it every time we write the full node.db4o.crypt i.e. on writing a backup, on defragmenting, on writing from RAM if we are in full-buffer mode. This eliminates the first problem, but does not deal with the others. - Always encrypt a whole block, and introduce an IV for the block. So e.g. we would divide the file into blocks of 4096 - 32 bytes, add a 32 byte IV at the beginning of each block, and always read and write an entire block. We could use a mode with feedback within the block. We could also introduce a checksum if we wanted to. - What do other apps do in the same situation? What does TrueCrypt do? Does it address this issue? It doesn't have to deal with the filesystem issues but hardware remapping remains a threat, especially with modern flash? The first option is likely the easiest, of course. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20100729/0ef37b18/attachment.pgp>
