mirror of
https://github.com/BLAKE3-team/BLAKE3
synced 2024-04-28 01:15:12 +02:00
copy the same notes to the C docs
This commit is contained in:
parent
ea3bc782d8
commit
153d46e11a
39
c/README.md
39
c/README.md
|
@ -106,17 +106,7 @@ Finalize the hasher and return an output of any length, given in bytes.
|
|||
This doesn't modify the hasher itself, and it's possible to finalize
|
||||
again after adding more input. The constant `BLAKE3_OUT_LEN` provides
|
||||
the default output length, 32 bytes, which is recommended for most
|
||||
callers.
|
||||
|
||||
Outputs shorter than the default length of 32 bytes (256 bits) provide
|
||||
less security. An N-bit BLAKE3 output is intended to provide N bits of
|
||||
first and second preimage resistance and N/2 bits of collision
|
||||
resistance, for any N up to 256. Longer outputs don't provide any
|
||||
additional security.
|
||||
|
||||
Shorter BLAKE3 outputs are prefixes of longer ones. Explicitly
|
||||
requesting a short output is equivalent to truncating the default-length
|
||||
output. (Note that this is different between BLAKE2 and BLAKE3.)
|
||||
callers. See the [Security Notes](#security-notes) below.
|
||||
|
||||
## Less Common API Functions
|
||||
|
||||
|
@ -199,6 +189,33 @@ multithreading support in the future, and if `blake3_hasher` holds (optional)
|
|||
threading resources, this function will reuse those resources. Until then, this
|
||||
is mainly for feature compatibility with the Rust implementation.
|
||||
|
||||
# Security Notes
|
||||
|
||||
Outputs shorter than the default length of 32 bytes (256 bits) provide less security. An N-bit
|
||||
BLAKE3 output is intended to provide N bits of first and second preimage resistance and N/2
|
||||
bits of collision resistance, for any N up to 256. Longer outputs don't provide any additional
|
||||
security.
|
||||
|
||||
[_Block-Cipher-Based Tree Hashing_ by Aldo Gunsing](https://eprint.iacr.org/2022/283) shows
|
||||
that an extended BLAKE3 output doesn't protect the secrecy of its offset — that is the number
|
||||
of output bytes that came before, or the argument to
|
||||
[`seek`](struct.OutputReader.html#method.seek) or
|
||||
[`position`](struct.OutputReader.html#method.position) — as well as it ideally could. Callers
|
||||
who rely on secret output lengths or offsets need to pay attention to this, but the vast
|
||||
majority of callers use constant and/or public lengths and offsets and aren't affected.
|
||||
|
||||
The underlying issue is that the BLAKE3 compression function is invertible if an attacker
|
||||
already knows the message and the key and also observes an extended output. In particular,
|
||||
inverting the compression function doesn't require knowing the internal `t` parameter that
|
||||
represents the offset. In other words, an output offset doesn't contribute any entropy towards
|
||||
protecting its own secrecy or the secrecy of other inputs. However, the offset does benefit
|
||||
from the entropy of the message and the key, so for example a caller using a 256-bit secret key
|
||||
is also not affected.
|
||||
|
||||
For comparison, AES-CTR has a similar property. If you know the key, you can decrypt a block
|
||||
from an unknown position in the output stream to recover its block index. However, the Salsa
|
||||
and ChaCha stream ciphers don't have this property, because they feed their offsets forward
|
||||
into their output.
|
||||
|
||||
# Building
|
||||
|
||||
|
|
Loading…
Reference in New Issue