mheyman / Isopoh.Cryptography.Argon2

Fully managed .Net Core implementation of Argon2
Other
196 stars 9 forks source link

Exploding memory usage #49

Closed robbelroot closed 1 year ago

robbelroot commented 1 year ago

I just installed your library and did nothing special. At program start, I was hashing 3 string (testing purposes). Later, I called Argon2.Verify and nothing else.

My application suddenly exploded to like over 600MB of memory usage - holy hell. I uninstalled the package again and tried to verify, if this was the issue - it was.

I appreciate your time and effort writing this library, but can we do something about this abnormous memory usage? I mean I already read about that "reduce cost blabla" post of the other users, but shouldn't be a standard config pretty much do it as well?

Maybe someone finds a fix / workaround.

(Why am I using a separate issue? Because it's a separate problem: static helper <> instantiation with specified config... :))

mheyman commented 1 year ago

The Argon2 hash uses a lot of memory by design - that is one of the methods it uses to make it hard to discover the password from the hash. There is a memory cost parameter you can set to reduce memory usage, The default uses 64MB as part of the hash - reducing it, of course, reduces the safety of the hash. RFC9106 section 4 recommends much higher amounts of RAM than the default - from 250MiB to 6GiB depending on use (I may have to add helper functions that simplify following those recommendations like Hash9106BackEndServer(...)).

I have started looking into ways of using a contiguous pre-allocated memory buffer that could possibly be reused (if the Argon2 parameters allow). The coding for that isn't trivial. This would remove pressure from the garbage collector on heavily used servers and give developers clear-cut knowledge of the memory cost.

In garbage-collected languages, calling the garbage collector explicitly becomes required when processes allocate memory either in many small chunks rapidly or in larger chunks less often (like Argon2) in such a way that the garbage collector does not perform adequately. Of course, you have to pick times to explicitly call the garbage collector such that the application doesn't suffer.