> -----Original Message----- > From: Herbert Xu [mailto:herbert@xxxxxxxxxxxxxxxxxxx] > Sent: Tuesday, June 14, 2016 12:35 PM > To: Benedetto, Salvatore <salvatore.benedetto@xxxxxxxxx> > Cc: linux-crypto@xxxxxxxxxxxxxxx > Subject: Re: [PATCH v8 1/3] crypto: Key-agreement Protocol Primitives API > (KPP) > > On Mon, Jun 13, 2016 at 10:55:46PM +0100, Salvatore Benedetto wrote: > > > > +struct kpp_alg { > > + int (*set_secret)(struct crypto_kpp *tfm, void *buffer); > > Sorry I think we need to change this. Leaving this with no type checking > between the user and the driver is a recipe for disaster. > > I think the easiest solution is to use either BER encoding like rsa.c or netlink > encoding like authenc.c. > My very first patch used PKCS3 and there were some objections to that. https://patchwork.kernel.org/patch/8311881/ Both Bluetooth or keyctl KEYCTL_DH_COMPUTE would have to first pack the key to whatever format we choose and I don't see that very convinient. We only want to provide the acceleration here, without bounding the user to a certain key format. akcipher is different as PKCS1 is a recognized standard for RSA keys. Please don't get me wrong, it's not much of an issue for me to respin the patchset and change that to PKCS3 for example, but I see no harm in leaving it as it is and moving the key check format to whatever upper layer is using us (like BT and keyctl). Just more work for who is using the API. Could you reconsider that? Thanks, Salvatore -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
