5

I'm using the C# Argon2 implementation provided through the Isopoh.Cryptography.Argon2 NuGet package (latest version 1.1.2 from here: https://github.com/mheyman/Isopoh.Cryptography.Argon2). Generating and verifying Argon2 hashes is sometimes fast and sometimes extremely slow (several seconds), even though I understand the configuration below to be on the low-cost end.

My Argon2 configuration is as follows:

Type = Argon2Type.HybridAddressing,
Version = Argon2Version.Nineteen,
MemoryCost = 16, //I had this at 2048 and lowered to 16 for testing, still slow
TimeCost = 2,
Lanes = 2,
Threads = 1,
HashLength = 32, 
ClearPassword = true,
ClearSecret = true

This results in Argon2 hashes that show the following configuration header:

$argon2id$v=19$m=16,t=2,p=2$<<hash>>

I wrote a performance profiler and found that the implementation gets (mostly) slower with each iteration after roughly the 10 to 12th iteration even on repeat tests. The slowness is ~2 orders of magnitude or more (going from ~10ms to several seconds), which leads me to believe that there is a garbage collection/memory leak issue.

enter image description here

Alex
  • 75,813
  • 86
  • 255
  • 348

2 Answers2

5

I found that the issue was indeed related to either the Argon2 implementation and/or garbage collection.

Forcing garbage collection via GC.Collect() (which I usually would not advise to do manually) immediately after generating the hash (which includes a using wrap for both the hash instance and the SecureArray<byte> instance, both of which were present already when the issue occurred) removes the odd variance in hash generation speeds.

It also allowed me to tune the parameters to a more secure setting while staying in an ~100-150ms generation time envelope.

enter image description here

Alex
  • 75,813
  • 86
  • 255
  • 348
0

Same here, using Verify() in this libary, memory is constantly and drastically increasing. GC.Collect() after each iteration (obviouisly not recommended) solves the issue.

This unfortunately happens in production while QA missed it (it is felt under heavy load) so we'll either have to switch or to modify the OS library itself.

NOP-MOV
  • 792
  • 2
  • 8
  • 28