Torsten72 wrote: > the kernel prints these lines: > > loop: padlock hardware AES enabled > loop: AES key scrubbing enabled > loop: loaded (max 8 devices) Ok, it is properly detected. > But your padlock implementation obviously supports the new AES-256 mode > of the C7, doesn't it? If I remember correctly, VIA C3 (stepping 8) has a bug/flaw that prevents AES192 and AES256 hardware extended key generation, but that bug/flaw can be worked around by doing extended key generation using software. A bit in xcrypt instruction control word defines whether the instruction uses software precomputed extended key or whether it should do that key setup work at the time the instruction is executed. Precomputed extended key is of course faster because the xcrypt instruction can skip some time consuming work. loop-AES always uses software precomputed extended key, so that VIA C3 bug/flaw does not affect loop-AES in any way. Extended key precomputing is done only at losetup time, and does not affect run time performance. > Could loop-AES IV computation also be done in padlock and speed things up? VIA C3 does not have a instruction to do that. C7 specs I have not seen yet. If someone has distributable copy of VIA C7 programming specs, feel free to send a copy or download URL to me. -- Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/
