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.
  1. password kdfs should be in their own namespace

Agreed

2. 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.

[x13a]

What do you think of scrypt key derivation function in std? I have ported one from go. Suppose that it is good to have common used crypto primitives build in. For example scrypt used by crypto-currencies and python has it in std. I see that bcrypt already there.

[jedisct1]

@x13a sure, that would be a nice addition, and the implementation looks great.

Maybe it could reuse the existing Salsa20 core function instead of embedding its own copy, so that it can benefit from the vectorized implementation. This requires a change to the current API in order to support reduced rounds, but that's not a bad thing to have. Scrypt is also used for password storage, so adding the standard parameters encodings would also be useful. Your repo is a better place to discuss this :)

[jedisct1]

Also, for memory-hard functions, we probably want the scratch buffer to be a function parameter. The size may not be known at comptime, and more importantly, we probably don't want gigabytes of memory right on the stack :)

[dralley]

This is just my personal opinion, but crypto seems like the sort of thing you wouldn't want in the standard library, precisely because of the huge number of different algorithms which may at any time in the future quickly fall out of favor (and new ones constantly being created). There's a tension between the goal of the standard library - "provide basic, useful functionality that we will never break" and the goal of a security library, which often needs to be a bit more opinionated (even if that means marking functionality deprecated, moving them to unsafe namespaces, etc.)