Re: Hardware Crypto Driver

[Herbert Xu]

On Wed, Nov 11, 2015 at 09:54:37AM -0500, Orlando wrote:
> I think the main problem might be my lack of understanding how IVs are
> handled by the kernel crypto framework. It seems the omap-aes.c driver
> is indicating to the crypto framework that it wants IV generation to
> be handled automatically by the crypto framework by filling this field
> .geniv = "eseqiv". Is there a way I can tell the kernel crypto
> framework to stop handling IV generation? Even if I remove the .geniv
> field it gets set with a default value by the crypto framework. I have
> tried .geniv = "" but then when I make a crypto call it does
> not use the driver anymore. What are the required things I must do if
> I set .geniv = "" ?

geniv is completely unrelated to this.  In fact, in the current
kernel geniv is no longer used and I will remove it once the skcipher
conversion is done.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Hardware Crypto Driver

[Orlando]

I think the main problem might be my lack of understanding how IVs are
handled by the kernel crypto framework. It seems the omap-aes.c driver
is indicating to the crypto framework that it wants IV generation to
be handled automatically by the crypto framework by filling this field
.geniv = "eseqiv". Is there a way I can tell the kernel crypto
framework to stop handling IV generation? Even if I remove the .geniv
field it gets set with a default value by the crypto framework. I have
tried .geniv = "" but then when I make a crypto call it does
not use the driver anymore. What are the required things I must do if
I set .geniv = "" ?

static struct crypto_alg algs[] = {
{
.cra_name = "ctr(aes)",
.cra_driver_name = "ctr-aes-omap",
.cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
 CRYPTO_ALG_KERN_DRIVER_ONLY |
 CRYPTO_ALG_ASYNC,
.cra_u.ablkcipher = {
.geniv = "eseqiv",

On Tue, Nov 10, 2015 at 11:24 PM, Herbert Xu
 wrote:
> Orlando  wrote:
>> Hello, I am new to the crypto framework in linux kernel and mailing
>> list in general. I am porting a driver omap-aes.c to my platform and
>> having problems with IV being modified against my will. I am doing
>> AES-128-CTR and I need the IV to increment by 1 every 16 bytes.
>> Instead some garbage IV is being returned to me after I do an encrypt
>> operation.
>>
>> I have no idea how the IV is being manipulated since the omap-aes.c
>> driver accepts and write the IV to the Hardware that comes from upper
>> layers but it never writes it back to the upper layers after doing
>> encryption.
>
> The omap-aes is probably buggy in this regard.  The crypto selftest
> system isn't currently testing this so a number of buggy drivers
> have slipped through.
>
> If you can send us a patch to fix this it would be great.  Otherwise
> I will be working through the drivers during the skcipher conversion.
>
> Thanks,
> --
> Email: Herbert Xu 
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Hardware Crypto Driver

[Orlando]

I will not be able to use your changes since I am running kernel
3.4.48 and I cannot change it for my project (embedded system).

The reason I am suspecting that the crypto framework is
generating/manipulating the IV for my driver is because when I do a
cat /proc/crypto I get two instances of the AES-CTR cipher instance
instead of one. One says

name : ctr(aes)
driver   : ctr-aes-omap
selftest : passed
type : ablkcipher

which is correct and how I want it. However, there is another that
gets automagically added by the crypto framework itself called

name : ctr(aes)
driver   : ctr-aes-omap
selftest : passed
type : givcipher

this second one has the flag CRYPTO_ALG_TYPE_GIVCIPHER set and I read that
CRYPTO_ALG_TYPE_GIVCIPHER  = Asynchronous multi-block cipher packed
together with an IV generator (see geniv field in the /proc/crypto
listing for the known IV generators)

as you can see, it says that it has a IV generator. I also read that I
can supply some callbacks for me to handle IV manipulation myself in
the driver by adding these fields
.cra_u.ablkcipher = {
.givencrypt = omap_givencrypt,
.givdecrypt = omap_givdecrypt,

However, they never seems be get called. It seems they are only
supported for AEAD.

givencrypt
Update the IV for encryption. With this function, a cipher
implementation may provide the function on how to update the IV for
encryption.

givdecrypt
Update the IV for decryption. This is the reverse of givencrypt

I have taken a look at others crypto hardware drivers implementation
and I do not see them manipulating or returning back the resulting IV
after the hardware operation is done. Which makes me believe the IV
incrementing/etc (CTR) is being handled by software in the kernel
crypto framework. I see the omap-aes.c driver receives the IV from the
crypto framework (comes from my user space openssl app) and writes it
into the hardware crypto engine. After the hardware finishes
encrypting the plaintext the IV has been incremented but this new IV
is not being written back into the kernel crypto framework to go back
to my user app.

What would I have to do to make sure the correct IV gets back to the user?


On Wed, Nov 11, 2015 at 10:02 AM, Herbert Xu
 wrote:
> On Wed, Nov 11, 2015 at 09:54:37AM -0500, Orlando wrote:
>> I think the main problem might be my lack of understanding how IVs are
>> handled by the kernel crypto framework. It seems the omap-aes.c driver
>> is indicating to the crypto framework that it wants IV generation to
>> be handled automatically by the crypto framework by filling this field
>> .geniv = "eseqiv". Is there a way I can tell the kernel crypto
>> framework to stop handling IV generation? Even if I remove the .geniv
>> field it gets set with a default value by the crypto framework. I have
>> tried .geniv = "" but then when I make a crypto call it does
>> not use the driver anymore. What are the required things I must do if
>> I set .geniv = "" ?
>
> geniv is completely unrelated to this.  In fact, in the current
> kernel geniv is no longer used and I will remove it once the skcipher
> conversion is done.
>
> Cheers,
> --
> Email: Herbert Xu 
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Hardware Crypto Driver

[Herbert Xu]

Orlando  wrote:
> Hello, I am new to the crypto framework in linux kernel and mailing
> list in general. I am porting a driver omap-aes.c to my platform and
> having problems with IV being modified against my will. I am doing
> AES-128-CTR and I need the IV to increment by 1 every 16 bytes.
> Instead some garbage IV is being returned to me after I do an encrypt
> operation.
> 
> I have no idea how the IV is being manipulated since the omap-aes.c
> driver accepts and write the IV to the Hardware that comes from upper
> layers but it never writes it back to the upper layers after doing
> encryption.

The omap-aes is probably buggy in this regard.  The crypto selftest
system isn't currently testing this so a number of buggy drivers
have slipped through.

If you can send us a patch to fix this it would be great.  Otherwise
I will be working through the drivers during the skcipher conversion.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html