zuluCrypt and cryptsetup compatibility issue when creating plain dm-crypt volumes with keyfiles

[supermariomansmith]

https://github.com/mhogomchungu/zuluCrypt/blob/5b47f7c06126fc6f23e32a0bd2d45ec59fcfc797/zuluCrypt-cli/lib/open_plain.c#L155

Because zuluCrypt supplies the keyfile to cryptsetup API as a passphrase, it then generates a hash to be used as the key.

This is incompatible with the --key-file option of the cryptsetup utility because it will ignore --hash directive and use the binary data directly as the key.

I am not sure if this should be considered a significant issue, but it occurs to me that if for some reason a user could not use zuluCrypt then the data in their volume could then be made inaccessible when using cryptsetup if they used a keyfile.

A work-around solution to open such a zuluCrypt-created volume with cryptsetup is to pipe the keyfile into cryptsetup via stdin so that it treats it as a passphrase and hashes it. However, this is somewhat likely to fail, because cryptsetup will quit reading the keyfile as a passphrase once it encounters a newline character, which can prevent the entirety of the keyfile being hashed.

If on the other hand, a user had a plain dm-crypt volume created by cryptsetup and a keyfile, there is no way for them to open it in zuluCrypt.

I do not know what the best solution would be. Perhaps just adding an option to specify not to hash the keyfile, and having _open_plain() use activate_crypt_by_key() instead if that option is enabled.

[mhogomchungu]

Will look into adding an option and sorry for a late reply.

[mhogomchungu]

It took a while but this one is finally fixed.

1. When creating a new plain dm-crypt volume, zuluCrypt now does what cryptsetup does and does not set hash function.
2. When unlocking a plain dm-crypt volume, zuluCrypt first tries with hash function set and if that fails, it tries again without setting hash function.