Thread: [Ocf-linux-users] Can cryptosoft be used as a bridge between OCF and Linux crypto APIs
Brought to you by:
david-m
Menu
▾
▴
ocf-linux-users
|
From: Zhou, B. <b-...@ti...> - 2011-05-05 19:20:09
|
Hi, We are doing Linux Async Crypto drivers for HW accelerators (AES, DES/3DES, SHA1/MD5) and kernel version we are using now is 2.6.37. Since user space APIs for Linux Crypto are still under development and not available in 2.6.37, we are looking at putting OCF on top of Linux crypto APIs. We see that there is cryptosoft module in OCF package which can translate between OCF requests and Linux crypto requests. Does anybody know if cryptosoft can practically be used as a bridge to handle all possible OpenSSL use cases? If it can not, is there any other existing software that is able to perform as a bridge? Many thanks in advance! Bin |
|
From: Zhou, B. <b-...@ti...> - 2011-05-05 20:28:09
|
Yun,
Thanks for your response. That's good news to me:-)
By saying "can practically be used", I meant it can handle all use cases of OpenSSL; and the reason I asked that is because I see following comments in cryptosoft.c and it makes me feel that some cases might not be handled here. I'm not familiar with OpenSSL, so not sure if this logic prevents some openSSL usage.
static void swcr_process_req(struct swcr_req *req)
{
struct swcr_data *sw;
struct cryptop *crp = req->crp;
struct cryptodesc *crd = req->crd;
struct sk_buff *skb = (struct sk_buff *) crp->crp_buf;
struct uio *uiop = (struct uio *) crp->crp_buf;
int sg_num, sg_len, skip;
dprintk("%s()\n", __FUNCTION__);
/*
* Find the crypto context.
*
* XXX Note that the logic here prevents us from having
* XXX the same algorithm multiple times in a session
* XXX (or rather, we can but it won't give us the right
* XXX results). To do that, we'd need some way of differentiating
* XXX between the various instances of an algorithm (so we can
* XXX locate the correct crypto context).
*/
Regards,
Bin
-----Original Message-----
From: Yun-Fong Loh [mailto:yl...@ed...]
Sent: Thursday, May 05, 2011 4:05 PM
To: Zhou, Bin
Cc: ocf...@li...
Subject: Re: [Ocf-linux-users] Can cryptosoft be used as a bridge between OCF and Linux crypto APIs
I have used cryptosoft successfully with OpenSSL.
What criteria are you using to determine whether it can "practically be used"?
Yun
On Thu, May 5, 2011 at 12:20 PM, Zhou, Bin <b-...@ti...> wrote:
> Hi,
>
> We are doing Linux Async Crypto drivers for HW accelerators (AES, DES/3DES,
> SHA1/MD5) and kernel version we are using now is 2.6.37. Since user space
> APIs for Linux Crypto are still under development and not available in
> 2.6.37, we are looking at putting OCF on top of Linux crypto APIs. We see
> that there is cryptosoft module in OCF package which can translate between
> OCF requests and Linux crypto requests.
>
> Does anybody know if cryptosoft can practically be used as a bridge to
> handle all possible OpenSSL use cases?
>
> If it can not, is there any other existing software that is able to perform
> as a bridge?
>
>
>
> Many thanks in advance!
>
>
>
> Bin
>
> ------------------------------------------------------------------------------
> WhatsUp Gold - Download Free Network Management Software
> The most intuitive, comprehensive, and cost-effective network
> management toolset available today. Delivers lowest initial
> acquisition cost and overall TCO of any competing solution.
> http://p.sf.net/sfu/whatsupgold-sd
> _______________________________________________
> Ocf-linux-users mailing list
> Ocf...@li...
> https://lists.sourceforge.net/lists/listinfo/ocf-linux-users
>
>
|
|
From: Yun-Fong L. <yl...@ed...> - 2011-05-05 20:32:47
|
I have used cryptosoft successfully with OpenSSL. What criteria are you using to determine whether it can "practically be used"? Yun On Thu, May 5, 2011 at 12:20 PM, Zhou, Bin <b-...@ti...> wrote: > Hi, > > We are doing Linux Async Crypto drivers for HW accelerators (AES, DES/3DES, > SHA1/MD5) and kernel version we are using now is 2.6.37. Since user space > APIs for Linux Crypto are still under development and not available in > 2.6.37, we are looking at putting OCF on top of Linux crypto APIs. We see > that there is cryptosoft module in OCF package which can translate between > OCF requests and Linux crypto requests. > > Does anybody know if cryptosoft can practically be used as a bridge to > handle all possible OpenSSL use cases? > > If it can not, is there any other existing software that is able to perform > as a bridge? > > > > Many thanks in advance! > > > > Bin > > ------------------------------------------------------------------------------ > WhatsUp Gold - Download Free Network Management Software > The most intuitive, comprehensive, and cost-effective network > management toolset available today. Delivers lowest initial > acquisition cost and overall TCO of any competing solution. > http://p.sf.net/sfu/whatsupgold-sd > _______________________________________________ > Ocf-linux-users mailing list > Ocf...@li... > https://lists.sourceforge.net/lists/listinfo/ocf-linux-users > > |
|
From: Yun-Fong L. <yl...@ed...> - 2011-05-05 20:55:52
|
On Thu, May 5, 2011 at 1:27 PM, Zhou, Bin <b-...@ti...> wrote:
> Yun,
> Thanks for your response. That's good news to me:-)
>
> By saying "can practically be used", I meant it can handle all use cases of OpenSSL; and the reason I asked that is because I see following comments in cryptosoft.c and it makes me feel that some cases might not be handled here. I'm not familiar with OpenSSL, so not sure if this logic prevents some openSSL usage.
>
> static void swcr_process_req(struct swcr_req *req)
> {
> struct swcr_data *sw;
> struct cryptop *crp = req->crp;
> struct cryptodesc *crd = req->crd;
> struct sk_buff *skb = (struct sk_buff *) crp->crp_buf;
> struct uio *uiop = (struct uio *) crp->crp_buf;
> int sg_num, sg_len, skip;
>
> dprintk("%s()\n", __FUNCTION__);
>
> /*
> * Find the crypto context.
> *
> * XXX Note that the logic here prevents us from having
> * XXX the same algorithm multiple times in a session
> * XXX (or rather, we can but it won't give us the right
> * XXX results). To do that, we'd need some way of differentiating
> * XXX between the various instances of an algorithm (so we can
> * XXX locate the correct crypto context).
> */
>
> Regards,
> Bin
That's a reasonable concern, I had not noticed that before.
I'm not entirely familiar with how OpenSSL works as well, but from
looking at engine/hw_cryptodev.c in OpenSSL, it seems to invoke
operations in a discrete manner so it doesn't look to me like a
problem.
Yun
|
|
From: David M. <dav...@mc...> - 2011-05-05 23:00:47
|
Jivin Yun-Fong Loh lays it down ...
> On Thu, May 5, 2011 at 1:27 PM, Zhou, Bin <b-...@ti...> wrote:
> > Yun,
> > Thanks for your response. That's good news to me:-)
> >
> > By saying "can practically be used", I meant it can handle all use cases of OpenSSL; and the reason I asked that is because I see following comments in cryptosoft.c and it makes me feel that some cases might not be handled here. I'm not familiar with OpenSSL, so not sure if this logic prevents some openSSL usage.
> >
> > static void swcr_process_req(struct swcr_req *req)
> > {
> > ?? ?? ?? ??struct swcr_data *sw;
> > ?? ?? ?? ??struct cryptop *crp = req->crp;
> > ?? ?? ?? ??struct cryptodesc *crd = req->crd;
> > ?? ?? ?? ??struct sk_buff *skb = (struct sk_buff *) crp->crp_buf;
> > ?? ?? ?? ??struct uio *uiop = (struct uio *) crp->crp_buf;
> > ?? ?? ?? ??int sg_num, sg_len, skip;
> >
> > ?? ?? ?? ??dprintk("%s()\n", __FUNCTION__);
> >
> > ?? ?? ?? ??/*
> > ?? ?? ?? ?? * Find the crypto context.
> > ?? ?? ?? ?? *
> > ?? ?? ?? ?? * XXX Note that the logic here prevents us from having
> > ?? ?? ?? ?? * XXX the same algorithm multiple times in a session
> > ?? ?? ?? ?? * XXX (or rather, we can but it won't give us the right
> > ?? ?? ?? ?? * XXX results). To do that, we'd need some way of differentiating
> > ?? ?? ?? ?? * XXX between the various instances of an algorithm (so we can
> > ?? ?? ?? ?? * XXX locate the correct crypto context).
> > ?? ?? ?? ?? */
> >
> > Regards,
> > Bin
>
> That's a reasonable concern, I had not noticed that before.
>
> I'm not entirely familiar with how OpenSSL works as well, but from
> looking at engine/hw_cryptodev.c in OpenSSL, it seems to invoke
> operations in a discrete manner so it doesn't look to me like a
> problem.
Thats a fair judgement.
What this means is that you cannot chain 3DES and 3DES together in the same
session. This is pretty unlikely requirement and I don't believe the
openssl code would ever consider it, they would be 2 seperate des
operations on seperate sessions with seperate keys etc.
In this context a session is something like "3des+sha1" or "aes128+md5".
So you can see that "3des+3des" is something you will rarely if ever require
even if openssl did support it.
Cheers,
Davidm
--
David McCullough, dav...@mc..., Ph:+61 734352815
McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org
|
|
From: Zhou, B. <b-...@ti...> - 2011-05-06 13:31:24
|
Thanks a lot for your explanations, which make us concern free to use cryptosoft as a bridge.
Best regards,
Bin
-----Original Message-----
From: David McCullough [mailto:dav...@Mc...]
Sent: Thursday, May 05, 2011 7:00 PM
To: Yun-Fong Loh
Cc: Zhou, Bin; ocf...@li...
Subject: Re: [Ocf-linux-users] Can cryptosoft be used as a bridge between OCF and Linux crypto APIs
Jivin Yun-Fong Loh lays it down ...
> On Thu, May 5, 2011 at 1:27 PM, Zhou, Bin <b-...@ti...> wrote:
> > Yun,
> > Thanks for your response. That's good news to me:-)
> >
> > By saying "can practically be used", I meant it can handle all use cases of OpenSSL; and the reason I asked that is because I see following comments in cryptosoft.c and it makes me feel that some cases might not be handled here. I'm not familiar with OpenSSL, so not sure if this logic prevents some openSSL usage.
> >
> > static void swcr_process_req(struct swcr_req *req)
> > {
> > ?? ?? ?? ??struct swcr_data *sw;
> > ?? ?? ?? ??struct cryptop *crp = req->crp;
> > ?? ?? ?? ??struct cryptodesc *crd = req->crd;
> > ?? ?? ?? ??struct sk_buff *skb = (struct sk_buff *) crp->crp_buf;
> > ?? ?? ?? ??struct uio *uiop = (struct uio *) crp->crp_buf;
> > ?? ?? ?? ??int sg_num, sg_len, skip;
> >
> > ?? ?? ?? ??dprintk("%s()\n", __FUNCTION__);
> >
> > ?? ?? ?? ??/*
> > ?? ?? ?? ?? * Find the crypto context.
> > ?? ?? ?? ?? *
> > ?? ?? ?? ?? * XXX Note that the logic here prevents us from having
> > ?? ?? ?? ?? * XXX the same algorithm multiple times in a session
> > ?? ?? ?? ?? * XXX (or rather, we can but it won't give us the right
> > ?? ?? ?? ?? * XXX results). To do that, we'd need some way of differentiating
> > ?? ?? ?? ?? * XXX between the various instances of an algorithm (so we can
> > ?? ?? ?? ?? * XXX locate the correct crypto context).
> > ?? ?? ?? ?? */
> >
> > Regards,
> > Bin
>
> That's a reasonable concern, I had not noticed that before.
>
> I'm not entirely familiar with how OpenSSL works as well, but from
> looking at engine/hw_cryptodev.c in OpenSSL, it seems to invoke
> operations in a discrete manner so it doesn't look to me like a
> problem.
Thats a fair judgement.
What this means is that you cannot chain 3DES and 3DES together in the same
session. This is pretty unlikely requirement and I don't believe the
openssl code would ever consider it, they would be 2 seperate des
operations on seperate sessions with seperate keys etc.
In this context a session is something like "3des+sha1" or "aes128+md5".
So you can see that "3des+3des" is something you will rarely if ever require
even if openssl did support it.
Cheers,
Davidm
--
David McCullough, dav...@mc..., Ph:+61 734352815
McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org
|
|
From: Lide, D. <dl...@ti...> - 2011-05-06 13:36:41
|
Would this present a problem with modes that use the same underlying cipher for encrypt and for authentication such as AES for CBC mode and aes-xcbc-mac (which uses AES again in CBC mode with a different key in order to produce an authentication tag) ?
-----Original Message-----
From: David McCullough [mailto:dav...@mc...]
Sent: Thursday, May 05, 2011 7:00 PM
To: Yun-Fong Loh
Cc: ocf...@li...
Subject: Re: [Ocf-linux-users] Can cryptosoft be used as a bridge between OCF and Linux crypto APIs
Jivin Yun-Fong Loh lays it down ...
> On Thu, May 5, 2011 at 1:27 PM, Zhou, Bin <b-...@ti...> wrote:
> > Yun,
> > Thanks for your response. That's good news to me:-)
> >
> > By saying "can practically be used", I meant it can handle all use cases of OpenSSL; and the reason I asked that is because I see following comments in cryptosoft.c and it makes me feel that some cases might not be handled here. I'm not familiar with OpenSSL, so not sure if this logic prevents some openSSL usage.
> >
> > static void swcr_process_req(struct swcr_req *req) { ?? ?? ??
> > ??struct swcr_data *sw; ?? ?? ?? ??struct cryptop *crp = req->crp;
> > ?? ?? ?? ??struct cryptodesc *crd = req->crd; ?? ?? ?? ??struct
> > sk_buff *skb = (struct sk_buff *) crp->crp_buf; ?? ?? ?? ??struct
> > uio *uiop = (struct uio *) crp->crp_buf; ?? ?? ?? ??int sg_num,
> > sg_len, skip;
> >
> > ?? ?? ?? ??dprintk("%s()\n", __FUNCTION__);
> >
> > ?? ?? ?? ??/*
> > ?? ?? ?? ?? * Find the crypto context.
> > ?? ?? ?? ?? *
> > ?? ?? ?? ?? * XXX Note that the logic here prevents us from having
> > ?? ?? ?? ?? * XXX the same algorithm multiple times in a session ??
> > ?? ?? ?? * XXX (or rather, we can but it won't give us the right ??
> > ?? ?? ?? * XXX results). To do that, we'd need some way of
> > differentiating ?? ?? ?? ?? * XXX between the various instances of
> > an algorithm (so we can ?? ?? ?? ?? * XXX locate the correct crypto context).
> > ?? ?? ?? ?? */
> >
> > Regards,
> > Bin
>
> That's a reasonable concern, I had not noticed that before.
>
> I'm not entirely familiar with how OpenSSL works as well, but from
> looking at engine/hw_cryptodev.c in OpenSSL, it seems to invoke
> operations in a discrete manner so it doesn't look to me like a
> problem.
Thats a fair judgement.
What this means is that you cannot chain 3DES and 3DES together in the same session. This is pretty unlikely requirement and I don't believe the openssl code would ever consider it, they would be 2 seperate des operations on seperate sessions with seperate keys etc.
In this context a session is something like "3des+sha1" or "aes128+md5".
So you can see that "3des+3des" is something you will rarely if ever require even if openssl did support it.
Cheers,
Davidm
--
David McCullough, dav...@mc..., Ph:+61 734352815
McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org
------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
Ocf-linux-users mailing list
Ocf...@li...
https://lists.sourceforge.net/lists/listinfo/ocf-linux-users
|
|
From: Zhou, B. <b-...@ti...> - 2011-05-06 13:42:52
|
David,
Here is a question from my colleague:
Would this present a problem with modes that use the same underlying cipher for encrypt and for authentication such as AES for CBC mode and aes-xcbc-mac (which uses AES again in CBC mode with a different key in order to produce an authentication tag)?
Thanks,
Bin
-----Original Message-----
From: David McCullough [mailto:dav...@Mc...]
Sent: Thursday, May 05, 2011 7:00 PM
To: Yun-Fong Loh
Cc: Zhou, Bin; ocf...@li...
Subject: Re: [Ocf-linux-users] Can cryptosoft be used as a bridge between OCF and Linux crypto APIs
Jivin Yun-Fong Loh lays it down ...
> On Thu, May 5, 2011 at 1:27 PM, Zhou, Bin <b-...@ti...> wrote:
> > Yun,
> > Thanks for your response. That's good news to me:-)
> >
> > By saying "can practically be used", I meant it can handle all use cases of OpenSSL; and the reason I asked that is because I see following comments in cryptosoft.c and it makes me feel that some cases might not be handled here. I'm not familiar with OpenSSL, so not sure if this logic prevents some openSSL usage.
> >
> > static void swcr_process_req(struct swcr_req *req)
> > {
> > ?? ?? ?? ??struct swcr_data *sw;
> > ?? ?? ?? ??struct cryptop *crp = req->crp;
> > ?? ?? ?? ??struct cryptodesc *crd = req->crd;
> > ?? ?? ?? ??struct sk_buff *skb = (struct sk_buff *) crp->crp_buf;
> > ?? ?? ?? ??struct uio *uiop = (struct uio *) crp->crp_buf;
> > ?? ?? ?? ??int sg_num, sg_len, skip;
> >
> > ?? ?? ?? ??dprintk("%s()\n", __FUNCTION__);
> >
> > ?? ?? ?? ??/*
> > ?? ?? ?? ?? * Find the crypto context.
> > ?? ?? ?? ?? *
> > ?? ?? ?? ?? * XXX Note that the logic here prevents us from having
> > ?? ?? ?? ?? * XXX the same algorithm multiple times in a session
> > ?? ?? ?? ?? * XXX (or rather, we can but it won't give us the right
> > ?? ?? ?? ?? * XXX results). To do that, we'd need some way of differentiating
> > ?? ?? ?? ?? * XXX between the various instances of an algorithm (so we can
> > ?? ?? ?? ?? * XXX locate the correct crypto context).
> > ?? ?? ?? ?? */
> >
> > Regards,
> > Bin
>
> That's a reasonable concern, I had not noticed that before.
>
> I'm not entirely familiar with how OpenSSL works as well, but from
> looking at engine/hw_cryptodev.c in OpenSSL, it seems to invoke
> operations in a discrete manner so it doesn't look to me like a
> problem.
Thats a fair judgement.
What this means is that you cannot chain 3DES and 3DES together in the same
session. This is pretty unlikely requirement and I don't believe the
openssl code would ever consider it, they would be 2 seperate des
operations on seperate sessions with seperate keys etc.
In this context a session is something like "3des+sha1" or "aes128+md5".
So you can see that "3des+3des" is something you will rarely if ever require
even if openssl did support it.
Cheers,
Davidm
--
David McCullough, dav...@mc..., Ph:+61 734352815
McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org
|
|
From: Zhou, B. <b-...@ti...> - 2011-05-06 18:21:35
|
I have to exclude aes-generic.c and des-generic.c from kernel build to make cryptosoft use my HW drivers. Is this as expected? Or something is wrong?
Thanks,
Bin
-----Original Message-----
From: David McCullough [mailto:dav...@Mc...]
Sent: Thursday, May 05, 2011 7:00 PM
To: Yun-Fong Loh
Cc: Zhou, Bin; ocf...@li...
Subject: Re: [Ocf-linux-users] Can cryptosoft be used as a bridge between OCF and Linux crypto APIs
Jivin Yun-Fong Loh lays it down ...
> On Thu, May 5, 2011 at 1:27 PM, Zhou, Bin <b-...@ti...> wrote:
> > Yun,
> > Thanks for your response. That's good news to me:-)
> >
> > By saying "can practically be used", I meant it can handle all use cases of OpenSSL; and the reason I asked that is because I see following comments in cryptosoft.c and it makes me feel that some cases might not be handled here. I'm not familiar with OpenSSL, so not sure if this logic prevents some openSSL usage.
> >
> > static void swcr_process_req(struct swcr_req *req)
> > {
> > ?? ?? ?? ??struct swcr_data *sw;
> > ?? ?? ?? ??struct cryptop *crp = req->crp;
> > ?? ?? ?? ??struct cryptodesc *crd = req->crd;
> > ?? ?? ?? ??struct sk_buff *skb = (struct sk_buff *) crp->crp_buf;
> > ?? ?? ?? ??struct uio *uiop = (struct uio *) crp->crp_buf;
> > ?? ?? ?? ??int sg_num, sg_len, skip;
> >
> > ?? ?? ?? ??dprintk("%s()\n", __FUNCTION__);
> >
> > ?? ?? ?? ??/*
> > ?? ?? ?? ?? * Find the crypto context.
> > ?? ?? ?? ?? *
> > ?? ?? ?? ?? * XXX Note that the logic here prevents us from having
> > ?? ?? ?? ?? * XXX the same algorithm multiple times in a session
> > ?? ?? ?? ?? * XXX (or rather, we can but it won't give us the right
> > ?? ?? ?? ?? * XXX results). To do that, we'd need some way of differentiating
> > ?? ?? ?? ?? * XXX between the various instances of an algorithm (so we can
> > ?? ?? ?? ?? * XXX locate the correct crypto context).
> > ?? ?? ?? ?? */
> >
> > Regards,
> > Bin
>
> That's a reasonable concern, I had not noticed that before.
>
> I'm not entirely familiar with how OpenSSL works as well, but from
> looking at engine/hw_cryptodev.c in OpenSSL, it seems to invoke
> operations in a discrete manner so it doesn't look to me like a
> problem.
Thats a fair judgement.
What this means is that you cannot chain 3DES and 3DES together in the same
session. This is pretty unlikely requirement and I don't believe the
openssl code would ever consider it, they would be 2 seperate des
operations on seperate sessions with seperate keys etc.
In this context a session is something like "3des+sha1" or "aes128+md5".
So you can see that "3des+3des" is something you will rarely if ever require
even if openssl did support it.
Cheers,
Davidm
--
David McCullough, dav...@mc..., Ph:+61 734352815
McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org
|
|
From: Zhou, B. <b-...@ti...> - 2011-05-06 18:31:18
|
I have figured it out why. I need to use higher cra_priority in my driver than in xxx-generic.c.
Regards,
Bin
-----Original Message-----
From: Zhou, Bin
Sent: Friday, May 06, 2011 1:58 PM
To: David McCullough; Yun-Fong Loh
Cc: ocf...@li...
Subject: Re: [Ocf-linux-users] Can cryptosoft be used as a bridge between OCF and Linux crypto APIs
I have to exclude aes-generic.c and des-generic.c from kernel build to make cryptosoft use my HW drivers. Is this as expected? Or something is wrong?
Thanks,
Bin
-----Original Message-----
From: David McCullough [mailto:dav...@Mc...]
Sent: Thursday, May 05, 2011 7:00 PM
To: Yun-Fong Loh
Cc: Zhou, Bin; ocf...@li...
Subject: Re: [Ocf-linux-users] Can cryptosoft be used as a bridge between OCF and Linux crypto APIs
Jivin Yun-Fong Loh lays it down ...
> On Thu, May 5, 2011 at 1:27 PM, Zhou, Bin <b-...@ti...> wrote:
> > Yun,
> > Thanks for your response. That's good news to me:-)
> >
> > By saying "can practically be used", I meant it can handle all use cases of OpenSSL; and the reason I asked that is because I see following comments in cryptosoft.c and it makes me feel that some cases might not be handled here. I'm not familiar with OpenSSL, so not sure if this logic prevents some openSSL usage.
> >
> > static void swcr_process_req(struct swcr_req *req)
> > {
> > ?? ?? ?? ??struct swcr_data *sw;
> > ?? ?? ?? ??struct cryptop *crp = req->crp;
> > ?? ?? ?? ??struct cryptodesc *crd = req->crd;
> > ?? ?? ?? ??struct sk_buff *skb = (struct sk_buff *) crp->crp_buf;
> > ?? ?? ?? ??struct uio *uiop = (struct uio *) crp->crp_buf;
> > ?? ?? ?? ??int sg_num, sg_len, skip;
> >
> > ?? ?? ?? ??dprintk("%s()\n", __FUNCTION__);
> >
> > ?? ?? ?? ??/*
> > ?? ?? ?? ?? * Find the crypto context.
> > ?? ?? ?? ?? *
> > ?? ?? ?? ?? * XXX Note that the logic here prevents us from having
> > ?? ?? ?? ?? * XXX the same algorithm multiple times in a session
> > ?? ?? ?? ?? * XXX (or rather, we can but it won't give us the right
> > ?? ?? ?? ?? * XXX results). To do that, we'd need some way of differentiating
> > ?? ?? ?? ?? * XXX between the various instances of an algorithm (so we can
> > ?? ?? ?? ?? * XXX locate the correct crypto context).
> > ?? ?? ?? ?? */
> >
> > Regards,
> > Bin
>
> That's a reasonable concern, I had not noticed that before.
>
> I'm not entirely familiar with how OpenSSL works as well, but from
> looking at engine/hw_cryptodev.c in OpenSSL, it seems to invoke
> operations in a discrete manner so it doesn't look to me like a
> problem.
Thats a fair judgement.
What this means is that you cannot chain 3DES and 3DES together in the same
session. This is pretty unlikely requirement and I don't believe the
openssl code would ever consider it, they would be 2 seperate des
operations on seperate sessions with seperate keys etc.
In this context a session is something like "3des+sha1" or "aes128+md5".
So you can see that "3des+3des" is something you will rarely if ever require
even if openssl did support it.
Cheers,
Davidm
--
David McCullough, dav...@mc..., Ph:+61 734352815
McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org
------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today. Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
Ocf-linux-users mailing list
Ocf...@li...
https://lists.sourceforge.net/lists/listinfo/ocf-linux-users
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X