... basically inlining static QCH::hash(), which, however, accepts
only one piece of data, while we have two.
Avoids the memory allocation of the QCH d-pointer. The toByteArray()
is now the only memory allocation left in finalizeUnchecked(), and
will be removed in a subsequent commit.
Pick-to: 6.5
Change-Id: I7549d6e1c116a4cdc29dac74b867dfa6647022a0
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Rename it to QSmallByteArray, and make the maximum size a template
argument. Initialize m_size to 0, to avoid a partially-formed
default-constructed objects (default-constructed containers should
always be in the empty state).
As a drive-by, fix placement of some {'s.
Don't move it into a header of its own, yet, as it lacks a lot of
features expected of a generally-reusable class. Maybe one day.
This is in preparation of re-using the class to hold the key in
QMessageAuthenticationCode.
Pick-to: 6.5
Change-Id: Iee77e03e50afdf2ebc5889feeead344bef8ab3e8
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
... from the end().
It was lonely down there, and prone to be overlooked when performing
early returns in the #ifdef'ery above, as witnessed by the early
returns in the OpenSSL3 code.
Amends 1fe74c3bd3f727551b8168ee9f3e642d42233d55, itself amending
633c1365966eda89fc883c039683a727d0a0813e.
Pick-to: 6.5
Change-Id: I8c941ecb5c4755d8823b2161544cf6f7fe75a239
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
They share so many things, and QMAC is lacking so many of the changes
QCH has received over the last few months, that it seems QMAC is
better off being implemented in the QCH TU.
Among other things, this will allow QMAC to use QCHPrivate for its
implementation, drastically reducing the number of memory allocations
required to perform HMAC operations.
Pick-to: 6.5
Change-Id: I3c81a52e3a9ad57c14c91c16bc347f215fd407ba
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This brings the code in line with the sibling code in
QMessageAuthenticationCode, which now has a simiar split between
finalize() and finalizeUnchecked().
Pick-to: 6.5
Change-Id: I10701d59d56617ab32fae0df47371f0464e9cc77
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
QIODevice::read(ptr, n) returns qint64, not int. The returned values
are, however, confined to the interval [-1,1024], so no harm
done. Make the narrowing explicit, though.
Pick-to: 6.5
Change-Id: I5f95292ca6e05f0f402e7258e590593eff361255
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The previous attempt at fixing QTBUG-110058,
ccad719d2e935306e601b0f6af5ff2acb7cd272e, was incomplete:
- the if (result.isEmpty()) check at the beginning of finalize() was
not protected, so it raced against the assignment at the end of
finalize(), which was protected
- because the mutex was not locked during the finalization of the hash
algorithm, two threads could perform this operation simultaneously,
which isn't such a bad idea in principle, as it can reduce latency,
but for that to work, the losing thread needs to throw away its own
work and adopt the work of the other thread, but that wasn't done:
both threads would write their result to 'result', just one after
the other, but that's still a data race, since the eventual _reader_
of the result cannot be protected (is outside the class). Besides,
we don't even know whether the algorithm-specific finalization
functions are ok with being called from separate threads on the same
context object
- in addition, the mutex wasn't necessary when finalize() was called
from the static hash() function, as no sharing could possibly take
place there (the state is function-local)
Fix all of the above by largely reverting the first attempt, dragging
the result.isEmpty() check out of finalize() and into resultView() and
instead simply holding the mutex over these two calls in
resultView(). To see why this is sufficient, consider that
resultView() is now idempotent again: the result is written once, the
next thread waits and then finds the work done. All following accesses
to the result are then reads, which happen-after the write at the end
of finalize().
The accesses to 'result' from reset() need no protection, as reset()
is a mutable function, and calling a mutable function on a shared
QCryptographicHash object is already UB. Only two const functions may
be called that way.
Pick-to: 6.5 6.4 6.2 5.15
Fixes: QTBUG-110058
Change-Id: Ia8ac095b785519682090801c1012e9dded6d60b2
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
There is no benefit from storing return value from some OpenSSL calls as
the only thing we do is to ignore them. There is also no difference when
we would be returning earlier.
Pick-to: 6.5
Change-Id: I76c742016a2532c65ffdcd913aafc74a2d1a9623
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
OpenSSL doesn't allow to add additional data when the hash has been
finalized. To fix that, we just make a copy of the current context
and call EVP_DigestFinal_ex() on the copy so we can still later add
additional data.
Pick-to: 6.5
Change-Id: If76d4ec56f8846d6ef55ed7ec7cbab440d43edd0
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
QCryptographicHashPrivate::SmallByteArray is a 65-byte type, so there
were 7 bytes of padding at the end of QCryptographicHashPrivate anyway.
Pick-to: 6.5
Change-Id: Ide4dbd0777a44ed0870efffd17394e1d5431e052
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
QCryptographicHash::result() and resultView() are const, therefore two
threads can call them on the same object. Given that the finalization of
the hash is not a trivial operation but doesn't modify the state, let's
do it without a locked mutex, onto a temporary stack buffer. Then we lock
the mutex to copy said result to our cached value.
Pick-to: 6.5 6.4 6.2 5.15
Fixes: QTBUG-110058
Change-Id: Ide4dbd0777a44ed0870efffd17394bf72785eabb
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
So we don't have to do these reinterpret_cast everywhere, as most of the
APIs we're calling take unsigned chars themselves. The reinterpret_casts
will be removed in the next commit, which needs to modify those lines
anyway.
Pick-to: 6.5 6.4 6.2 5.15
Change-Id: Ide4dbd0777a44ed0870efffd17394f9f25062122
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This is unnecessary and basically doesn't have any effect.
Pick-to: 6.5
Change-Id: I6b63e989c43bdcd55bf83d2c0756da2de1ab49df
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Adds QCH::supportsAlgorithm() method which returns whether the selected
algorithm is supported and we guarantee to get a result when generating
hashes. OpenSSL will be responsible for providing us this information.
Returns TRUE if OpenSSL is not used as a provider.
[ChangeLog][QtCore][QCryptographicHash] Add supportsAlgorithm() method
that can be used to query OpenSSL and check whether the selected
algorithm is supported.
Pick-to: 6.5
Change-Id: I0d94e02b8c70beb79520150fab6c32bdd1da3fca
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
OpenSSL implementation did not clear the previous result when
calling QCH::reset(). This could lead to not generating new hashes.
Pick-to: 6.5
Change-Id: Ic83e6382038a2f8808af950b88e57316b90ef2bc
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
MSVC 2022. Must have been some indirect include I'm modifying.
qcryptographichash.cpp(266): error C2079: 'QCryptographicHashPrivate::SmallByteArray::m_data' uses undefined class 'std::array<char,64>'
Change-Id: I3d74c753055744deb8acfffd172492257099f14d
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
OpenSSL by default doesn't provide static libraries and we would fail to
build it in such case.
Fixes: QTBUG-106978
Change-Id: I456fe9bec2bbef5003de8f6cb7d9d8bb226821f9
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Use OpenSSL 3.0 as a provider of all hashing algorithms, except the
BLAKE2b and BLAKE2s. BLAKE2b and BLAKE2s algorithms support a variable
length digest, but OpenSSL's implementation outputs only a digest of a
fixed length (the maximum length supported). This is 512-bits for the
BLAKE2b and 256-bits for the BLAKE2s and for that reason we still use
the original implementation.
[ChangeLog][QtCore][QCryptographicHash] Uses the OpenSSL 3.0
implementation now, where available.
Change-Id: Ia4e4139b92ea9b40a18aa480aa5c06562178f916
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
This can be helpful when you calculate multiple hashes, store them in a
vector and you want to know which result belongs to which algorithm.
[ChangeLog][QtCore][QCryptographicHash] Added getter algorithm().
Change-Id: Ifcf78536f215619a6e2e3035a95598327d0ed733
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
This adds a move constructor, a move assignment operator and a swap
function to QCryptographicHash. This can (to name one example) be useful
when you want to store multiple hashes in a vector.
[ChangeLog][QtCore][QCryptographicHash] Added move constructor, move
assignment operator and swap() function.
Change-Id: Id54594fa69104ec25ad78581f962a021e85531c2
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Replace the current license disclaimer in files by
a SPDX-License-Identifier.
Files that have to be modified by hand are modified.
License files are organized under LICENSES directory.
Task-number: QTBUG-67283
Change-Id: Id880c92784c40f3bbde861c0d93f58151c18b9f1
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Still not complete. Just grepping for static and thread_local.
Task-number: QTBUG-100486
Change-Id: I90ca14e8db3a95590ecde5f89924cf6fcc9755a3
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Rename the resize() function of its internal buffer into the possibly
better resizeForOverwrite(). The point is that unlike an ordinary resize
the data in the buffer is NOT initialized, and therefore must be
overwritten by the caller, "or else".
Change-Id: I7d82821e92f59f7eeab18c51d98003826ffe164b
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Øystein Heskestad <oystein.heskestad@qt.io>
This reverts commit 6deded8bc42d5275c08039812c388a3c593244df.
Reason for revert: The new SHA-3 implementation cannot generate digest noexcept, which is required by the QCryptographicHash API.
Task-number: QTBUG-71327
Change-Id: I9a49acd529090d479c7d5e9583dd25e0ec669806
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Only QByteArray has a toHex() member, QByteArrayView doesn't.
Since toHex() is linked to from result() already, remove it here
to avoid the wrong impression that there was a toHex() that doesn't
require any memory allocation.
Change-Id: I76f876aca90403baebf9328b794aeaf9be698c46
Reviewed-by: Luca Di Sera <luca.disera@qt.io>
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
* name method parameters consistently with their declaration
* don't document parameters that are not there
Pick-to: 6.2
Change-Id: I06ae9fdca357ed29eb7a72802f149eb4914181f4
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
The maximum size for a hash result is 64 atm. Even if, and esp when,
we'll get to 128 and 256 bytes in the future, there's no reason to use
dynamic memory, because the sizes will always be statically known.
So use, essentially, a std::array<char, 64> to hold the result
internally. Add a bit of convenience API on top to limit impact on the
rest of the code and add a few static_asserts that ensure this is large
enough. Then give users access to the internal buffer by adding
QByteArrayView resultView() const noexcept. The documentation snippet
is taken from QString::data(), suitably adjusted.
Use resultView() in a few places instead of result().
[ChangeLog][QtCore][QCryptographicHash] Changed to use a
statically-sized buffer internally. Added resultView() to access it.
Change-Id: I96c35e55acacbe94529446d720c18325273ffd2f
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Now that calling hashLengthInternal() is cheap, use it to factor
common code in switch statements. For sha3, that would have been
possible before, too. Reason for duplicating the case bodies is
unclear.
Change-Id: I281617546e0b3e701315eee2f10df8d26ada92ae
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Just create it on the stack, we know the lifetime.
Reduces memory allocations in static hash() from 2 to 1.
Change-Id: Ie0e22b023331da9a6f39c80b4cd1a5c016f63a87
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
...and use it internally.
Exported symbols are LD_PRELOADable, so the compiler might not
constant-fold calls to them. Besides, it's a requirement for a
follow-up change.
Change-Id: I437f46d7d42ed0a6921dee3027a471e2aa52baa1
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
It never changes, making it const might improve code-gen.
Change-Id: Ife8723e27ae9cf6cfcca48d58d46307003123354
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Incl. the static hash() function. Remove the QByteArray versions from
the API, but not the ABI.
Adapt some callers.
[ChangeLog][QtCore][QCryptographicHash] Replaced QByteArray with
QByteArrayView in addData() and static hash() functions.
Change-Id: Ia0e9bf726276305e05894d323d76a29e985f39eb
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Need to decrement 'remaining' (check), but also increment data (meep).
Testing is a bit complicated, as most algorithms are just too slow to
fit into the 5min QTestLib timeout. Picked the fast ones and Sha512
(which completes here in < 17s, with threads), at least.
Amends e12577b56396cca0df05f88f8787706a3a12c82d.
[ChangeLog][QtCore][QCryptographicHash] Fixed a bug where presenting
more than 4GiB in a single addData() call would calculate the wrong
result().
Pick-to: 6.1 6.2
Change-Id: Ic72916ebc33ba087d58225af6d8240e46e41f434
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
We don't build on platforms without stdint.h
Change-Id: Iee9de3e71a7bcae524f2d1377919cf074a713960
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This adds the option to build Qt with libb2, which is especially
recommended, if you care about the performance of the BLAKE2 hashing
algorithms. The bundled version is the pure reference C implementation
of BLAKE2, while libb2 has many additional hardware optimizations.
However, the API of both is the same, so no changes to the code were
necessary here.
Change-Id: I3563982f4e07be300291fe103c38b16a404b3ebb
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
BLAKE2 does not specify requirements about specific hash sizes and
since QCryptographicHash does not support dynamic hash sizes, only the
most common hash sizes could be covered by this.
The supported hash sizes were chosen to match the ones supported by the
Linux kernel.
The new hashing algorithms for QCryptographicHash are:
* BLAKE2b (160 bit, 256 bit, 384 bit, 512 bit)
* BLAKE2s (128 bit, 160 bit, 224 bit, 256 bit)
[ChangeLog][QtCore][QCryptographicHash] Added BLAKE2b and BLAKE2s
hashing algorithms.
Fixes: QTBUG-78198
Change-Id: Id9e0180a974093982fdf1cdd6180988a2e5e9f4f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
A union member lifetime does not start automatically if one
takes a pointer to a union member and writes into the member.
Only the subscript syntax in an assignment features such
automatic lifetime start [class.union§6].
In the other cases, one is allowed to get a pointer to the
storage ([basic.life§6]) but has to start lifetime explicitly
via placement new. Hence, do so, or we end up in UB land.
We're left with the problem of reset() which may be called
multiple times. I think we can actually just create a new
object in the same storage without destroying the pre-existing
object by exploiting [basic.life§5]: reusing the storage causes
lifetime end for the old object. Moreover, since the union
is over trivial datatypes (C structs), there's no side effects
in the destructor of the old object, so there is no need
to call it.
Drive by fix, apply some DRY for SHA3.
Change-Id: Idc351568635e59d45421311f043956ab3aabf389
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Linus Jahn <lnj@kaidan.im>
Because 256 MB * 8 = 2 Gbit, but length*8 is a signed integer overflow,
hence UB.
Can't really autotest this. Not all systems where we're going to test
can allocate 256 MB of RAM.
[ChangeLog][QtCore][QCryptographicHash] Fixed a bug that caused the
SHA-3 and Keccak algorithms to crash if passed 256 MB of data or more.
Fixes: QTBUG-77362
Change-Id: Iec9c051acd73484c8d94fffd15b91f4b1450f5d7
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
ALIGN macro exists in RTEMS system headers and in sha3 library.
Change-Id: I00cbb5be5598a6a6ca1f011f199da62d658ef9d5
Reviewed-by: Ryan Chu <ryan.chu@qt.io>
It's useful when you need to check how long a hash will be without first
generating one.
[ChangeLog][QtCore][QCryptographicHash] Add a static method, hashLength,
which returns the length of the output of a hash function in bytes.
Change-Id: Id6a454016523de83d157fd95c50105c6db4bb1d9
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Commit 12c5264d9add1826d543c36d893db77262195fc6 fixed the calculation of
SHA-3 in QCryptographicHash: we were previously calculating Keccak.
Unfortunately, turns out that replacing the algorithm wasn't the best
idea: there are people who need to compare with the result obtained from
a previous version of Qt and stored somewhere. This commit restores the
enum values 7 through 10 to mean Keccak and moves SHA-3 to 12 through
15. The "Sha3_nnn" enums will switch between the two according to the
QT_SHA3_KECCAK_COMPAT macro.
[ChangeLog][Important Behavior Changes] This version of Qt restores
compatibility with pre-5.9.0 calculation of QCryptographicHash
algorithms that were labelled "Sha3_nnn": that is, applications compiled
with old versions of Qt will continue using the Keccak algorithm.
Applications recompiled with this version will use SHA-3, unless
QT_SHA3_KECCAK_COMPAT is #define'd prior to #include
<QCryptographicHash>.
[ChangeLog][Binary Compatibility Note] This version of Qt changes the
values assigned to enumerations QCryptographicHash::Sha3_nnn.
Applications compiled with this version and using those enumerations
will not work with Qt 5.9.0 and 5.9.1, unless QT_SHA3_KECCAK_COMPAT is
defined.
Task-number: QTBUG-62025
Discussed-at: http://lists.qt-project.org/pipermail/development/2017-September/030818.html
Change-Id: I6e1fe42ae4b742a7b811fffd14e418fc04f096c3
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Compilation and link times in CPU seconds with GCC 7, using precompiled
headers (not including moc, rcc, uic, etc. steps or headersclean):
Before After
Debug -O0 198,1 180,3
Debug -Og 240,7 229,2
Release -O3 267,1 249,2
Release LTO 239,4 229,8
QtCore required a little manual adjusting because some files are
bootstrapped into moc itself and into qmake.
Change-Id: I84e363d735b443cb9beefffd14b8b57c10e7da36
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
The SHA3 family is a modified version of Keccak. We were
incorrectly calculating Keccak (and even *testing* Keccak!),
but claiming it was SHA3.
To actually calculate SHA3, we need invoke Keccak on the original
message followed by the two bits sequence 0b01, cf. §6.1 [1].
[1] http://dx.doi.org/10.6028/NIST.FIPS.202
[ChangeLog][QtCore][QCryptographicHash] QCryptographicHash now
properly calculates SHA3 message digests. Before, when asked
to calculate a SHA3 digest, it calculated a Keccak digest instead.
Task-number: QTBUG-59770
Change-Id: Iae694d1a1668aa676922e3e00a292cddc30d3e0d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
