New package: CryptographicHashFunctions v0.0.1

[JuliaRegistrator]

• Registering package: CryptographicHashFunctions
• Repository: https://github.com/erich-9/CryptographicHashFunctions.jl
• Created by: @erich-9
• Version: v0.0.1
• Commit: b90ee62685e1463fb0aac01ecfc0bf2da8d29fd9
• Reviewed by: @erich-9
• Reference: erich-9/CryptographicHashFunctions.jl@b90ee62#commitcomment-141228010
• Description: Fast cryptographic hash functions for Julia

[github-actions]

Your new package pull request met all of the guidelines for auto-merging and is scheduled to be merged when the mandatory waiting period (3 days) has elapsed.

Since you are registering a new package, please make sure that you have read the package naming guidelines: https://pkgdocs.julialang.org/v1/creating-packages/#Package-naming-guidelines

---

If you want to prevent this pull request from being auto-merged, simply leave a comment. If you want to post a comment without blocking auto-merging, you must include the text [noblock] in your comment. You can edit blocking comments, adding [noblock] to them in order to unblock auto-merging.

[stemann]

What is the scope of this package in relation to the existing packages, e.g. in JuliaCrypto ?

It seems a substantial part of this package is wrappers (which should be named accordingly)?

[noblock]

[erich-9]

Yes, for now it's all wrappers. But isn't this an implementation detail? Why would they require special naming?

The scope is convenience. Recently, I needed fast SHA-3 functions. Since the ones provided by SHA.jl are not particularly fast, I decided to create a package with the same API but with faster implementations. For another motivation see the issue JuliaCrypto/SHA.jl#90.

[noblock]

[erich-9]

@stemann Since your comment is blocking the merge, do you expect me to make any changes?

[noblock]

[stemann]

I have not looked much at cryptography in Julia, but it seems Nettle.jl and SEAL.jl follow the common practice of having one Julia wrapper package per binary dependency (JLL) - in line with the naming guidelines, point 6: Packages that wrap external libraries or programs should be named after those libraries or programs.

The discussion in JuliaCrypto/SHA.jl#90 (comment) also argues for wrappers in separate packages (e.g. a HACL* wrapper).

This packages wraps two binaries.

CryptographicHashFunctions is a quite general name - hence the question to scope. Is this package or does it strive to be the canonical (pure Julia) interface to cryptographic hash functions?

… there is also already OpenSSL.jl - which probably should wrap OpenSSL JLL: JuliaCrypto/OpenSSH.jl#1

[noblock]

[erich-9]

Is this package or does it strive to be the canonical (pure Julia) interface to cryptographic hash functions?

This place is already taken by SHA.jl I believe. However, it could be a "canonical" interface for fast implementations of these functions. This would be helpful given that SHA.jl doesn't intend to provide hardware-accelerated versions.

Basically this package is the would-be package HashlibAcc.jl mentioned in JuliaCrypto/SHA.jl#90. It wraps (or potentially could also implement itself) the fastest currently available version of each hash function without unnecessarily exposing to the user where this implementation comes from (... probably from OpenSSL, but maybe it's a fall-back from HACL* ...).

@stemann Do you see any way to solve the issue without including the name of wrapped packages? Would another name be okay for you (e.g. FastSHA.jl or AcceleratedSHA.jl or the name HashlibAcc.jl suggested by the SHA.jl maintainers)? Honestly, I would rather stick with the current name but if you think it's necessary I can live with a change.

[noblock]

[stemann]

I think this has had enough consideration from my side - unblocking my comments.

[noblock]