Rewrite in pure Rust?

[nabijaczleweli]

No description provided.

[newpavlov]

Would you like to consider making it part of the RustCrypto?

[nabijaczleweli]

What'd that entail and how'd it affect me/this project/other people?

[newpavlov]

Until we have pure Rust implementation with the same API as other hash functions in RustCrypto nothing will change, after we write it (me, you or someone else) in my opinion it would be ideal to republish this project under blake-ffi (or similar name) and to use blake crate for pure Rust implementation which will be developed in RustCrypto/hashes. To make sure what we will be able to publish updates afterwards you can either transfer ownership of crate or grant write access to owners of RustCrypto.

One problem I see is the 1.0 status. API change of such scale will be a breaking change, so if we are to strictly comply to semver we'll have to publish it under 2.0, but I am not yet certain about API stability for RustCrypto (e.g. API will definitely change when type level integers will be introduced to Rust), so ideally I would like to publish it under <1.0 version and it will require yanking currently published 1.0 versions.

So users of this crate will face either bump to 2.0 (and potentially later to 3.0 and higher) or yanked 1.0 versions.

Of course we can publish pure Rust version under another name, this will not require anything from you nor from crate users. But one downside of this will be permanent confusion for those who will search for cryptographic hashes on crates.io as blake will not share the same interface as other hash functions (currently 9 and more in future) and will not have same properties (pure Rust, no_std capability).

[nabijaczleweli]

change, after we write it (me, you or someone else) in my opinion it would be ideal to republish this project

Yeah, alright (but I sure as hell ain't rewriting this damn algorithm in Rust the third time).

able to publish updates afterwards you can either transfer ownership of crate or grant write access

Once you have a working impl.

change, so if we are to strictly comply to semver we'll have to publish it under 2.0, but

Obviously, yes.

would like to publish it under <1.0 version and it will require yanking currently published 1.0 versions

Nah, if it ain't got compilation-affecting errors it ain't getting yanked.

face either bump to 2.0 (and potentially later to 3.0 and higher) or yanked 1.0

Former sounds much better (see up).

publish pure Rust version under another name, this will not

Nah, reusing this one is fine.

[newpavlov]

Thank you for cooperation!
For now I'll add blake to this list. If no one will take it, I'll implement it. (though it will be after I'll rework blake2 based on blake2-rfc implementation)

Nah, if it ain't got compilation-affecting errors it ain't getting yanked.

Ok, as you wish. Another possible solution is to publish new version under 1.2 while saving the old API for backward compatibility. This way we'll be able to hold off 2.0 until Digest trait will change. (hope it will be only on stabilisation of type level integers)