Zig: General crypto api improvements

[Rocknest]

• consider moving Md5, Sha1 to new unsafe/legacy namespace, document that all algorithms in it are not cryptographically secure. It may be a place for DES #4157. Same for some block cipher modes #5763.

• make changes to kdf discussed in #6336.
  1) password kdfs should be in their own namespace done
  2) implement another kdf and come up with a unified api.
  suggestion Pbkdf2(HmacSha1).init(iterations, salt?).deriveKey(outSlice)
  3) maybe add an alias/wrapper for Blake3 kdf mode
  4) suggestion: restrict size of derived key that Pbkdf2 accepts (spec allows maxInt(u32) * hash.digest_size)
   

• when making changes use arrays instead of slices if a fixed buffer is required #5851

[daurnimator]

• consider moving Md5, Sha1 to new unsafe/legacy namespace, document that all algorithms in it are not cryptographically secure. It may be a place for DES #4157. Same for some block cipher modes #5763.

I don't think this is a good idea. Also see https://github.com/ziglang/zig/pull/6095#discussion_r473170318

• make changes to kdf discussed in #6336.
• password kdfs should be in their own namespace

Agreed

1. implement another kdf and come up with a unified api.
   suggestion Pbkdf2(HmacSha1).init(iterations, salt?).deriveKey(outSlice)

Consider implementing bcrypt or scrypt.
Also consider looking at the openssl api. I've worked on that a bit e.g. https://github.com/openssl/openssl/issues/9139

[jedisct1]

consider moving Md5, Sha1 to new unsafe/legacy namespace

This is something that has been discussed before, but the consensus was to improve the documentation for these functions rather than move them to a legacy namespace.

MD5 and SHA1 are required by many applications and by Zig itself. But it more difficult to justify DES and unauthenticated modes in a recent project, even less so in the standard library of a new programming language.

Performance of our implementations is currently very poor due to the absence of optimized implementations. Maybe this is something to focus on first (and it has implications on the API, too , such as the way the AES core functions is exposed) before adding more constructions, especially legacy ones.

Pbkdf2(HmacSha1).init(iterations, salt?).deriveKey(outSlice)

Shouldn't the salt be mandatory?

[andrewrk]

I just want to put one piece of guidance here which I think I am qualified to make:

• Focus more on making each API independently secure, optimized, correct, type-safe, etc. Worry less about trying to make all the APIs conform to similar interfaces, or making them iterable with reflection or whatever.

[jedisct1]

Consider implementing bcrypt or scrypt.

Argon2 may be better a candidate. The reason being that unlike bcrypt/scrypt, it can share code with the existing BLAKE2 implementation, so that the same optimizations can be shared. But doing so will require some refactoring. It is a better case to study than another primitive that is very similar to PBKDF2.

[daurnimator]

It is a better case to study than another primitive that is very similar to PBKDF2.

I thought it would be best to study something quite far removed from PBKDF2 so that assumptions are more general.

[jedisct1]

It is a better case to study than another primitive that is very similar to PBKDF2.

I thought it would be best to study something quite far removed from PBKDF2 so that assumptions are more general.

Yes, this is exactly why I would suggest Argon2 instead of bcrypt, which is very close to PBKDF2.