Could the obsoletion of all Rfc2898DeriveBytes constructors be reconsidered?

[koszeggy]

Though .NET 10 is not released yet, unfortunately the conversation of #97221 created by @vcsjones is now closed, so I created this discussion instead.

I've read the obsoletion reasoning, and also watched the video attached by @terrajobst, but I still don't quite get it why is it such a big issue if I use the Rfc2898DeriveBytes class in 'streaming mode' as you guys called it when one calls GetBytes multiple times. I understand that the non-.NET implementations are usually not prepared for that and calling it in one shot is better, but making this approach obsolete suggests that it's actually worse than suboptimal: it can be a security issue.

If you just haven't found examples for such a use case, there are multiple examples or even recommended ways (eg. here, here or here) when IV is also generated by PBKDF2, and up to now it was really convenient to use Rfc2898DeriveBytes in 'two shots'.

Or is there something fundamentally wrong with generating also the IV like that? I performed a little research and found some pages where exactly this question is asked (eg. here, here and here). I'm not a security expert and the answers do not always agree, but if I'm not mistaken the answers saying it's not secure misunderstood the behavior of GetBytes, thinking, it is stateless and it works like the static Pbkdf2 method, returning always the same sequence for a specific length.

Of course, I can refactor my code to create a big enough buffer first, call Pbkdf2 once, and then slice the result to achieve the same result as before (which I really must do if I don't want to explain why I have to suppress an obsolete warning on a security-related class) but it results in a longer code, doing the same thing as before, just in a more complicated way.

[bartonjs]

One reason is the perf:

Method	iters	Mean	Allocated
ViaCtor	1000	878.7 us	576 B
ViaCtor_OneCall	1000	881.1 us	552 B
ViaStatic	1000	709.4 us	104 B
ViaCtor	10009	8,980.9 us	579 B
ViaCtor_OneCall	10009	8,788.9 us	555 B
ViaStatic	10009	7,086.3 us	106 B
ViaCtor	100000	87,808.1 us	612 B
ViaCtor_OneCall	100000	87,600.9 us	588 B
ViaStatic	100000	70,670.1 us	131 B

Calling via the static methods is 12% faster for the same inputs (on my machine just now). For PBKDF, you should really be picking a number of iterations based on the maximum amount of time you're willing to churn, so "faster" doesn't mean "faster", it means "I get to pick a bigger number of iterations".

To answer the obvious question, "no, we can't make the constructor-based approach faster". The 12% speedup is from getting to call a native function with "let's do PBKDF2" instead of implementing it in .NET. It's not that .NET is slower here, it's that Rfc2898DeriveBytes calls IncrementalHash AppendData, then GetHashAndReset, a number of times based on the iteration count. AppendData is going to call (e.g.) BCryptHashData, which is going to then route based on the current algorithm before it gets to the right algorithm's update handler, then invoke that handler and do the work. GetHashAndReset will call (e.g.) BCryptFinishHash, which similarly has to go through a layer of routing to get to the right final answer. The native implementation gets to figure out, once, "which update routine" and "which finishing routine" behind all of its indirection, and then invoke the backing functions iterations times, removing a minimum of 4 * iterations function calls. Function calls are cheap, sure, but 400k of them starts to add up.

There's a second reason, which is that NIST SP 800-132 declares PBKDF2 an approved algorithm for deriving keys from passwords. https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/details?product=20032 shows that PBKDF is one of the algorithms that can (could?) be certified under the CAVP FIPS-Certified program, and in context that almost certainly means PBKDF2. Workloads that are sensitive to FIPS concerns therefore are likely to give the Spock eyebrow at "there's a certified version you could use, and it's faster, but you don't use it... 'because'...?".

There's also a question of "why are you deriving the IV?" There are a lot of cases where you're going to want to lock the salt and keep allowing the same password to be used over time, but each fresh encryption with it wants a new IV; so the IV should normally just be random, not a generated value.

Code using the constructors and instance methods is functionally correct. If the above reasons don't matter to you, or don't sway you, you can suppress SYSLIB0060. But, no, we won't be un-obsoleting it.