Tags

, , , ,

Not to be confused with BeCrypt or the password hashing algorithm of a similar name. This is a different utility that I noticed in the Linux package repo that uses the Blowfish cipher for its file encryption and wipes the unencrypted data with three random bit passes. It got me wondering whether this method is more secure than doing the same with GPG’s implementation of AES and cleaning up the unencrypted files with BleachBit.

Blowfish is a symmetric encryption algorithm published by Schneier back in 1993 as a substitute for DES, before the Rijndael algorithm became the Advanced Encryption Standard choice, and before Schneier followed up with the Twofish algorithm.

Although a 446-bit key size might appear impressive, an algorithm’s security depends also on other factors. The main (and the only?) disadvantage of Blowfish is its 64-bit block size, making it potentially weaker against cryptanalysis when dealing with relatively large amounts of data – the danger lies in the probability of two ciphertext blocks being identical, which increases, of course, with the number of blocks – obviously there’d be more blocks in encrypted data of a given size if the block size is smaller. Such an attack was demonstrated quite recently (they call it ‘Sweet32’), but you’d expect this attack to be less practical than straight up bruteforcing anyway.

It turns out that key changes in Blowfish are computationally expensive, making the algorithm intrinsically resistant to bruteforce attacks. To quote Schneier’s 1993 paper, ‘[…] time-consuming subkey-generation process adds considerable complexity for a bruteforce attack. The subkeys are too long to be stored on a massive tape, so they would have to be generated by a brute-force cracking machine as required.‘ The paper mentions that 521 or 522 iterations are required to test a single key.
Multiply that delay by something like 2^112 (112 bits being the entropy value of a typical 14-character password). Probably up to 86 million years to bruteforce, if each iteration takes a nanosecond, unless my mathematics is way off. And that’s assuming the key is dependent on the password being used.

So, if I wanted to recover the unencrypted data, I’d focus my efforts on recovering the original unencrypted file, perhaps using foremost, Sleuthkit or EnCase.
Unlike GPG file encryption, bcrypt wipes the plaintext copy by overwriting the filespace with random bits. Compare this with encrypting a file with GPG and using BleachBit to overwrite the plaintext with 0 bytes. GPG can provide stronger file encryption, and BleachBit’s file shredding feature is (according to the developer’s docs) enough to make a file unrecoverable on a modern hard drive using software-based tools. It also renames the file then gives it a shorter name, just to mess up the file’s metadata before wiping. I’d like to do a comparison of BleachBit and bcrypt’s file shredding features for my next post, to see whether this is the case.

Advertisements