> > Testing:
> > -----------
> > The code passed the kernel test module and passed automated tests on a
> > dm-crypt volume reading/writing large files with alternating modules ( c
> > / assembler ) and comparing results. It is also running on my workstation
> > for over a week now.
>
> It would be good if you could run some random input encrypt/decrypt tests
> comparing the C reference version with yours. We have had bad luck
> with assembler functions not quite implementing the same cipher
> in the past.
That's exactly what my skript did.
http://homepages.tu-darmstadt.de/~fritschi/twofish/test_twofish.sh
Be careful with this script. It formats the testpartition you specify. The
script assumes you have both modules (c and asm) compiled as modules.
It generates a 1Gb random file and a random passphrase. It copies the file on
your crypted partition with the c module and reads it again with the asm
module. Then it copies the file again onto the crypto partition with the asm
module and reads it with the c module. After each step the md5sum of the
files are compared with the original file. Then the script starts all over
again with a new random file and passphrase.
My modules also pass the tcrypt tests.
> > Please have a look, try, improve and criticise.
>
> Is it really needed to duplicate all the C code and tables - can't that
> be shared with the portable C code?
I really don't know. I'm quite a newbie when it comes to kernel programming.
Maybe there is a way, but my reference for this module was the aes assembler
code which duplicates everything as well. I assumed there is reason for this.
Maybe someone with a little more knowledge about the crypto-api / kernel
could pitch in here.
>
> Also don't make it a separate config - it should just be a replacement
> on x86-64.
There was a patch in 2.6.16:
-------------------------
commit c8a19c91b5b488fed8cce04200a84c6a35c0bf0c
Author: Herbert Xu <[email protected]>
Date: Sat Nov 5 18:06:26 2005 +1100
[CRYPTO] Allow AES C/ASM implementations to coexist
As the Crypto API now allows multiple implementations to be registered
for the same algorithm, we no longer have to play tricks with Kconfig
to select the right AES implementation.
This patch sets the driver name and priority for all the AES
implementations and removes the Kconfig conditions on the C implementation
for AES.
------------------------------
That's why i did it the same way.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
