Rfc2898DeriveBytes should reuse arrays during chained HMAC invocations.

[bartonjs]

Rfc2898DeriveBytes provides an implementation for the PBKDF2 algorithm.

This algorithm does quite a lot of HMAC.ComputeHash calls, each of which marshals back and forth to native code and creates a byte[] to emit the answer into.

• Windows: BCryptDeriveKeyPBKDF2
• macOS: CCKeyDerivationPBKDF
• Other-*nix (OpenSSL): PKCS5_PBKDF2_HMAC (present in 1.0.1)

[bartonjs]

A minor complication here is that Rfc2898DeriveBytes lets you keep calling GetBytes as if it were a stream (GetBytes(16).Concat(GetBytes(16)) is the same as GetBytes(32)); and all of the native implementations are one-shot.

There certainly exist buffered workarounds, but I'm wondering if it's going to introduce more complexity than it's worth...

• Always ask the native implementation, do local offsetting
  • N^2, where N is the number of calls to GetBytes
    • Assume all calls are asking for full blocks:
      • First call asks for one block, quick.
      • Second call asks for one block, two blocks computed (repeating work from step 1), first block skipped.
      • Repeat.
• Use native unless (some criteria), then switch to managed
  • At some point the perf changes significantly, but probably not for most callers
• Leave it all as managed
  • Predictable
• Leave it all as managed, and at some point add a ComputeHash overload to HashAlgorithm which provides an array (span?) to write into, avoiding the blocks*iterations array allocations, and update this to make use of it
  • Potential win for everyone?

[bartonjs]

Having thought about it a bit more, plan 4 seems the best (reduce the allocations) in terms of supportability and compatibility.

Since we're going to make this as an incremental improvement and not a Hail-Mary it no longer feels like we need to rush to get it in for 2.0.

[bartonjs]

Already fixed, just wasn't tagged.