On Thu, May 24, 2018 at 07:09:27PM -0500, Denis Kenzior wrote: > > But seriously, how is it a fault of the 'random person on the mailing list' > that AF_ALG exists and is being used for its (seemingly intended) purpose? > > I'm not really here to criticize or judge the past. AF_ALG exists now. It > is being used. Can we just make it better? Or are we going to whinge at > every user that tries to use (and improve) kernel features that (some) > people disagree with because it can 'compromise' kernel security? Another point of view is that it was arguably a mistake, and we shouldn't make it worse. > > Also, if speed isn't a worry, why not just a single software-only > > implementation of SHA1, and be done with it? It's what I did in > > e2fsprogs for e4crypt. > > If things were that simple, we would definitely not be having this exchange. > Lets just say we use just about every feature that crypto subsystem provides > in some way. What I'm saying here is if you need to code PBPDF2 in user-space, it _really_ isn't hard. I've done it. It's less than 7k of source code to implement SHA512: https://ghit.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/tree/lib/ext2fs/sha256.c and then less than 50 lines of code to implement PBPDF2 (I didn't even bother putting in a library such as libext2fs): https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/tree/misc/e4crypt.c#n405 This is all you would need to do if we don't put PBPDF2 in the kernel. Is it really that onerous? If you don't want to use some crypto library, I don't blame you --- I just grabbed the code and dropped it into e2fsprogs; so I understand that POV. And so if you want to keep using AF_ALG, we made a mistake, created an attractive nuisance, and we have to support it forever. Fine. But we don't have to add more _stuff_ into the kernel.... - Ted
