On 08/03/2015 11:20 AM, Marcel Holtmann wrote: > actually I think this reasoning needs to be revisited. When I look at this, this makes no sense whatsoever. The end result is that we have keys in multiple formats in the kernel and have to convert between them or parse them again. > > If you do not want to use struct public_key, then lets go for struct key as I proposed in my other response. That should in the end be able to represent hardware keys as well. There is really no good reason to move things around and parse them again or create new formats out of it. > > My take is that we want to store a key once in a single location and single location only. Storing the same key in different formats in different locations is just a plain bad idea. Keep it secure and locked in one place. > The approach was not to use any of the existing public key stuff. To be consistent with all the other crypto API tfm needs to "own" the key. The existing struct key is not controlled by the tfm and the key can be gone without tfm knowing. We can change this approach, but this is not my call, but Herbert's. Herbert, any comments? > I hope someone is looking at lib/digsig.c as well and gets this all cleaned up into a single implementation. However for this to happen, we really need to get this key stuff figured out. Right now this looks to me like the left hand does not know what the right hand is doing. Yes, your are right, but crypto/public_key/rsa.c and lib/digsig.c have been added long before akcipher. Now we are trying to get all this fixed, but we need to have stable API before any of it will be converted. Thanks, T -- 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
