Re: [Ocf-linux-users] Can cryptosoft be used as a bridge between OCF and Linux crypto APIs

[Zhou, B. <b-...@ti...>]

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