| Age | Commit message (Collapse) | Author |
|---|
|
Apart from being pretty ambiguous in general, the term "context string"
has the specific problem that it isn't clear whether it should be
describing the input or the output. In fact, it's quite important that
it describes the output, because the whole point is to domain-separate
different outputs that derive from the *same* input. To make that
clearer, rename the "context string" to the "purpose string" in
documentation.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The previous version of this API called for a key of exactly 256 bits.
That's good for optimal performance, but it would mean losing the
use-with-other-algorithms property for applications whose input keys are
a different size. There's no way for an abstraction over the previous
version to provide reliable domain separation for the "extract" step.
|
|
These things are totally equivalent, and I keep going back and forth,
but now I think this is slightly clearer.
|
|
This is clearer, and because of padding requirements it doesn't change
the size of the Hasher struct. (We have a test for this.)
|
|
|
|
|
|
Also use fewer array references (the compiler doesn't care) be more
explicit with a `new_cv` mutable variable. This clarifies
push_chunk_chaining_value just a bit. Since that's the trickiest
function in the entire thing, it's good to clarify it. (It also gets
excerpted directly into the spec.)
|
|
|
|
|
|
|
|
This is simpler than sometimes incrementing by CHUNK_LEN and other times
incrementing by BLOCK_LEN.
|
|
Smaller chunk sizes are a big benefit for parallelism at shorter input
lengths, and recent benchmarks show that this reduction has a relative
small cost in terms of peak throughput. It's also a nice round number.
|
|
This fits better with the current wording of the spec.
|
|
|
|
|
