Previously, we assume the existence of a incomplete block at
end of the input. However, it's possible that input's an exact
multiple of block size. In this case, the first argument of
process_final_incomplete_block() will be one-past-the-last
element, the second argument will be zero. This' an ill-defined
call, and it will trigger an assertion failure of std::vector
Assertion '__builtin_expect(__n < this->size(), true)' failed.
This commit introduced a check. If we see the length of the last
incomplete block is zero, we call
process_final_incomplete_block(NULL, 0);
which immediately finalizes CubeHash without hashing additional
data.
Although it should be changed to
state.process_final_incomplete_block (a.data() + a.size(),
a.size() - i);
It hides the possibility of passing an out-of-bound element to
the function, so it's better to be explicit.
Signed-off-by: Tom Li <tomli@tomli.me>
In load_key_vector(), the program passes a std::vector<byte> to
a C-style function, load_key (const byte*begin, const byte*end)
by creating references
load_key (& (K[0]), & (K[K.size()]));
However, accessing the one-past-the-last element in a std::vector
via [] is not allowed in C++, it triggers an assertion failure.
Assertion '__builtin_expect(__n < this->size(), true)' failed.
In this commit, we use K.data() and K.data() + K.size() to expose
the underlying pointers and pass them to the C function.
Signed-off-by: Tom Li <tomli@tomli.me>
Note that the CMakeLists.txt file is not included in autotools dist package to
avoid any packaging confusion. `configure.ac` is still the primary
build-configuration information source. (Btw isn't there a way to build
CMakeLists.txt from autotools?)
Well, there's a reason for that test vectors are published on wikipedia.
Although this looks scary (like writing past array bounds), cubehash B
parameter is in all cases smaller than 63 (which is the first B value where
this would write behind the array), so no harm is done. For similar reason, the
"misimplemented" cubehash was cryptographically correct (i.e. without
cryptographic weakness), only implemented differently and producing different
results than those prescribed by the standard.
Practical implications of changing the hash functions are:
- everyone gets a new KeyID
- FMTSeq keys that used cubehash are invalid now, users are forced to generate
new ones
Mirek Kratochvil