proposal: x/crypto/blake2[b|s]: Implement personalisation and salting

[str4d]

The current implementations of BLAKE2b and BLAKE2s support both variable output lengths and keyed BLAKE2 (blake2b, blake2s), but do not yet enable setting the personalisation and salt sections of the parameter block. Personalisation in particular is becoming more commonplace in BLAKE2's usage within cryptographic protocols. It would be beneficial both inherently and for interoperability if the BLAKE2 implementations provided an interface for instantiating the digest state with a personalisation string and/or a salt.

[str4d]

@FiloSottile

[tv42]

For anyone looking for personalization/salt ASAP: I know of two abandoned projects that had that feature: https://github.com/codahale/blake2 and https://github.com/minio/blake2b-simd

[FiloSottile]

Sounds like the API would look like

type Options struct {
    Size uint32
    Key []byte
    Personalization string
    Salt []byte
}

func NewWithOptions(*Options) hash.Hash

func NewXOFWithOptions(*Options) XOF

Anybody see any way to simplify it?

[FiloSottile]

Do we need for both Blake2b and Blake2s? The latter doesn't even have arbitrary size hashes right now. #32417

[tv42]

Perhaps it's worth noting that blake3 switched away from salt & personalization. It still has derive_key (constant string, hash material) and keyed_hash (hash material, key) modes. So personalization & salt might not end up seeing as much adoption as they would have if blake3 hadn't happened.

[elichai]

Sounds like the API would look like

type Options struct {
    Size uint32
    Key []byte
    Personalization string
    Salt []byte
}

func NewWithOptions(*Options) hash.Hash

func NewXOFWithOptions(*Options) XOF

Anybody see any way to simplify it?

Why is size needed for non-XOF hashes?

I think it's either this API or a builder-pattern of sort, where you optionally input key/salt/personalization

Perhaps it's worth noting that blake3 switched away from salt & personalization. It still has derive_key (constant string, hash material) and keyed_hash (hash material, key) modes. So personalization & salt might not end up seeing as much adoption as they would have if blake3 hadn't happened.

I don't think we should consider blake3 here, it's way newer than blake2 and will take time before it can be considered a good choice for real world security applications IMO ( https://twitter.com/oconnor663/status/1257078936917377024 )

I'd really like to see this API implemented, I consider domain separation a huge security feature

[FiloSottile]

Why is size needed for non-XOF hashes?

How would you select the hash output size otherwise?

[elichai]

Why is size needed for non-XOF hashes?

How would you select the hash output size otherwise?

i'd add the options to the New256/New384/New512 but I guess it's too late for that, and adding 3 more functions might be too much

[elichai]

Sounds like the API would look like

type Options struct {
    Size uint32
    Key []byte
    Personalization string
    Salt []byte
}

func NewWithOptions(*Options) hash.Hash

func NewXOFWithOptions(*Options) XOF

Anybody see any way to simplify it?

@FiloSottile Friendly ping :), yeah this API should work for us, (I'm interested in the hash.Hash one, but I assume this is also a good API for the XOF option). I will use it like this:

hasher, _ := blake2b.NewWithOptions(&Options{Personalization: "MyHash"})

Thanks! (I can also help with implementation/review if you want :) )

[FiloSottile]

Actually, the New functions should return an error.

type Options struct {
    // Size is the output size of the function. It must be up to 64 for
    // hashes, and up to 2**32-1 or OutputLengthUnknown for XOFs.
    Size            uint32
    // Key turns the function into a MAC. It can be up to 64 bytes for
    // hashes, and up to 32 for XOFs. It can be nil.
    Key             []byte
    // Personalization can be up to 16 bytes. It can be empty.
    Personalization string
    // Salt can be up to 16 bytes. It can be empty.
    Salt            []byte
}

func NewWithOptions(*Options) (hash.Hash, error)

func NewXOFWithOptions(*Options) (XOF, error)

This looks good to me to implement.

@rsc can we get this on the active proposal queue?

[austinast]

Hi @rsc @FiloSottile May I know when will this proposal be implemented? Thanks

[lukewhrit]

Any ETA?