[dm-crypt] iv generation from third-party code
fraser.scott at gmail.com
Thu May 7 10:12:42 CEST 2015
Thanks for taking the time to reply.
On 7 May 2015 at 07:40, Arno Wagner <arno at wagner.name> wrote:
> So the hardware assist sits in some USB bridge or the like?
Its an ARM based system-on-a-chip, specifically the Oxford Semiconductor
If you can, get the datasheet and hope it describes what it does...
There is a datasheet, but it is pretty useless. It has chip pins etc but
only mentions AES as a feature - no details.
Depends on how much time you want to invest. Afterwards you will
> know quite a bit about C programming. The dm-crypt/kernel part is
> less of a problem as you can use the module you have, you just
> need to replace all hardware crypto with equivalent software
> crypto. That may be anything from vwey easy to very hard. It gets
> harder, the less you know about the hardware crypto engine.
The thing you probably need to replace is
> As far as I can see, the source for that is missing.
> Probably in a driver for the "OX800 DPE core". Do you have
> that driver and its sources? Because it does not seem to
> be a part of the standard kernel. At least in 3.14.29, I
> find nothing. Of course you can try to replace it with
> a standard aes-lrw implementation and hope that it has
> that semantics and does nto require anything special and
> non-standard with its parameters.
The source for that lives in another file, also provided by WD.
I did some playing around in Ruby before getting further help from IRC. I
was able to decrypt the first 32 bytes in ECB mode using some counter mode
inspired IV tweaking. The first 16 bytes were decrypted using an IV of 0x0
and the next 16 bytes were decrypted using the unmodified user supplied IV.
After that it gets a bit funky, but I believe this matches up with what is
expected from LRW mode.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dm-crypt