an "official" recommended way to mix associated data with a derived key

[blake3-team]

an "official" recommended way to mix associated data with a derived key

[oconnor663]

Another real world hazard is that you can't just change the associated data parameters over time. If you want to add a third parameter (let's say the filesystem type), you need to change the context string in step 1. Otherwise the key you were using for [application stuff] before is now an intermediate subkey, which is no bueno.

If we wanted a scheme that was robust to this, we could imagine some sort of "finalization" step, that distinguishes between intermediate subkeys and output subkeys. But is that really necessary? I feel like encouraging people to reuse the same context string would be a bad precedent.

[Luro02]

What we don't want to do is skip steps entirely

You could use the rust type system for this, for example

pub struct Stage2 {
}

impl Stage2 {
    pub(crate) fn new() -> Self {
        Self {}
    }

    pub fn start_hash(data: &[u8]) {}
}

pub fn init_key(_: &str) -> Stage2 {
    // do something necessary
    Stage2::new()
}

This would make it impossible to call start_hash without calling init_key, so there is no possible way to skip this step.

Alternatively you could also wrap the data in a new type

struct Key(Vec<u8>);

which could then be passed to a function as an argument.

[oconnor663]

Agreed, providing a secure Rust API for key derivation with associated data wouldn't be too hard. But I'm thinking more about providing advice for protocol designers. Or maybe for coders using some other implementation of BLAKE3, in some other language. (Maybe even folks who aren't using BLAKE3.) I'm hoping to define some sort of Right Way to Do It in the abstract.