Sorry for repeating maybe, but i just joined mailing list and i did
not recieve any response.
I'm trying to write a driver for hardware accelerated aes-cbc crypting
device to use with ipsec. I have a geode-aes and I'm spying on it
trying to understand all the stuff needed to make it work.
Well, when I'm initializing the geode module, I'm sending some test vectors:
Key : 0xc286696d887c9aa0611bbb3e2025a
45a
IV : 0x562e17996d093d28ddb3ba695a2e6 f58
Plaintext : 0x000102030405060708090a0b0c0d0 e0f
101112131415161718191a1b1c1d1e1 f
Ciphertext expected:
d296cd94 c2cccf8a 3a863028 b5e1dc0a
7586602d 253cfff9 1b8266be a6d61ab1
expecting to see the cipher text on output. I,m just sending the
address of data stored on my local machine to src field on geode-aes
engine AES_SOURCEA_REG, and all the flags needed for CBC encryption,
it work
surely because obtained data is decrypted to the original plain text.
And i recieve this:
c1398353 61a38726 4db45c3f 513bc0cc
a1835114 42f2fdd0 86fc8bdc 5b3aeeef
Where is the problem?
Is the plaintext in ipsec not so "plain"? Is the kernel doing some
modifications on it while trabelling thru blkcipher_walkvirt &
friends?
What is the real interface between ipsec and algorithms?
Thanks in advance!
* Vasile Marii | 2008-04-02 09:46:42 [+0300]:
>Sorry for repeating maybe, but i just joined mailing list and i did
>not recieve any response.
Sorry for being busy. You can check archive to see whether your email
made it to the list or not.
Sebastian
@ Sebastian Siewior
>>I'm trying to write a driver for hardware accelerated aes-cbc crypting
>>device to use with ipsec. I have a geode-aes and I'm spying on it
>>trying to understand all the stuff needed to make it work.
>>Well, when I'm initializing the geode module, I'm sending some test
>>vectors:
>> Key : 0xc286696d887c9aa0611bbb3e2025a45a
>>IV : 0x562e17996d093d28ddb3ba695a2e6f58
>>Plaintext : 0x000102030405060708090a0b0c0d0e0f
> > 101112131415161718191a1b1c1d1e1f
>>Ciphertext expected:
> > d296cd94 c2cccf8a 3a863028 b5e1dc0a
>> 7586602d 253cfff9 1b8266be a6d61ab1
>>This looks like the test vector #2 for cbc enc.
>Are you using the in kernel module or your own?
>Which kernel version do you use?
it is the geode-aes driver from kernel 2.6.24.2 but modified, meaning
that on loading no algorithms are registred, just some data(hand
written) is put on input of geode-aes and some is taken out. Because
the results differ from test vectors, i concluded that some other
operations are made on data...before entering geode-aes.
>Try to run the tcrypt module for testing.
>modprobe tcrypt mode=10
>will test _all_ aes variants, you can ignore them all except the cbc
>part.
ok, i will install it and will watch.
>>Is the plaintext in ipsec not so "plain"? Is the kernel doing some
>>modifications on it while trabelling thru blkcipher_walkvirt &
>>friends?
>No. That one should only walk through the scatterlist and ensures
>alignment that is required.
>> What is the real interface between ipsec and algorithms?
>>Thanks in advance!
>Take a look on tcrypt.c. That one is pretty easy. ipsec uses the
>asynchronous interface.
OK i'll do this right now, but the next question is:
after all, in blockcipher mode, the src, and dst addresses filled by
blkcipher_walk... are the real plaintext source and destination? No
other operations are made on that data?
Thanks a lot for response.
>
>--
>Vasile Marii
Sebastian
* Vasile Marii | 2008-04-02 10:17:59 [+0300]:
>>Are you using the in kernel module or your own?
>>Which kernel version do you use?
>it is the geode-aes driver from kernel 2.6.24.2 but modified, meaning
That kernel should have a working version. So in theoory it should work
without your modifications.
>OK i'll do this right now, but the next question is:
>after all, in blockcipher mode, the src, and dst addresses filled by
>blkcipher_walk... are the real plaintext source and destination? No
>other operations are made on that data?
Yes. The data is not modified by the crypto stack. Dump the data on the
the entre of the function and you will see it. Keep in mind that it is a
kernel address and the geode expects a physical address.
>>--
>>Vasile Marii
>
Sebastian