Thread (39 messages) 39 messages, 6 authors, 2017-10-03

Re: [PATCH v8 3/4] crypto: AF_ALG -- add asymmetric cipher

From: Tudor Ambarus <hidden>
Date: 2017-08-21 09:24:17


On 08/21/2017 11:55 AM, Tudor Ambarus wrote:
Hi, Stephan,
quoted
quoted
quoted
+static int akcipher_setprivkey(void *private, const u8 *key,
+                   unsigned int keylen)
+{
+    struct akcipher_tfm *tfm = private;
+    struct crypto_akcipher *akcipher = tfm->akcipher;
+    int err;
+
+    err = crypto_akcipher_set_priv_key(akcipher, key, keylen);
+    tfm->has_key = !err;
+
+    /* Return the maximum size of the akcipher operation. */
+    if (!err)
+        err = crypto_akcipher_maxsize(akcipher);
crypto subsystem returns zero when setkey is successful and introduces
a new function for determining the maxsize. Should we comply with that?
The idea is that only when the the setting of the priv key fails, it 
returns
the size of the expected privkey.

Which new function are you referring to?
I was referring to crypto_akcipher_maxsize. When
crypto_akcipher_set_priv_key fails, you are overwriting it's return
value with the value of crypto_akcipher_maxsize, hiding the cause of
the error.
Oops, I missed the negation. When crypto_akcipher_set_priv_key succeeds
you return the akcipher_maxsize. Not a bad idea, you save few cpu
cycles.
crypto akcipher uses a dedicated function for determining the length of
the output buffer, crypto_akcipher_maxsize. Should we add a new function
pointer in struct af_alg_type that returns the maxsize?
Your API is different from crypto's akcipher. Should we make them
identical?

Cheers,
ta
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help