On Tue, Oct 11, 2022 at 02:01:45PM -0600, Jason A. Donenfeld wrote: > > I've got no stake in this, but isn't the whole idea that if you specify > "aes" you get AES, and if you specify "cbc(aes)" you get AES-CBC, and so > forth? And so leaking implementation details into the algorithm name > feels like it breaks the abstraction a bit. Well, keys stored in hardware are fundamentally incompatible with the algorithm/implementation model. The whole point of having algorithms with multiple implementations (e.g., drivers) is that they all provide exactly the same functionality and could be substituted at will. This completely breaks down with hardware keys because by definition the key is stored in a specific piece of hardware so it will only work with a particular driver. IOW it almost never makes sense to allocate "aes" if you have a hardware key, you almost always want to allocate "aes-mydriver" instead. > Rather, drivers that do AES should be called "aes". For this hardware > key situation, I guess that means keys have a type (in-memory vs > hardware-resident). Then, a crypto operation takes an "algorithm" and a > "key", and the abstraction then picks the best implementation that's > compatible with both the "algorithm" and the "key". No the key is already in a specific hardware bound to some driver. The user already knows where the key is and therefore they know which driver it is. > If you don't want a proliferation of different ways of doing the same > thing, maybe the requirement should be that the author of this series > also converts the existing "paes" kludge to use the new thing he's > proposing? Yes that would definitely be a good idea. We should also talk to the people who added paes in the first place, i.e., s390. Cheers, -- Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt