ocf-linux-users Mailing List for Open Cryptographic Framework for Linux (Page 10)
Brought to you by:
david-m
Menu
▾
▴
ocf-linux-users — Anything and everything ocf-linux related
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(12) |
Sep
(39) |
Oct
(16) |
Nov
(7) |
Dec
(17) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
(10) |
Feb
(1) |
Mar
(18) |
Apr
(8) |
May
(14) |
Jun
(12) |
Jul
(35) |
Aug
(11) |
Sep
(3) |
Oct
(3) |
Nov
(7) |
Dec
(2) |
| 2009 |
Jan
(20) |
Feb
(12) |
Mar
(31) |
Apr
(20) |
May
(31) |
Jun
|
Jul
(2) |
Aug
(5) |
Sep
(11) |
Oct
|
Nov
(2) |
Dec
(6) |
| 2010 |
Jan
(20) |
Feb
(10) |
Mar
(16) |
Apr
|
May
(17) |
Jun
|
Jul
(2) |
Aug
(30) |
Sep
(6) |
Oct
|
Nov
|
Dec
(1) |
| 2011 |
Jan
|
Feb
(9) |
Mar
(7) |
Apr
(6) |
May
(20) |
Jun
(2) |
Jul
(13) |
Aug
(4) |
Sep
(7) |
Oct
(9) |
Nov
(5) |
Dec
(2) |
| 2012 |
Jan
(5) |
Feb
(2) |
Mar
|
Apr
(1) |
May
|
Jun
(7) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(8) |
Dec
(19) |
| 2013 |
Jan
(2) |
Feb
(3) |
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(8) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
(2) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
|
From: V Jyothi-B. <B2...@fr...> - 2010-03-19 12:47:25
|
Hi,
I am trying to use OCF openssl interface with openssl1.0beta versions
for DH operations.
This framework is very much useful to make use of HW acceleration
through openssl.
There are two minor issues we found in cryptodev_dh_compute_key()
function definition:
1) keylen assignment to crypt_kop structure:
keylen is computed using BN_num_bits() which returns the key size
in number of bits.
While assigning keylen to kop.crk_param[3].crp_nbits is again
multiplied by 8, which not required:
kop.crk_param[3].crp_nbits = keylen * 8;
keylen variable already containing the length of key in bits, so
this statement should be like:
kop.crk_param[3].crp_nbits = keylen; /* keylen is containing
the number of bits, so we should not again multiply with 8 */
2) In case of "ioctl(fd, CIOCKEY, &kop)" returning success, 'dhret'
value is not filled but the return value is expected by the caller as
the length of key in bytes:
"dhret = (keylen+7)/8;" statement may be required after ioctl
condition.
if (ioctl(fd, CIOCKEY, &kop) == -1) {
const DH_METHOD *meth = DH_OpenSSL();
dhret = (meth->compute_key)(key, pub_key, dh);
}
else
dhret = (keylen+7)/8;
I hope these issues get fixed in the next version.
Thanks
Jyothi
-----Original Message-----
From: ocf...@li...
[mailto:ocf...@li...]
Sent: Friday, March 19, 2010 5:50 PM
To: V Jyothi-B22245
Subject: confirm 1ef0c65cf0f2a60548df99b6c2c94792e0eb3850
Mailing list subscription confirmation notice for mailing list
Ocf-linux-users
We have received a request from 172.29.29.1 for subscription of your
email address, "jyo...@fr...", to the
ocf...@li... mailing list. To confirm that you
want to be added to this mailing list, simply reply to this message,
keeping the Subject: header intact. Or visit this web page:
https://lists.sourceforge.net/lists/confirm/ocf-linux-users/1ef0c65cf0f2
a60548df99b6c2c94792e0eb3850
Or include the following line -- and only the following line -- in a
message to ocf...@li...:
confirm 1ef0c65cf0f2a60548df99b6c2c94792e0eb3850
Note that simply sending a `reply' to this message should work from most
mail readers, since that usually leaves the Subject: line in the right
form (additional "Re:" text in the Subject: is okay).
If you do not wish to be subscribed to this list, please simply
disregard this message. If you think you are being maliciously
subscribed to the list, or have any other questions, send them to
ocf...@li....
|
|
From: David M. <dav...@mc...> - 2010-03-18 03:58:15
|
Jivin avital sela lays it down ... > Hello David, > > I am working on porting our custom AES and SHA drivers written for > native crypto to OCF. Cryptosoft can use those already. In fact, if you have async kernel api crypto, I now have a version of cryptosoft that can use those as well. I am about to do an OCF release with the updated cryptosoft that can use the kernels async cryptoapi code. > As a start I modified the cryptosoft driver by removing the > crypto_done call in case of HMAC/MAC and block cipher and replacing > the appropriate crypto op calls with ones that enqueue the requests > to the drivers. The drivers then from interrupt context call > crypto_done. I also changed the registration to Hardware. Using > crytotest I verifed that everything works fine (and produces pretty > good results as compared with SW only crypto). > > With this approach I was able to make use of all your existing > skbuff/uiov manipulation code which seems non trivial at all. > The one problem I see with this approach is that I won't be able to > make use of alg chaining which I will eventually need for ipsec. > Is my understanding on the trade off (using a lot of existing code > versus optimal performance) correct or am I missing something else? OCF does chaining, you have just based your driver on cryptosoft which currently doesn't. The safe/hifn/talitos/ixp and basically every other HW driver does to chaining on hmac/ciphers. > Is it possible that with very small buffers the hw processing , the > corrosponding interrupt and the call to crypto_done will complete > before the crypto_process routine returns? If that happens will that > be a problem? That won't be a problem, I have already seen that happen and the code is able to deal with it specifically. > As far as I could tell, there is no way to get the native kernel IPSEC > to call the OCF driver so I need to change to the KLIPS stack. Is this > true? Yes. The native stack can only use the native cryptoapi drivers. > With the current drivers I use setkey to manually setup a tunnel . > Will I still be able to do that with the KLIPS stack? No, you need to use the openswan tools, whican can also do netkey. So, if you can, use pluto and at a minimum whack to configure your tunnels. Using ipsec.conf is better though ;-) Cheers, Davidm -- David McCullough, dav...@mc..., Ph:+61 734352815 McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org |
|
From: David M. <dav...@mc...> - 2010-03-18 03:49:35
|
Jivin Kennedy, Brendan lays it down ...
> >-----Original Message-----
> >From: David McCullough [mailto:dav...@mc...]
> >> Would it be possible to include the updated code in your later
> >releases
> >> of OCF?
> >
> >Done, will be in the next release.
> >
>
> Brilliant, thanks Dave!
>
> >> There is a corresponding OpenSSL eng_cryptodev patch (third
> >attachment)
> >> if you want to check it out. This fixes some of the PKE ?? OCF calls.
> >
> >Ok, some questions for you on this one.
> >
> >For the change:
> >+ } else if (ECANCELED == kop.crk_status) {
> >
> >This changes the behaviour for other drivers (safe/ixp) that will fall
> >back
> >to software on an ERANGE/E2BIG or any other error.
> >
> >Did you just want to be able to identify the HW condition that causes
> >this separate to an error ?
>
> Yes, we wanted to identify that the call was failing because of lack of driver support rather than due to bad inputs or some such thing.
Ok, I backed out the change in cryptodev so that a fail is still a fail
at the syscall level, but we can detect this when the errno is the same
as the kop_status. Saves changes the driver API in any way which is kind of
nice to have.
Have a look at the attached patch and see if it does what you need, if so
then I'll commit that.
Thanks,
Davidm
--
David McCullough, dav...@mc..., Ph:+61 734352815
McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org
|
|
From: avital s. <avi...@gm...> - 2010-03-17 15:25:00
|
Hello David, I am working on porting our custom AES and SHA drivers written for native crypto to OCF. As a start I modified the cryptosoft driver by removing the crypto_done call in case of HMAC/MAC and block cipher and replacing the appropriate crypto op calls with ones that enqueue the requests to the drivers. The drivers then from interrupt context call crypto_done. I also changed the registration to Hardware. Using crytotest I verifed that everything works fine (and produces pretty good results as compared with SW only crypto). With this approach I was able to make use of all your existing skbuff/uiov manipulation code which seems non trivial at all. The one problem I see with this approach is that I won't be able to make use of alg chaining which I will eventually need for ipsec. Is my understanding on the trade off (using a lot of existing code versus optimal performance) correct or am I missing something else? Is it possible that with very small buffers the hw processing , the corrosponding interrupt and the call to crypto_done will complete before the crypto_process routine returns? If that happens will that be a problem? As far as I could tell, there is no way to get the native kernel IPSEC to call the OCF driver so I need to change to the KLIPS stack. Is this true? With the current drivers I use setkey to manually setup a tunnel . Will I still be able to do that with the KLIPS stack? Thanks a lot for your time. |
|
From: Kennedy, B. <bre...@in...> - 2010-03-10 15:55:06
|
>-----Original Message-----
>From: David McCullough [mailto:dav...@mc...]
>> Would it be possible to include the updated code in your later
>releases
>> of OCF?
>
>Done, will be in the next release.
>
Brilliant, thanks Dave!
>> There is a corresponding OpenSSL eng_cryptodev patch (third
>attachment)
>> if you want to check it out. This fixes some of the PKE ?? OCF calls.
>
>Ok, some questions for you on this one.
>
>For the change:
>+ } else if (ECANCELED == kop.crk_status) {
>
>This changes the behaviour for other drivers (safe/ixp) that will fall
>back
>to software on an ERANGE/E2BIG or any other error.
>
>Did you just want to be able to identify the HW condition that causes
>this separate to an error ?
Yes, we wanted to identify that the call was failing because of lack of driver support rather than due to bad inputs or some such thing.
> If so, then something like:
>
> } else if (kop.crk_status) {
>
>Should do. I don't think ECANCELED needs to be any different than any
>other
>driver error, but perhaps I am missing something.
>
>If this sounds ok I will fix up teh patch on the way in,
This works for us. I think we just didn't want to lose granularity if some unexpected error happened in our driver, but it should print to /var/log/messages in that case anyway.
Thanks,
Regards,
Brendan
--------------------------------------------------------------
Intel Shannon Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
Business address: Dromore House, East Park, Shannon, Co. Clare
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
|
|
From: David M. <dav...@mc...> - 2010-03-10 06:14:02
|
Jivin Kennedy, Brendan lays it down ...
> Hi Dave, All,
>
> Attached is an update to the EP80579 driver. It allows it to compile
> under FreeBSD Opencrypto framework and fixes a few bugs.
>
> Would it be possible to include the updated code in your later releases
> of OCF?
Done, will be in the next release.
> There??s also an update to cryptodev.c to allow a distinction between
> a process fail and algorithm fail. This helps DSA verify functionality
> when, for example, certain key sizes are not supported.
>
> There is a corresponding OpenSSL eng_cryptodev patch (third attachment)
> if you want to check it out. This fixes some of the PKE ?? OCF calls.
Ok, some questions for you on this one.
For the change:
- if (cryptodev_asym(&kop, BN_num_bytes(m), r, 0, NULL) == -1) {
+ if (cryptodev_asym(&kop, BN_num_bytes(m), r, 0, NULL)) {
+ printf("OCF asym process failed, Running in software\n");
+ const RSA_METHOD *meth = RSA_PKCS1_SSLeay();
+ ret = meth->bn_mod_exp(r, a, p, m, ctx, in_mont);
+
+ } else if (ECANCELED == kop.crk_status) {
+ printf("OCF hardware operation cancelled. Running in Software\n");
const RSA_METHOD *meth = RSA_PKCS1_SSLeay();
ret = meth->bn_mod_exp(r, a, p, m, ctx, in_mont);
}
+ /* else cryptodev operation worked ok ==> ret = 1*/
+
This changes the behaviour for other drivers (safe/ixp) that will fall back
to software on an ERANGE/E2BIG or any other error.
Did you just want to be able to identify the HW condition that causes this
separate to an error ? If so, then something like:
if (cryptodev_asym(&kop, BN_num_bytes(m), r, 0, NULL)) {
const RSA_METHOD *meth = RSA_PKCS1_SSLeay();
printf("OCF asym process failed, Running in software\n");
ret = meth->bn_mod_exp(r, a, p, m, ctx, in_mont);
} else if (kop.crk_status) {
const RSA_METHOD *meth = RSA_PKCS1_SSLeay();
printf("OCF hardware operation failed(%d). Running in Software\n",
kop.crk_status);
ret = meth->bn_mod_exp(r, a, p, m, ctx, in_mont);
}
/* else cryptodev operation worked ok ==> ret = 1*/
Should do. I don't think ECANCELED needs to be any different than any other
driver error, but perhaps I am missing something.
If this sounds ok I will fix up teh patch on the way in,
Cheers,
Davidm
--
David McCullough, dav...@mc..., Ph:+61 734352815
McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org
|
|
From: David M. <dav...@mc...> - 2010-03-10 00:21:47
|
Jivin hiren joshi lays it down ... > Hello, > > Applying the patch at > https://dev.openwrt.org/browser/trunk/target/linux/generic-2.6/patches-2.6.27/973-ocf_2.6.27_fix.patch?rev=13341 > fixes https://dev.openwrt.org/ticket/4184 > > Is the patch recommended? It looks ok, but I would probably just go with the simpler attached patch for now. crypto.c is already using this approach. Cheers, Davidm -- David McCullough, dav...@mc..., Ph:+61 734352815 McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org |
|
From: hiren j. <jos...@gm...> - 2010-03-09 15:47:26
|
Hello, Applying the patch at https://dev.openwrt.org/browser/trunk/target/linux/generic-2.6/patches-2.6.27/973-ocf_2.6.27_fix.patch?rev=13341 fixes https://dev.openwrt.org/ticket/4184 Is the patch recommended? Thanks for your time. Regards, Hiren |
|
From: David M. <dav...@mc...> - 2010-02-25 22:30:23
|
Jivin Kennedy, Brendan lays it down ... > Hi Dave, > > We did have a few issues with the OpenSSL patch when --cryptodev-digests was enabled. It may be fixed now, but we saw issues with RSA functionality and also performance issues to do with OCF being used for every single digest request... Thats to be expected really, --cryptodev-digests shuld really only be enabled if you know you need it. The cost of the user/kernel/user overhead for a digest operation is usually to hight to warrant its use, Cheers, David > > Regards, > Brendan > > -----Original Message----- > From: David McCullough [mailto:dav...@mc...] > Sent: Thursday, February 25, 2010 1:14 AM > To: Kennedy, Brendan > Cc: ocf...@li... > Subject: Re: [Ocf-linux-users] [PATCH - EP80579 driver update patch] > > > Jivin Kennedy, Brendan lays it down ... > > Hi Dave, > > > > Thanks, that's great :) Sorry to hear about the crash! > > That life. > > > I saw those updates to OpenSSL, it's great they were included. > > Yeah, they do need a re-check though and I haven't got around to > that yet, > > Cheers, > Davidm > > > -----Original Message----- > > From: David McCullough [mailto:dav...@mc...] > > Sent: Tuesday, February 23, 2010 11:29 PM > > To: Kennedy, Brendan > > Cc: ocf...@li... > > Subject: Re: [Ocf-linux-users] [PATCH - EP80579 driver update patch] > > > > > > Jivin Kennedy, Brendan lays it down ... > > > Hi Dave, All, > > > > > > > > > > > > Attached is an update to the EP80579 driver. It allows it to compile under FreeBSD Opencrypto framework and fixes a few bugs. > > > > > > Would it be possible to include the updated code in your later releases of OCF? > > > > I'll do my best to get it in. > > > > > There??s also an update to cryptodev.c to allow a distinction between a process fail and algorithm fail. This helps DSA verify functionality when, for example, certain key sizes are not supported. > > > > Sounds fair. > > > > > There is a corresponding OpenSSL eng_cryptodev patch (third attachment) if you want to check it out. This fixes some of the PKE ?? OCF calls. > > > > > > I??ll be sending it to the OpenSSL dev team soon enough, but I think they??ll need OCF or Opencrypto team to work with them when doing the updates. > > > > No problems. I haven't looked at the patch yet but I will soon. I am sort of > > half out of action at the moment. Just had a bad crash while cycling and so > > my hours and typing speed are way down :-( Hopefully back on top of it soon :-) > > > > A lot of the OCF patch to opnssl has been included in 1.0 IIRC, so that > > should help, > > > > Cheers, > > Davidm > > > > > > -- > > David McCullough, dav...@mc..., Ph:+61 734352815 > > McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org > > -------------------------------------------------------------- > > Intel Shannon Limited > > Registered in Ireland > > Registered Office: Collinstown Industrial Park, Leixlip, County Kildare > > Registered Number: 308263 > > Business address: Dromore House, East Park, Shannon, Co. Clare > > > > This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. > > > > > > > > -- > David McCullough, dav...@mc..., Ph:+61 734352815 > McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org > -------------------------------------------------------------- > Intel Shannon Limited > Registered in Ireland > Registered Office: Collinstown Industrial Park, Leixlip, County Kildare > Registered Number: 308263 > Business address: Dromore House, East Park, Shannon, Co. Clare > > This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. > > > -- David McCullough, dav...@mc..., Ph:+61 734352815 McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org |
|
From: Kennedy, B. <bre...@in...> - 2010-02-25 12:52:33
|
Hi Dave, We did have a few issues with the OpenSSL patch when --cryptodev-digests was enabled. It may be fixed now, but we saw issues with RSA functionality and also performance issues to do with OCF being used for every single digest request... Regards, Brendan -----Original Message----- From: David McCullough [mailto:dav...@mc...] Sent: Thursday, February 25, 2010 1:14 AM To: Kennedy, Brendan Cc: ocf...@li... Subject: Re: [Ocf-linux-users] [PATCH - EP80579 driver update patch] Jivin Kennedy, Brendan lays it down ... > Hi Dave, > > Thanks, that's great :) Sorry to hear about the crash! That life. > I saw those updates to OpenSSL, it's great they were included. Yeah, they do need a re-check though and I haven't got around to that yet, Cheers, Davidm > -----Original Message----- > From: David McCullough [mailto:dav...@mc...] > Sent: Tuesday, February 23, 2010 11:29 PM > To: Kennedy, Brendan > Cc: ocf...@li... > Subject: Re: [Ocf-linux-users] [PATCH - EP80579 driver update patch] > > > Jivin Kennedy, Brendan lays it down ... > > Hi Dave, All, > > > > > > > > Attached is an update to the EP80579 driver. It allows it to compile under FreeBSD Opencrypto framework and fixes a few bugs. > > > > Would it be possible to include the updated code in your later releases of OCF? > > I'll do my best to get it in. > > > There??s also an update to cryptodev.c to allow a distinction between a process fail and algorithm fail. This helps DSA verify functionality when, for example, certain key sizes are not supported. > > Sounds fair. > > > There is a corresponding OpenSSL eng_cryptodev patch (third attachment) if you want to check it out. This fixes some of the PKE ?? OCF calls. > > > > I??ll be sending it to the OpenSSL dev team soon enough, but I think they??ll need OCF or Opencrypto team to work with them when doing the updates. > > No problems. I haven't looked at the patch yet but I will soon. I am sort of > half out of action at the moment. Just had a bad crash while cycling and so > my hours and typing speed are way down :-( Hopefully back on top of it soon :-) > > A lot of the OCF patch to opnssl has been included in 1.0 IIRC, so that > should help, > > Cheers, > Davidm > > > -- > David McCullough, dav...@mc..., Ph:+61 734352815 > McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org > -------------------------------------------------------------- > Intel Shannon Limited > Registered in Ireland > Registered Office: Collinstown Industrial Park, Leixlip, County Kildare > Registered Number: 308263 > Business address: Dromore House, East Park, Shannon, Co. Clare > > This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. > > > -- David McCullough, dav...@mc..., Ph:+61 734352815 McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org -------------------------------------------------------------- Intel Shannon Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 Business address: Dromore House, East Park, Shannon, Co. Clare This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. |
|
From: David M. <dav...@mc...> - 2010-02-25 01:12:08
|
Jivin Kennedy, Brendan lays it down ... > Hi Dave, > > Thanks, that's great :) Sorry to hear about the crash! That life. > I saw those updates to OpenSSL, it's great they were included. Yeah, they do need a re-check though and I haven't got around to that yet, Cheers, Davidm > -----Original Message----- > From: David McCullough [mailto:dav...@mc...] > Sent: Tuesday, February 23, 2010 11:29 PM > To: Kennedy, Brendan > Cc: ocf...@li... > Subject: Re: [Ocf-linux-users] [PATCH - EP80579 driver update patch] > > > Jivin Kennedy, Brendan lays it down ... > > Hi Dave, All, > > > > > > > > Attached is an update to the EP80579 driver. It allows it to compile under FreeBSD Opencrypto framework and fixes a few bugs. > > > > Would it be possible to include the updated code in your later releases of OCF? > > I'll do my best to get it in. > > > There??s also an update to cryptodev.c to allow a distinction between a process fail and algorithm fail. This helps DSA verify functionality when, for example, certain key sizes are not supported. > > Sounds fair. > > > There is a corresponding OpenSSL eng_cryptodev patch (third attachment) if you want to check it out. This fixes some of the PKE ?? OCF calls. > > > > I??ll be sending it to the OpenSSL dev team soon enough, but I think they??ll need OCF or Opencrypto team to work with them when doing the updates. > > No problems. I haven't looked at the patch yet but I will soon. I am sort of > half out of action at the moment. Just had a bad crash while cycling and so > my hours and typing speed are way down :-( Hopefully back on top of it soon :-) > > A lot of the OCF patch to opnssl has been included in 1.0 IIRC, so that > should help, > > Cheers, > Davidm > > > -- > David McCullough, dav...@mc..., Ph:+61 734352815 > McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org > -------------------------------------------------------------- > Intel Shannon Limited > Registered in Ireland > Registered Office: Collinstown Industrial Park, Leixlip, County Kildare > Registered Number: 308263 > Business address: Dromore House, East Park, Shannon, Co. Clare > > This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. > > > -- David McCullough, dav...@mc..., Ph:+61 734352815 McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org |
|
From: Kennedy, B. <bre...@in...> - 2010-02-24 16:31:05
|
Hi Dave, Thanks, that's great :) Sorry to hear about the crash! I saw those updates to OpenSSL, it's great they were included. Take care, Brendan -----Original Message----- From: David McCullough [mailto:dav...@mc...] Sent: Tuesday, February 23, 2010 11:29 PM To: Kennedy, Brendan Cc: ocf...@li... Subject: Re: [Ocf-linux-users] [PATCH - EP80579 driver update patch] Jivin Kennedy, Brendan lays it down ... > Hi Dave, All, > > > > Attached is an update to the EP80579 driver. It allows it to compile under FreeBSD Opencrypto framework and fixes a few bugs. > > Would it be possible to include the updated code in your later releases of OCF? I'll do my best to get it in. > There??s also an update to cryptodev.c to allow a distinction between a process fail and algorithm fail. This helps DSA verify functionality when, for example, certain key sizes are not supported. Sounds fair. > There is a corresponding OpenSSL eng_cryptodev patch (third attachment) if you want to check it out. This fixes some of the PKE ?? OCF calls. > > I??ll be sending it to the OpenSSL dev team soon enough, but I think they??ll need OCF or Opencrypto team to work with them when doing the updates. No problems. I haven't looked at the patch yet but I will soon. I am sort of half out of action at the moment. Just had a bad crash while cycling and so my hours and typing speed are way down :-( Hopefully back on top of it soon :-) A lot of the OCF patch to opnssl has been included in 1.0 IIRC, so that should help, Cheers, Davidm -- David McCullough, dav...@mc..., Ph:+61 734352815 McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org -------------------------------------------------------------- Intel Shannon Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 Business address: Dromore House, East Park, Shannon, Co. Clare This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. |
|
From: Chia-Chih Wu <wuc...@gm...> - 2010-02-24 02:33:18
|
Hi there,
I have a question about the condition of wait_event_interruptible() in
crypto_proc().
The condition in 2009-09-01 release is:
10507 + wait_event_interruptible(cryptoproc_wait,
10508 + !(list_empty(&crp_q) || crypto_all_qblocked) ||
10509 + !(list_empty(&crp_kq) || crypto_all_kqblocked) ||
10510 + cryptoproc == (pid_t) -1);
crypto_all_qblocked is a global integer which has the value of
!list_empty(&crp_q). It would not be modified during the sleeping period of
crypto_proc(). If crypto_all_qblocked is true (e.g. crp_q is not empty but
no driver is available) and no more operations go into crypto_dispatch(),
the condition will be always false. Who can awake crypto_proc() kernel
thread in this case?
- ccwu
|
|
From: David M. <dav...@mc...> - 2010-02-23 23:28:11
|
Jivin Kennedy, Brendan lays it down ... > Hi Dave, All, > > > > Attached is an update to the EP80579 driver. It allows it to compile under FreeBSD Opencrypto framework and fixes a few bugs. > > Would it be possible to include the updated code in your later releases of OCF? I'll do my best to get it in. > There??s also an update to cryptodev.c to allow a distinction between a process fail and algorithm fail. This helps DSA verify functionality when, for example, certain key sizes are not supported. Sounds fair. > There is a corresponding OpenSSL eng_cryptodev patch (third attachment) if you want to check it out. This fixes some of the PKE ?? OCF calls. > > I??ll be sending it to the OpenSSL dev team soon enough, but I think they??ll need OCF or Opencrypto team to work with them when doing the updates. No problems. I haven't looked at the patch yet but I will soon. I am sort of half out of action at the moment. Just had a bad crash while cycling and so my hours and typing speed are way down :-( Hopefully back on top of it soon :-) A lot of the OCF patch to opnssl has been included in 1.0 IIRC, so that should help, Cheers, Davidm -- David McCullough, dav...@mc..., Ph:+61 734352815 McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org |
|
From: David M. <dav...@mc...> - 2010-02-10 22:37:38
|
Jivin hiren joshi lays it down ... > Hello, > > I have a question related to Openswan-2.6.24 KLIPS. > While calling crypto_dispatch from ipsec_ocf_rcv, do authentication > and decryption operations clubbed together? > Authentication check and decryption is done in one shot or separately? Each ocf session is setup with the auth/enc paramaters. The OCF crypto drivers then process that the best they can. Currently all the HW drivers do it in a single operation while the software crypto driver "cryptosoft" does it individually. The best place to look is in ipsec_ocf.c in ipsec_ocf_sa_init you will see how it sets up a single session with auth, auth/enc or just enc. Cheers, Davidm -- David McCullough, dav...@mc..., Ph:+61 734352815 McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org |
|
From: hiren j. <jos...@gm...> - 2010-02-10 15:52:34
|
Hello, I have a question related to Openswan-2.6.24 KLIPS. While calling crypto_dispatch from ipsec_ocf_rcv, do authentication and decryption operations clubbed together? Authentication check and decryption is done in one shot or separately? Thanks for your time. Hiren |
|
From: Gokhale, G. <Gan...@ls...> - 2010-02-05 05:08:38
|
Hi David, Another piece I could not find in the OCF is the support for extended sequence numbers (64 bit sequence numbers). If the SA has extended sequence number enabled then the OCF has to pass the high order word to the driver in the cryptodev_process call. The crypto algorithm has to use the high order word of sequence number while computing the authentication data. The high order word of sequence number won't go in the packet data as it is not transmitted out. Hence, we need to extend the crptdesc struct for the high order word of sequence number. Do you agree? Thanks and regards, Gandhar Gokhale -----Original Message----- From: David McCullough [mailto:Dav...@se...] Sent: Monday, 01 February, 2010 5:28 AM To: Gokhale, Gandhar Cc: ocf...@li... Subject: Re: [Ocf-linux-users] AEAD support in OCF Jivin Gokhale, Gandhar lays it down ... > Hi David, > > I do agree that Linux is giving async crypto support for many algorithms including aead ones. However, for hardware accelerator the advantage that OCF brings in is that of portability. We expect to easily port the same driver to other platforms ones we have it working for one platform, Linux in this particular case. So, I believe it'll be a good idea to keep the OCF in sync with the newer developments in the crypto world. Thats is fine, just wanted to ensure you had thought about it :-) > I'll make a proper proposal in the coming week to you about the modifications we would need in the data structures. Let's take it forward from there. Does it sound good? No problems. I will try and put up a newer versions with support for later kernels etc in the meantime. Cheers, Davidm > -----Original Message----- > From: David McCullough [mailto:Dav...@se...] > Sent: Friday, 29 January, 2010 7:46 PM > To: Gokhale, Gandhar > Cc: ocf...@li... > Subject: Re: [Ocf-linux-users] AEAD support in OCF > > > Jivin Gokhale, Gandhar lays it down ... > > Hi David, > > Thanks for pointing out aead-aes-cbc-hmac-sha. However, I could not get a ratified standard for this. I could get only an expired draft of this. So, this may not be the perfect example to look at. However, it'll be great if you could point me to an example OCF driver that has a support for aead-aes-cbc-hmac-sha. > > I see that we need to have a few more fields (maybe union) in the cryptoini and/or cryptodesc structure to support the AAD, the nonce or maybe IV and salt separately. This will be needed even in case of aead-aes-cbc-hmac-sha. Details need to be finalized after carefully looking into all the AEAD algorithms available so far. If there is an existing aead-aes-cbc-hmac-sha OCF driver we can see how it uses the data structures as an example. > > > Currently, one way to do a combination of aes-cbc/hmac-sha the process > is something like this (in kernel) error checking removed ;-): > > init: > struct cryptoini alg[2]; > > alg[0].cri_alg = CRYPTO_AES_CBC; > alg[0].cri_klen = aes key length in bits; > alg[0].cri_key = ptr to aes key data; > alg[0].cri_next = &alg[1]; > > alg[1].cri_alg = CRYPTO_SHA1_HMAC; > alg[1].cri_klen = sha1 key length in bits; > alg[1].cri_key = ptr to sha1 key data; > alg[1].cri_mlen = result len (ie., 12 for ipsec, 20 for normal sha) > > err= crypto_newsession(&cryptoid, &alg[0], CRYPTOCAP_F_HARDWARE) > > encrypt some data: > > struct cryptop *crp; > struct cryptodesc *crd[2]; > > crp = crypto_getreq(2); > crd[0] = crp->crp_desc; > crd[1] = crd[0]->crd_next; > > crd[0]->crd_alg = CRYPTO_SHA1_HMAC; > crd[0]->crd_key = sha key pointer; > crd[0]->crd_klen = sha key len in bits; > crd[0]->crd_inject = offset in buffer for sha result > crd[0]->crd_mlen = size of result > crd[0]->crd_skip = start hashing this far into buffer; > crd[0]->crd_len = length of input buffer for SHA > > crd[1]->crd_alg = CRYPTO_AES_CBC; > crd[1]->crd_key = aes key pointer; > crd[1]->crd_klen = aes key len in bits; > crd[1]->crd_inject = offset in buffer to write the IV when done > crd[1]->crd_skip = start cipher this far into buffer; > crd[1]->crd_len = length of input buffer for AES > > crp->crp_ilen = total length of input buffer > crp->crp_flags = CRYPTO_F_* flags (ie SKB/IOV etc); > crp->crp_buf = pointer to buf/iov/skb > crp->crp_callback = function to call when done > crp->crp_sid = cryptoid from newsession; > crp->crp_opaque = arg to pass back to callback > > crypto_dispatch(crp) > > Hope that helps describe how it's current chained together a little. > > > How do you suggest we go about this? > > First we need to work out what is missing from the current API that you will > need and then we can decide on how to incorporate it. > > Also, have you looked at the latest crypto API in the linux kernel. > It supports a lot of alg's and combinations. The doco can be a bit poor but > it may already be capable of what you want. There is also support for async > HW crypto now. While I am more than happy to have people improve OCF it > wouldn't be fair to leave out the kernel API as there is a lot of work going > on there and it's part of the kernel, something OCF will never be ;-) > > Cheers, > Davidm > > > -----Original Message----- > > From: David McCullough [mailto:Dav...@se...] > > Sent: Friday, 29 January, 2010 6:18 PM > > To: Gokhale, Gandhar > > Cc: ocf...@li... > > Subject: Re: [Ocf-linux-users] AEAD support in OCF > > > > > > Jivin Gokhale, Gandhar lays it down ... > > > Hi David, > > > Thanks for your reply. I may be missing something here. > > > > > > As per my understanding what the AEAD mode algorithms typically need in input is: key, nonce, payload and AAD (Additional Authentication Data). Of these, nonce and AAD are very much algorithm dependent (as specified in respective RFCs. E.g. http://tools.ietf.org/html/rfc4106 and http://tools.ietf.org/html/rfc4309). The cryptodesc or cryptoini structures don't appear to have fields that could hold all these values. Are any of the existing fields being overloaded to be used for this? None of the drivers included in the code (ocf-linux-20090901) have any of the AEAD algorithms supported. Further, I don't see the #define values for any AEAD algorithms in the CRYPTO_* list in the cryptodev.h file. I'd would expect something like #define CRYPTO_RIJNDAEL128_GCM 26 > > > #define CRYPTO_RIJNDAEL128_CCM 26 etc. > > > However, I don't find them there. > > > > > > Am I looking at wrong code? > > > > I was under the impression that AEAD was a term used to refer to hash/cipher > > combinations. Perhaps I have that wrong :-( > > > > Plenty of the drivers do AES/DES+MD5/SHA. In other words something like: > > > > aead-aes-cbc-hmac-sha > > > > but you are right, none of them do CCM/GCM or counter modes. Do you need > > more inputs to the algs than aead-aes-cbc-hmac-sha would require ? > > OCF allows for each cipher/hash in a session to have it's own keys, iv's etc. > > If that is enough then you probably just need to add the ciphers/auth algs > > you want to the headers and implement them in your driver. > > > > Cheers, > > Davidm > > > > > > > -----Original Message----- > > > From: David McCullough [mailto:Dav...@se...] > > > Sent: Friday, 29 January, 2010 4:59 PM > > > To: Gokhale, Gandhar > > > Cc: ocf...@li... > > > Subject: Re: [Ocf-linux-users] AEAD support in OCF > > > > > > > > > Jivin Gokhale, Gandhar lays it down ... > > > > Hi, > > > > > > > > I??m working on designing an OCF driver to be used by Linux IPsec stack. I??m trying to gather information about how ??aead?? (Authenticated Encryption with Associate Data) type of algorithms can be supported with OCF. I searched this mailing list but could not get any discussion on this particular topic. Have any aead algorithms been supported via OCF? If yes, is there any resource that discusses the details of the same? Any help is highly appreciated. > > > > > > OCF has always been able to do AEAD. > > > > > > Not sure if it's documented specifically. The OCF design paper discusses > > > alg chaining (AEAD wasn't the term back then ;-) > > > > > > http://openbsd.org/papers/ocf.pdf > > > > > > Almost all the existing drivers implement it and openswan ipsec_ocf.c > > > gives you a fairly easy to follow example of how to use it. > > > > > > If you need more info feel free to ask at any time, > > > > > > Cheers, > > > Davidm > > > > > > -- > > > David McCullough, dav...@se..., Ph:+61 734352815 > > > McAfee - SnapGear http://www.snapgear.com http://www.uCdot.org > > > > > > > > > > -- > > David McCullough, dav...@se..., Ph:+61 734352815 > > McAfee - SnapGear http://www.snapgear.com http://www.uCdot.org > > > > > > -- > David McCullough, dav...@se..., Ph:+61 734352815 > McAfee - SnapGear http://www.snapgear.com http://www.uCdot.org > > -- David McCullough, dav...@se..., Ph:+61 734352815 McAfee - SnapGear http://www.snapgear.com http://www.uCdot.org |
|
From: David M. <Dav...@se...> - 2010-01-31 23:58:18
|
Jivin Gokhale, Gandhar lays it down ... > Hi David, > > I do agree that Linux is giving async crypto support for many algorithms including aead ones. However, for hardware accelerator the advantage that OCF brings in is that of portability. We expect to easily port the same driver to other platforms ones we have it working for one platform, Linux in this particular case. So, I believe it'll be a good idea to keep the OCF in sync with the newer developments in the crypto world. Thats is fine, just wanted to ensure you had thought about it :-) > I'll make a proper proposal in the coming week to you about the modifications we would need in the data structures. Let's take it forward from there. Does it sound good? No problems. I will try and put up a newer versions with support for later kernels etc in the meantime. Cheers, Davidm > -----Original Message----- > From: David McCullough [mailto:Dav...@se...] > Sent: Friday, 29 January, 2010 7:46 PM > To: Gokhale, Gandhar > Cc: ocf...@li... > Subject: Re: [Ocf-linux-users] AEAD support in OCF > > > Jivin Gokhale, Gandhar lays it down ... > > Hi David, > > Thanks for pointing out aead-aes-cbc-hmac-sha. However, I could not get a ratified standard for this. I could get only an expired draft of this. So, this may not be the perfect example to look at. However, it'll be great if you could point me to an example OCF driver that has a support for aead-aes-cbc-hmac-sha. > > I see that we need to have a few more fields (maybe union) in the cryptoini and/or cryptodesc structure to support the AAD, the nonce or maybe IV and salt separately. This will be needed even in case of aead-aes-cbc-hmac-sha. Details need to be finalized after carefully looking into all the AEAD algorithms available so far. If there is an existing aead-aes-cbc-hmac-sha OCF driver we can see how it uses the data structures as an example. > > > Currently, one way to do a combination of aes-cbc/hmac-sha the process > is something like this (in kernel) error checking removed ;-): > > init: > struct cryptoini alg[2]; > > alg[0].cri_alg = CRYPTO_AES_CBC; > alg[0].cri_klen = aes key length in bits; > alg[0].cri_key = ptr to aes key data; > alg[0].cri_next = &alg[1]; > > alg[1].cri_alg = CRYPTO_SHA1_HMAC; > alg[1].cri_klen = sha1 key length in bits; > alg[1].cri_key = ptr to sha1 key data; > alg[1].cri_mlen = result len (ie., 12 for ipsec, 20 for normal sha) > > err= crypto_newsession(&cryptoid, &alg[0], CRYPTOCAP_F_HARDWARE) > > encrypt some data: > > struct cryptop *crp; > struct cryptodesc *crd[2]; > > crp = crypto_getreq(2); > crd[0] = crp->crp_desc; > crd[1] = crd[0]->crd_next; > > crd[0]->crd_alg = CRYPTO_SHA1_HMAC; > crd[0]->crd_key = sha key pointer; > crd[0]->crd_klen = sha key len in bits; > crd[0]->crd_inject = offset in buffer for sha result > crd[0]->crd_mlen = size of result > crd[0]->crd_skip = start hashing this far into buffer; > crd[0]->crd_len = length of input buffer for SHA > > crd[1]->crd_alg = CRYPTO_AES_CBC; > crd[1]->crd_key = aes key pointer; > crd[1]->crd_klen = aes key len in bits; > crd[1]->crd_inject = offset in buffer to write the IV when done > crd[1]->crd_skip = start cipher this far into buffer; > crd[1]->crd_len = length of input buffer for AES > > crp->crp_ilen = total length of input buffer > crp->crp_flags = CRYPTO_F_* flags (ie SKB/IOV etc); > crp->crp_buf = pointer to buf/iov/skb > crp->crp_callback = function to call when done > crp->crp_sid = cryptoid from newsession; > crp->crp_opaque = arg to pass back to callback > > crypto_dispatch(crp) > > Hope that helps describe how it's current chained together a little. > > > How do you suggest we go about this? > > First we need to work out what is missing from the current API that you will > need and then we can decide on how to incorporate it. > > Also, have you looked at the latest crypto API in the linux kernel. > It supports a lot of alg's and combinations. The doco can be a bit poor but > it may already be capable of what you want. There is also support for async > HW crypto now. While I am more than happy to have people improve OCF it > wouldn't be fair to leave out the kernel API as there is a lot of work going > on there and it's part of the kernel, something OCF will never be ;-) > > Cheers, > Davidm > > > -----Original Message----- > > From: David McCullough [mailto:Dav...@se...] > > Sent: Friday, 29 January, 2010 6:18 PM > > To: Gokhale, Gandhar > > Cc: ocf...@li... > > Subject: Re: [Ocf-linux-users] AEAD support in OCF > > > > > > Jivin Gokhale, Gandhar lays it down ... > > > Hi David, > > > Thanks for your reply. I may be missing something here. > > > > > > As per my understanding what the AEAD mode algorithms typically need in input is: key, nonce, payload and AAD (Additional Authentication Data). Of these, nonce and AAD are very much algorithm dependent (as specified in respective RFCs. E.g. http://tools.ietf.org/html/rfc4106 and http://tools.ietf.org/html/rfc4309). The cryptodesc or cryptoini structures don't appear to have fields that could hold all these values. Are any of the existing fields being overloaded to be used for this? None of the drivers included in the code (ocf-linux-20090901) have any of the AEAD algorithms supported. Further, I don't see the #define values for any AEAD algorithms in the CRYPTO_* list in the cryptodev.h file. I'd would expect something like #define CRYPTO_RIJNDAEL128_GCM 26 > > > #define CRYPTO_RIJNDAEL128_CCM 26 etc. > > > However, I don't find them there. > > > > > > Am I looking at wrong code? > > > > I was under the impression that AEAD was a term used to refer to hash/cipher > > combinations. Perhaps I have that wrong :-( > > > > Plenty of the drivers do AES/DES+MD5/SHA. In other words something like: > > > > aead-aes-cbc-hmac-sha > > > > but you are right, none of them do CCM/GCM or counter modes. Do you need > > more inputs to the algs than aead-aes-cbc-hmac-sha would require ? > > OCF allows for each cipher/hash in a session to have it's own keys, iv's etc. > > If that is enough then you probably just need to add the ciphers/auth algs > > you want to the headers and implement them in your driver. > > > > Cheers, > > Davidm > > > > > > > -----Original Message----- > > > From: David McCullough [mailto:Dav...@se...] > > > Sent: Friday, 29 January, 2010 4:59 PM > > > To: Gokhale, Gandhar > > > Cc: ocf...@li... > > > Subject: Re: [Ocf-linux-users] AEAD support in OCF > > > > > > > > > Jivin Gokhale, Gandhar lays it down ... > > > > Hi, > > > > > > > > I??m working on designing an OCF driver to be used by Linux IPsec stack. I??m trying to gather information about how ??aead?? (Authenticated Encryption with Associate Data) type of algorithms can be supported with OCF. I searched this mailing list but could not get any discussion on this particular topic. Have any aead algorithms been supported via OCF? If yes, is there any resource that discusses the details of the same? Any help is highly appreciated. > > > > > > OCF has always been able to do AEAD. > > > > > > Not sure if it's documented specifically. The OCF design paper discusses > > > alg chaining (AEAD wasn't the term back then ;-) > > > > > > http://openbsd.org/papers/ocf.pdf > > > > > > Almost all the existing drivers implement it and openswan ipsec_ocf.c > > > gives you a fairly easy to follow example of how to use it. > > > > > > If you need more info feel free to ask at any time, > > > > > > Cheers, > > > Davidm > > > > > > -- > > > David McCullough, dav...@se..., Ph:+61 734352815 > > > McAfee - SnapGear http://www.snapgear.com http://www.uCdot.org > > > > > > > > > > -- > > David McCullough, dav...@se..., Ph:+61 734352815 > > McAfee - SnapGear http://www.snapgear.com http://www.uCdot.org > > > > > > -- > David McCullough, dav...@se..., Ph:+61 734352815 > McAfee - SnapGear http://www.snapgear.com http://www.uCdot.org > > -- David McCullough, dav...@se..., Ph:+61 734352815 McAfee - SnapGear http://www.snapgear.com http://www.uCdot.org |
|
From: Gokhale, G. <Gan...@ls...> - 2010-01-30 18:25:48
|
Hi David, I do agree that Linux is giving async crypto support for many algorithms including aead ones. However, for hardware accelerator the advantage that OCF brings in is that of portability. We expect to easily port the same driver to other platforms ones we have it working for one platform, Linux in this particular case. So, I believe it'll be a good idea to keep the OCF in sync with the newer developments in the crypto world. I'll make a proper proposal in the coming week to you about the modifications we would need in the data structures. Let's take it forward from there. Does it sound good? Thanks and regards, Gandhar Gokhale -----Original Message----- From: David McCullough [mailto:Dav...@se...] Sent: Friday, 29 January, 2010 7:46 PM To: Gokhale, Gandhar Cc: ocf...@li... Subject: Re: [Ocf-linux-users] AEAD support in OCF Jivin Gokhale, Gandhar lays it down ... > Hi David, > Thanks for pointing out aead-aes-cbc-hmac-sha. However, I could not get a ratified standard for this. I could get only an expired draft of this. So, this may not be the perfect example to look at. However, it'll be great if you could point me to an example OCF driver that has a support for aead-aes-cbc-hmac-sha. > I see that we need to have a few more fields (maybe union) in the cryptoini and/or cryptodesc structure to support the AAD, the nonce or maybe IV and salt separately. This will be needed even in case of aead-aes-cbc-hmac-sha. Details need to be finalized after carefully looking into all the AEAD algorithms available so far. If there is an existing aead-aes-cbc-hmac-sha OCF driver we can see how it uses the data structures as an example. Currently, one way to do a combination of aes-cbc/hmac-sha the process is something like this (in kernel) error checking removed ;-): init: struct cryptoini alg[2]; alg[0].cri_alg = CRYPTO_AES_CBC; alg[0].cri_klen = aes key length in bits; alg[0].cri_key = ptr to aes key data; alg[0].cri_next = &alg[1]; alg[1].cri_alg = CRYPTO_SHA1_HMAC; alg[1].cri_klen = sha1 key length in bits; alg[1].cri_key = ptr to sha1 key data; alg[1].cri_mlen = result len (ie., 12 for ipsec, 20 for normal sha) err= crypto_newsession(&cryptoid, &alg[0], CRYPTOCAP_F_HARDWARE) encrypt some data: struct cryptop *crp; struct cryptodesc *crd[2]; crp = crypto_getreq(2); crd[0] = crp->crp_desc; crd[1] = crd[0]->crd_next; crd[0]->crd_alg = CRYPTO_SHA1_HMAC; crd[0]->crd_key = sha key pointer; crd[0]->crd_klen = sha key len in bits; crd[0]->crd_inject = offset in buffer for sha result crd[0]->crd_mlen = size of result crd[0]->crd_skip = start hashing this far into buffer; crd[0]->crd_len = length of input buffer for SHA crd[1]->crd_alg = CRYPTO_AES_CBC; crd[1]->crd_key = aes key pointer; crd[1]->crd_klen = aes key len in bits; crd[1]->crd_inject = offset in buffer to write the IV when done crd[1]->crd_skip = start cipher this far into buffer; crd[1]->crd_len = length of input buffer for AES crp->crp_ilen = total length of input buffer crp->crp_flags = CRYPTO_F_* flags (ie SKB/IOV etc); crp->crp_buf = pointer to buf/iov/skb crp->crp_callback = function to call when done crp->crp_sid = cryptoid from newsession; crp->crp_opaque = arg to pass back to callback crypto_dispatch(crp) Hope that helps describe how it's current chained together a little. > How do you suggest we go about this? First we need to work out what is missing from the current API that you will need and then we can decide on how to incorporate it. Also, have you looked at the latest crypto API in the linux kernel. It supports a lot of alg's and combinations. The doco can be a bit poor but it may already be capable of what you want. There is also support for async HW crypto now. While I am more than happy to have people improve OCF it wouldn't be fair to leave out the kernel API as there is a lot of work going on there and it's part of the kernel, something OCF will never be ;-) Cheers, Davidm > -----Original Message----- > From: David McCullough [mailto:Dav...@se...] > Sent: Friday, 29 January, 2010 6:18 PM > To: Gokhale, Gandhar > Cc: ocf...@li... > Subject: Re: [Ocf-linux-users] AEAD support in OCF > > > Jivin Gokhale, Gandhar lays it down ... > > Hi David, > > Thanks for your reply. I may be missing something here. > > > > As per my understanding what the AEAD mode algorithms typically need in input is: key, nonce, payload and AAD (Additional Authentication Data). Of these, nonce and AAD are very much algorithm dependent (as specified in respective RFCs. E.g. http://tools.ietf.org/html/rfc4106 and http://tools.ietf.org/html/rfc4309). The cryptodesc or cryptoini structures don't appear to have fields that could hold all these values. Are any of the existing fields being overloaded to be used for this? None of the drivers included in the code (ocf-linux-20090901) have any of the AEAD algorithms supported. Further, I don't see the #define values for any AEAD algorithms in the CRYPTO_* list in the cryptodev.h file. I'd would expect something like #define CRYPTO_RIJNDAEL128_GCM 26 > > #define CRYPTO_RIJNDAEL128_CCM 26 etc. > > However, I don't find them there. > > > > Am I looking at wrong code? > > I was under the impression that AEAD was a term used to refer to hash/cipher > combinations. Perhaps I have that wrong :-( > > Plenty of the drivers do AES/DES+MD5/SHA. In other words something like: > > aead-aes-cbc-hmac-sha > > but you are right, none of them do CCM/GCM or counter modes. Do you need > more inputs to the algs than aead-aes-cbc-hmac-sha would require ? > OCF allows for each cipher/hash in a session to have it's own keys, iv's etc. > If that is enough then you probably just need to add the ciphers/auth algs > you want to the headers and implement them in your driver. > > Cheers, > Davidm > > > > -----Original Message----- > > From: David McCullough [mailto:Dav...@se...] > > Sent: Friday, 29 January, 2010 4:59 PM > > To: Gokhale, Gandhar > > Cc: ocf...@li... > > Subject: Re: [Ocf-linux-users] AEAD support in OCF > > > > > > Jivin Gokhale, Gandhar lays it down ... > > > Hi, > > > > > > I??m working on designing an OCF driver to be used by Linux IPsec stack. I??m trying to gather information about how ??aead?? (Authenticated Encryption with Associate Data) type of algorithms can be supported with OCF. I searched this mailing list but could not get any discussion on this particular topic. Have any aead algorithms been supported via OCF? If yes, is there any resource that discusses the details of the same? Any help is highly appreciated. > > > > OCF has always been able to do AEAD. > > > > Not sure if it's documented specifically. The OCF design paper discusses > > alg chaining (AEAD wasn't the term back then ;-) > > > > http://openbsd.org/papers/ocf.pdf > > > > Almost all the existing drivers implement it and openswan ipsec_ocf.c > > gives you a fairly easy to follow example of how to use it. > > > > If you need more info feel free to ask at any time, > > > > Cheers, > > Davidm > > > > -- > > David McCullough, dav...@se..., Ph:+61 734352815 > > McAfee - SnapGear http://www.snapgear.com http://www.uCdot.org > > > > > > -- > David McCullough, dav...@se..., Ph:+61 734352815 > McAfee - SnapGear http://www.snapgear.com http://www.uCdot.org > > -- David McCullough, dav...@se..., Ph:+61 734352815 McAfee - SnapGear http://www.snapgear.com http://www.uCdot.org |
|
From: David M. <Dav...@se...> - 2010-01-29 14:33:07
|
Jivin Gokhale, Gandhar lays it down ... > Hi David, > Thanks for your reply. I may be missing something here. > > As per my understanding what the AEAD mode algorithms typically need in input is: key, nonce, payload and AAD (Additional Authentication Data). Of these, nonce and AAD are very much algorithm dependent (as specified in respective RFCs. E.g. http://tools.ietf.org/html/rfc4106 and http://tools.ietf.org/html/rfc4309). The cryptodesc or cryptoini structures don't appear to have fields that could hold all these values. Are any of the existing fields being overloaded to be used for this? None of the drivers included in the code (ocf-linux-20090901) have any of the AEAD algorithms supported. Further, I don't see the #define values for any AEAD algorithms in the CRYPTO_* list in the cryptodev.h file. I'd would expect something like #define CRYPTO_RIJNDAEL128_GCM 26 > #define CRYPTO_RIJNDAEL128_CCM 26 etc. > However, I don't find them there. > > Am I looking at wrong code? I was under the impression that AEAD was a term used to refer to hash/cipher combinations. Perhaps I have that wrong :-( Plenty of the drivers do AES/DES+MD5/SHA. In other words something like: aead-aes-cbc-hmac-sha but you are right, none of them do CCM/GCM or counter modes. Do you need more inputs to the algs than aead-aes-cbc-hmac-sha would require ? OCF allows for each cipher/hash in a session to have it's own keys, iv's etc. If that is enough then you probably just need to add the ciphers/auth algs you want to the headers and implement them in your driver. Cheers, Davidm > -----Original Message----- > From: David McCullough [mailto:Dav...@se...] > Sent: Friday, 29 January, 2010 4:59 PM > To: Gokhale, Gandhar > Cc: ocf...@li... > Subject: Re: [Ocf-linux-users] AEAD support in OCF > > > Jivin Gokhale, Gandhar lays it down ... > > Hi, > > > > I??m working on designing an OCF driver to be used by Linux IPsec stack. I??m trying to gather information about how ??aead?? (Authenticated Encryption with Associate Data) type of algorithms can be supported with OCF. I searched this mailing list but could not get any discussion on this particular topic. Have any aead algorithms been supported via OCF? If yes, is there any resource that discusses the details of the same? Any help is highly appreciated. > > OCF has always been able to do AEAD. > > Not sure if it's documented specifically. The OCF design paper discusses > alg chaining (AEAD wasn't the term back then ;-) > > http://openbsd.org/papers/ocf.pdf > > Almost all the existing drivers implement it and openswan ipsec_ocf.c > gives you a fairly easy to follow example of how to use it. > > If you need more info feel free to ask at any time, > > Cheers, > Davidm > > -- > David McCullough, dav...@se..., Ph:+61 734352815 > McAfee - SnapGear http://www.snapgear.com http://www.uCdot.org > > -- David McCullough, dav...@se..., Ph:+61 734352815 McAfee - SnapGear http://www.snapgear.com http://www.uCdot.org |
|
From: Gokhale, G. <Gan...@ls...> - 2010-01-29 14:23:53
|
Hi David, Thanks for pointing out aead-aes-cbc-hmac-sha. However, I could not get a ratified standard for this. I could get only an expired draft of this. So, this may not be the perfect example to look at. However, it'll be great if you could point me to an example OCF driver that has a support for aead-aes-cbc-hmac-sha. I see that we need to have a few more fields (maybe union) in the cryptoini and/or cryptodesc structure to support the AAD, the nonce or maybe IV and salt separately. This will be needed even in case of aead-aes-cbc-hmac-sha. Details need to be finalized after carefully looking into all the AEAD algorithms available so far. If there is an existing aead-aes-cbc-hmac-sha OCF driver we can see how it uses the data structures as an example. How do you suggest we go about this? Thanks and regards, Gandhar Gokhale -----Original Message----- From: David McCullough [mailto:Dav...@se...] Sent: Friday, 29 January, 2010 6:18 PM To: Gokhale, Gandhar Cc: ocf...@li... Subject: Re: [Ocf-linux-users] AEAD support in OCF Jivin Gokhale, Gandhar lays it down ... > Hi David, > Thanks for your reply. I may be missing something here. > > As per my understanding what the AEAD mode algorithms typically need in input is: key, nonce, payload and AAD (Additional Authentication Data). Of these, nonce and AAD are very much algorithm dependent (as specified in respective RFCs. E.g. http://tools.ietf.org/html/rfc4106 and http://tools.ietf.org/html/rfc4309). The cryptodesc or cryptoini structures don't appear to have fields that could hold all these values. Are any of the existing fields being overloaded to be used for this? None of the drivers included in the code (ocf-linux-20090901) have any of the AEAD algorithms supported. Further, I don't see the #define values for any AEAD algorithms in the CRYPTO_* list in the cryptodev.h file. I'd would expect something like #define CRYPTO_RIJNDAEL128_GCM 26 > #define CRYPTO_RIJNDAEL128_CCM 26 etc. > However, I don't find them there. > > Am I looking at wrong code? I was under the impression that AEAD was a term used to refer to hash/cipher combinations. Perhaps I have that wrong :-( Plenty of the drivers do AES/DES+MD5/SHA. In other words something like: aead-aes-cbc-hmac-sha but you are right, none of them do CCM/GCM or counter modes. Do you need more inputs to the algs than aead-aes-cbc-hmac-sha would require ? OCF allows for each cipher/hash in a session to have it's own keys, iv's etc. If that is enough then you probably just need to add the ciphers/auth algs you want to the headers and implement them in your driver. Cheers, Davidm > -----Original Message----- > From: David McCullough [mailto:Dav...@se...] > Sent: Friday, 29 January, 2010 4:59 PM > To: Gokhale, Gandhar > Cc: ocf...@li... > Subject: Re: [Ocf-linux-users] AEAD support in OCF > > > Jivin Gokhale, Gandhar lays it down ... > > Hi, > > > > I??m working on designing an OCF driver to be used by Linux IPsec stack. I??m trying to gather information about how ??aead?? (Authenticated Encryption with Associate Data) type of algorithms can be supported with OCF. I searched this mailing list but could not get any discussion on this particular topic. Have any aead algorithms been supported via OCF? If yes, is there any resource that discusses the details of the same? Any help is highly appreciated. > > OCF has always been able to do AEAD. > > Not sure if it's documented specifically. The OCF design paper discusses > alg chaining (AEAD wasn't the term back then ;-) > > http://openbsd.org/papers/ocf.pdf > > Almost all the existing drivers implement it and openswan ipsec_ocf.c > gives you a fairly easy to follow example of how to use it. > > If you need more info feel free to ask at any time, > > Cheers, > Davidm > > -- > David McCullough, dav...@se..., Ph:+61 734352815 > McAfee - SnapGear http://www.snapgear.com http://www.uCdot.org > > -- David McCullough, dav...@se..., Ph:+61 734352815 McAfee - SnapGear http://www.snapgear.com http://www.uCdot.org |
|
From: David M. <Dav...@se...> - 2010-01-29 14:16:27
|
Jivin Gokhale, Gandhar lays it down ... > Hi David, > Thanks for pointing out aead-aes-cbc-hmac-sha. However, I could not get a ratified standard for this. I could get only an expired draft of this. So, this may not be the perfect example to look at. However, it'll be great if you could point me to an example OCF driver that has a support for aead-aes-cbc-hmac-sha. > I see that we need to have a few more fields (maybe union) in the cryptoini and/or cryptodesc structure to support the AAD, the nonce or maybe IV and salt separately. This will be needed even in case of aead-aes-cbc-hmac-sha. Details need to be finalized after carefully looking into all the AEAD algorithms available so far. If there is an existing aead-aes-cbc-hmac-sha OCF driver we can see how it uses the data structures as an example. Currently, one way to do a combination of aes-cbc/hmac-sha the process is something like this (in kernel) error checking removed ;-): init: struct cryptoini alg[2]; alg[0].cri_alg = CRYPTO_AES_CBC; alg[0].cri_klen = aes key length in bits; alg[0].cri_key = ptr to aes key data; alg[0].cri_next = &alg[1]; alg[1].cri_alg = CRYPTO_SHA1_HMAC; alg[1].cri_klen = sha1 key length in bits; alg[1].cri_key = ptr to sha1 key data; alg[1].cri_mlen = result len (ie., 12 for ipsec, 20 for normal sha) err= crypto_newsession(&cryptoid, &alg[0], CRYPTOCAP_F_HARDWARE) encrypt some data: struct cryptop *crp; struct cryptodesc *crd[2]; crp = crypto_getreq(2); crd[0] = crp->crp_desc; crd[1] = crd[0]->crd_next; crd[0]->crd_alg = CRYPTO_SHA1_HMAC; crd[0]->crd_key = sha key pointer; crd[0]->crd_klen = sha key len in bits; crd[0]->crd_inject = offset in buffer for sha result crd[0]->crd_mlen = size of result crd[0]->crd_skip = start hashing this far into buffer; crd[0]->crd_len = length of input buffer for SHA crd[1]->crd_alg = CRYPTO_AES_CBC; crd[1]->crd_key = aes key pointer; crd[1]->crd_klen = aes key len in bits; crd[1]->crd_inject = offset in buffer to write the IV when done crd[1]->crd_skip = start cipher this far into buffer; crd[1]->crd_len = length of input buffer for AES crp->crp_ilen = total length of input buffer crp->crp_flags = CRYPTO_F_* flags (ie SKB/IOV etc); crp->crp_buf = pointer to buf/iov/skb crp->crp_callback = function to call when done crp->crp_sid = cryptoid from newsession; crp->crp_opaque = arg to pass back to callback crypto_dispatch(crp) Hope that helps describe how it's current chained together a little. > How do you suggest we go about this? First we need to work out what is missing from the current API that you will need and then we can decide on how to incorporate it. Also, have you looked at the latest crypto API in the linux kernel. It supports a lot of alg's and combinations. The doco can be a bit poor but it may already be capable of what you want. There is also support for async HW crypto now. While I am more than happy to have people improve OCF it wouldn't be fair to leave out the kernel API as there is a lot of work going on there and it's part of the kernel, something OCF will never be ;-) Cheers, Davidm > -----Original Message----- > From: David McCullough [mailto:Dav...@se...] > Sent: Friday, 29 January, 2010 6:18 PM > To: Gokhale, Gandhar > Cc: ocf...@li... > Subject: Re: [Ocf-linux-users] AEAD support in OCF > > > Jivin Gokhale, Gandhar lays it down ... > > Hi David, > > Thanks for your reply. I may be missing something here. > > > > As per my understanding what the AEAD mode algorithms typically need in input is: key, nonce, payload and AAD (Additional Authentication Data). Of these, nonce and AAD are very much algorithm dependent (as specified in respective RFCs. E.g. http://tools.ietf.org/html/rfc4106 and http://tools.ietf.org/html/rfc4309). The cryptodesc or cryptoini structures don't appear to have fields that could hold all these values. Are any of the existing fields being overloaded to be used for this? None of the drivers included in the code (ocf-linux-20090901) have any of the AEAD algorithms supported. Further, I don't see the #define values for any AEAD algorithms in the CRYPTO_* list in the cryptodev.h file. I'd would expect something like #define CRYPTO_RIJNDAEL128_GCM 26 > > #define CRYPTO_RIJNDAEL128_CCM 26 etc. > > However, I don't find them there. > > > > Am I looking at wrong code? > > I was under the impression that AEAD was a term used to refer to hash/cipher > combinations. Perhaps I have that wrong :-( > > Plenty of the drivers do AES/DES+MD5/SHA. In other words something like: > > aead-aes-cbc-hmac-sha > > but you are right, none of them do CCM/GCM or counter modes. Do you need > more inputs to the algs than aead-aes-cbc-hmac-sha would require ? > OCF allows for each cipher/hash in a session to have it's own keys, iv's etc. > If that is enough then you probably just need to add the ciphers/auth algs > you want to the headers and implement them in your driver. > > Cheers, > Davidm > > > > -----Original Message----- > > From: David McCullough [mailto:Dav...@se...] > > Sent: Friday, 29 January, 2010 4:59 PM > > To: Gokhale, Gandhar > > Cc: ocf...@li... > > Subject: Re: [Ocf-linux-users] AEAD support in OCF > > > > > > Jivin Gokhale, Gandhar lays it down ... > > > Hi, > > > > > > I??m working on designing an OCF driver to be used by Linux IPsec stack. I??m trying to gather information about how ??aead?? (Authenticated Encryption with Associate Data) type of algorithms can be supported with OCF. I searched this mailing list but could not get any discussion on this particular topic. Have any aead algorithms been supported via OCF? If yes, is there any resource that discusses the details of the same? Any help is highly appreciated. > > > > OCF has always been able to do AEAD. > > > > Not sure if it's documented specifically. The OCF design paper discusses > > alg chaining (AEAD wasn't the term back then ;-) > > > > http://openbsd.org/papers/ocf.pdf > > > > Almost all the existing drivers implement it and openswan ipsec_ocf.c > > gives you a fairly easy to follow example of how to use it. > > > > If you need more info feel free to ask at any time, > > > > Cheers, > > Davidm > > > > -- > > David McCullough, dav...@se..., Ph:+61 734352815 > > McAfee - SnapGear http://www.snapgear.com http://www.uCdot.org > > > > > > -- > David McCullough, dav...@se..., Ph:+61 734352815 > McAfee - SnapGear http://www.snapgear.com http://www.uCdot.org > > -- David McCullough, dav...@se..., Ph:+61 734352815 McAfee - SnapGear http://www.snapgear.com http://www.uCdot.org |
|
From: Gokhale, G. <Gan...@ls...> - 2010-01-29 13:07:01
|
Hi David, Thanks for your reply. I may be missing something here. As per my understanding what the AEAD mode algorithms typically need in input is: key, nonce, payload and AAD (Additional Authentication Data). Of these, nonce and AAD are very much algorithm dependent (as specified in respective RFCs. E.g. http://tools.ietf.org/html/rfc4106 and http://tools.ietf.org/html/rfc4309). The cryptodesc or cryptoini structures don't appear to have fields that could hold all these values. Are any of the existing fields being overloaded to be used for this? None of the drivers included in the code (ocf-linux-20090901) have any of the AEAD algorithms supported. Further, I don't see the #define values for any AEAD algorithms in the CRYPTO_* list in the cryptodev.h file. I'd would expect something like #define CRYPTO_RIJNDAEL128_GCM 26 #define CRYPTO_RIJNDAEL128_CCM 26 etc. However, I don't find them there. Am I looking at wrong code? Thanks and regards, Gandhar Gokhale -----Original Message----- From: David McCullough [mailto:Dav...@se...] Sent: Friday, 29 January, 2010 4:59 PM To: Gokhale, Gandhar Cc: ocf...@li... Subject: Re: [Ocf-linux-users] AEAD support in OCF Jivin Gokhale, Gandhar lays it down ... > Hi, > > I??m working on designing an OCF driver to be used by Linux IPsec stack. I??m trying to gather information about how ??aead?? (Authenticated Encryption with Associate Data) type of algorithms can be supported with OCF. I searched this mailing list but could not get any discussion on this particular topic. Have any aead algorithms been supported via OCF? If yes, is there any resource that discusses the details of the same? Any help is highly appreciated. OCF has always been able to do AEAD. Not sure if it's documented specifically. The OCF design paper discusses alg chaining (AEAD wasn't the term back then ;-) http://openbsd.org/papers/ocf.pdf Almost all the existing drivers implement it and openswan ipsec_ocf.c gives you a fairly easy to follow example of how to use it. If you need more info feel free to ask at any time, Cheers, Davidm -- David McCullough, dav...@se..., Ph:+61 734352815 McAfee - SnapGear http://www.snapgear.com http://www.uCdot.org |
|
From: David M. <Dav...@se...> - 2010-01-29 11:28:40
|
Jivin Gokhale, Gandhar lays it down ... > Hi, > > I??m working on designing an OCF driver to be used by Linux IPsec stack. I??m trying to gather information about how ??aead?? (Authenticated Encryption with Associate Data) type of algorithms can be supported with OCF. I searched this mailing list but could not get any discussion on this particular topic. Have any aead algorithms been supported via OCF? If yes, is there any resource that discusses the details of the same? Any help is highly appreciated. OCF has always been able to do AEAD. Not sure if it's documented specifically. The OCF design paper discusses alg chaining (AEAD wasn't the term back then ;-) http://openbsd.org/papers/ocf.pdf Almost all the existing drivers implement it and openswan ipsec_ocf.c gives you a fairly easy to follow example of how to use it. If you need more info feel free to ask at any time, Cheers, Davidm -- David McCullough, dav...@se..., Ph:+61 734352815 McAfee - SnapGear http://www.snapgear.com http://www.uCdot.org |
|
From: Gokhale, G. <Gan...@ls...> - 2010-01-29 07:36:50
|
Hi, I'm working on designing an OCF driver to be used by Linux IPsec stack. I'm trying to gather information about how 'aead' (Authenticated Encryption with Associate Data) type of algorithms can be supported with OCF. I searched this mailing list but could not get any discussion on this particular topic. Have any aead algorithms been supported via OCF? If yes, is there any resource that discusses the details of the same? Any help is highly appreciated. Thanks and regards, Gandhar Gokhale |
4 messages has been excluded from this view by a project administrator.
