Discussion about a reasonable API is ongoing, but I'll give some
review comments anyway -- including some of my thoughts on why the
crypt_r API is not ideal -- in case they're helpful.
--- include/unistd.h 15 Oct 2021 22:32:28 - 1.162
+++ include/unistd.h 12 Feb 2022 12:47:04
> Date: Wed, 16 Feb 2022 10:27:08 -0500 (EST)
> From: Mouse
>
> > Thi is an essential hardening step against FPGA/custom ASIC
> > implementations.
>
> I can't help feeling that there should be better ways to do that. I
> like the idea of resistance to such things, but, for at least my
>
On Wed, Feb 16, 2022 at 10:27:08AM -0500, Mouse wrote:
> That sounds like a recipe for disaster. It is a complete fail for
> heterogenous environments where the same hash needs to be checkable on
> widely disparate hardware, where a small machine may not have the
> resources to perform the check
> Given that malloc will cache any reasonable small allocation anyway,
> we are talking about a few dozen or 100 cpu cycles for an operation
> that is expected to take several orders of magnitude more.
I wouldn't be concerned about CPU time costs, no. I'm more concerned
about malloc _failing_.
> All modern password hashing algorithms use a large memory buffers and
> will attempt to scale them according to system ressources.
So merely attempting to log in *requires* a major fraction of the
amount of memory the system had when the password was set?
That sounds like a recipe for
Am Tue, Feb 15, 2022 at 05:25:10PM -0800 schrieb Konrad Schroder:
> Of course the clearest use-case for crypt_r(3) is a password cracker: each
> thread sets up its own local memory and blasts through calls to crypt_r(3)
> as fast as it can. I've run a cracker as a white-hat. But I can see not
>
Am Tue, Feb 15, 2022 at 08:04:29PM -0500 schrieb Mouse:
> > Given that the goal of the crypt(3) interface is to be slow,
> > optimizing a memory allocation away saves nothing, except making a
> > more complicated interface.
>
> I disagree. It saves a bunch of error paths. Many (most? all?) of
Am Tue, Feb 15, 2022 at 03:58:30PM -0800 schrieb Jason Thorpe:
> There really should be a function that takes a user name or ID and a
> cleartext password string, and IPCs to another (trusted system) process
> to do the verification, so that programs that want to verify passwords
> don’t need root
