Mark Powers wrote:
> Garrett D'Amore wrote:
>> I notice that crypto.c makes the assumption that if the encrypt and
>> decrypt lengths are the same, that an in-place operation is OK.
>>
>> I'm not sure that this is true of all algorithms. I could imagine,
>> for example, an algorithm where the "update" operation writes to the
>> write buffer by trailing a block behind....
> The check only applies to single part operations, e.g. C_Encrypt().
But what if the device internally uses an "update-like" mechanism to do
this?
>
>>
>> Or what if the input and output buffers were the same size as
>> supplied, but the algorithm is actually a compressing algorithm, and
>> the user was just supplying the same destination buffer size know
>> that it would not be any *larger* than the input buffer.
>
> But I think this would work. Input and output buffer lengths would be
> the same and therefore /dev/crypto
> would do the in-place transformation.
No my point is that this might not be safe... because you could wind up
screwing up bits in the source before you need them. The whole
assumption just feels a bit sticky to me.
>
>>
>> I'd feel a *lot* better if you instead tagged the algorithms for
>> which this is true, much like you are doing in the pkcs11_kernel
>> module. (See kernelGlobal.h)
>
> Tagging mechanisms really needs to take place in the library. We've
> managed to keep knowledge of particular
> mechanisms out of /dev/crypto. That said, I could add a flag to the
> ioctl structure that's passed
> to /dev/crypto. That would remove any ambiguity in /dev/crypto.
That would be better.
-- Garrett
>
>>
>> -- Garrett
>>
>> Mark Powers wrote:
>>> Folks,
>>>
>>> I need two code reviewers for this RFE:
>>>
>>> 6534628 /dev/crypto can use in-place when calling crypto_encrypt API
>>>
>>> The webrev is
>>> http://cr.grommit.com/~mcpowers/6534628/
>>>
>>> or, if you are within SWAN,
>>> http://borg.sfbay.sun.com/cube/builds/mcpowers/6534628/webrev/
>>>
>>> We would appreciate any review comments by July 6 (Friday).
>>>
>>> Thanks,
>>>
>>> Mark Powers
>>> _______________________________________________
>>> crypto-discuss mailing list
>>> crypto-discuss at opensolaris.org
>>> http://opensolaris.org/mailman/listinfo/crypto-discuss
>>
>
