KWallet format optimization potential

[solardiz]

There's optimization potential for the KWallet format, especially for the old KDF:

1. The old KDF is unsalted, but we treat different wallets as different salts (because the trial decryption needs to be separate per wallet). We may implement our usual "keys changed" logic to compute the KDF just once for all old-wallet salts (all old wallets being cracked simultaneously). This would require global storage of the KDF output, which right now is in a temporary array on the stack.
2. BTW, it seems pointless to have that array mentioned above - could as well be just one variable for the current derived key (or an array of SIMD size when we use SIMD, which we do for the new KDF) - unless we make it global and reuse it as per the above. If the array is made global for the above, it should probably only be used for the old KDF (the new KDF may use its own SIMD-sized local array), as such split will help us continue to support cracking of a mix of old and new wallets at once.
3. The old KDF splits long passwords into up to 4 chunks. We could cache and conditionally recompute (or not) KDF output portions for those depending on whether they changed e.g. relative to what was in the same slot the last time. When cracking long passwords, probably not all chunks will be changing all the time. This optimization may be tricky to have along with adding SIMD.
4. The old KDF is currently implemented without SIMD. We could implement it with SIMD.
5. Regardless of KDF (old or new), we could decrypt just one Blowfish block most of the time, not the 56 bytes that we decrypt every time now.

Out of the above, items 1, 3, 4 will result in substantial speedup for some uses. Items 2 and 5 will not (are minor relative to other performance costs).