BLAKE-family hashing within Transit Secrets Engine

[HariAmoor-professional]

Is your feature request related to a problem? Please describe. I'm using Vault+Consul+Nomad in open-source to automate my homelab. I'd like to store crypto keys using Transit Secrets Engine, but I need BLAKE-224 and BLAKE-256 hashing with Ed25519 signatures.

Describe the solution you'd like Transit already supports Ed25519 according to the spec; however, it remains to support BLAKE-family hashing. I'd like this done.

Describe alternatives you've considered I'm currently storing my keys as a KV-pair in Consul. This is fine, but then the value would have to be injected into the application. I'd prefer to have support in Transit instead so it's not needed to inject anything.

Explain any additional use-cases It'd help the encryption story, as this scheme is perhaps the most secure mainstream asymmetric encryption possible.

[schultz-is]

Howdy, @HariAmoor-professional! Support for the BLAKE family of hash functions in Transit isn't on our roadmap to support, but we're happy to review any PR from the community that adds this.

One important thing to note though is that go's Ed25519 library (which Vault makes use of) doesn't support arbitrary hash functions for signature generation or verification. Input can only be prehashed with SHA-512 for Ed25519ph or unhashed for standard Ed25519 operation.

[HariAmoor-professional]

Go's Ed25519 library doesn't support arbitrary hash functions

@schultz-is Looking at the doc you linked, it supports any of the crypto.Hash variations, which include the BLAKE-2B functions I need. I could be wrong, but would it not be simple to implement given this consideration?

Granted, it doesn't support 224-bit BLAKE, but that's something I could live without.

Let me know your thoughts!

Edit: I could be wrong on this too; it might not generalize over the full range of crypto.Hash.

[cipherboy]

AFAICT, sign doesn't support a WithOptions variant, but only Verify does: https://pkg.go.dev/crypto/ed25519#Sign vs https://pkg.go.dev/crypto/ed25519#VerifyWithOptions -- but the private key signing variety does support crypto.Hash options: https://pkg.go.dev/crypto/ed25519#PrivateKey.Sign

Looking at the implementation for Sign, it doesn't seem like it does what you want: https://cs.opensource.google/go/go/+/refs/tags/go1.21.0:src/crypto/ed25519/ed25519.go;l=79-117

Can you point us to a reference implementation that pairs BLAKE+ed25519 in this way? AFAIK, according to the spec (https://datatracker.ietf.org/doc/html/rfc8032#section-5.1), even ed25519ph requires SHA-512 and this is not configurable. A different choice of hash function would best be applied as raw-curve-op(sha512(blake(msg))), and not as raw-curve-op(blake(msg)).

[HariAmoor-professional]

Like I said, I could be mistaken; you may be right in that signing doesn't support WithOptions. I'll let you know when/if I look into it.

[veorq]

@HariAmoor-professional Just my 2 cents (as co-author of BLAKE): you may consider using the most recent and much faster BLAKE3 hash function, which is formally defined as a C2SP specs.