On Thu, May 24, 2018 at 12:11:35PM -0500, Denis Kenzior wrote: > > Well, I'm not sure where the laziness comment is coming from. We have at > least two user-space implementations that implement PBKDF on top of AF_ALG. > But a typical invocation of PBKDF runs a couple of thousand iterations. > That is a lot of system call overhead. Would it not be better to fix things > to be more efficient rather than worry about how 'mistakes were made'? Even where there is hardware acceleration, I suspect that it might be more efficient (as in, result in a faster implementation) if the user PBKDF application was changed to use its own in-userspace software implementation. Many/most hardware implementations are optimzied for throughput (e.g., bulk data operations), and it's not obvious to me that once you had the syscall overhead, it's actually faster to use the hardware accleration. Has anyone actually done the experiment and verified that it was in fact a win to use AF_ALG on at least _some_ platform? What about the common cast for most platforms, even those that had some kind of hardware accleration that could only be accessed by the kernel? (Amusing war story: the hardware where we first experimented with ext4 encryption, the hardware "acceleration" offered by the ARM core in question was *slower* than a well-tuned software-only implementation on the same ARM CPU! :-) - Ted
