Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> wrote: > > I am not in favor of just hacking in this split until the semantics are > > actually understood. As said, the right solution from my point of view is > > to remove setkey from akcipher and replace it with setkeyid instead. > > It's the keys system that should not be decoding the keys since > it doesn't know what to do with them. The keys system should not > have any algorithm-specific knowledge in it. You need to have > algorithm-specific knowledge to parse the keys, so that's why > the parsing should happen in the crypto API and not in the key > storage system. You're right and wrong, I think. The asymmetric key type should be calling akcipher to do the algorithmic stuff, yes, *but* the key must also be parsed on loading to check that the bits we require for a particular algorithm are there. Now this could be done by starting up an akcipher blob and loading the key data into it to see if it croaks on initialisation (which will presumably check the contents of the data blob), but we wouldn't necessarily be able to actually *use* the key at this point. David -- 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
