crypto: Introduce SM3 hash hmac pbkdf algorithm

Introduce the SM3 cryptographic hash algorithm (GB/T 32905-2016).

SM3 (GB/T 32905-2016) is a cryptographic standard issued by the
Organization of Sta

crypto: Introduce SM3 hash hmac pbkdf algorithm

Introduce the SM3 cryptographic hash algorithm (GB/T 32905-2016).

SM3 (GB/T 32905-2016) is a cryptographic standard issued by the
Organization of State Commercial Cryptography Administration (OSCCA)
as an authorized cryptographic algorithm for use within China.

Detect the SM3 cryptographic hash algorithm and enable the feature silently
if it is available.

Signed-off-by: cheliequan <cheliequan@inspur.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>

show more ...

crypto/hash: avoid overwriting user supplied result pointer

If the user provides a pre-allocated buffer for the hash result,
we must use that rather than re-allocating a new buffer.

Reported-by: Do

crypto/hash: avoid overwriting user supplied result pointer

If the user provides a pre-allocated buffer for the hash result,
we must use that rather than re-allocating a new buffer.

Reported-by: Dorjoy Chowdhury <dorjoychy111@gmail.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>

show more ...

crypto/hash: avoid overwriting user supplied result pointer

If the user provides a pre-allocated buffer for the hash result,
we must use that rather than re-allocating a new buffer.

Reported-by: Do

crypto/hash: avoid overwriting user supplied result pointer

If the user provides a pre-allocated buffer for the hash result,
we must use that rather than re-allocating a new buffer.

Reported-by: Dorjoy Chowdhury <dorjoychy111@gmail.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>

show more ...

crypto/hash: avoid overwriting user supplied result pointer

If the user provides a pre-allocated buffer for the hash result,
we must use that rather than re-allocating a new buffer.

Reported-by: Do

crypto/hash: avoid overwriting user supplied result pointer

If the user provides a pre-allocated buffer for the hash result,
we must use that rather than re-allocating a new buffer.

Reported-by: Dorjoy Chowdhury <dorjoychy111@gmail.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>

show more ...

crypto: drop obsolete back compat logic for old nettle

The nettle 2.x series declared all the hash functions with 'int' for
the data size. Since we dropped support for anything older than 3.4
we can

crypto: drop obsolete back compat logic for old nettle

The nettle 2.x series declared all the hash functions with 'int' for
the data size. Since we dropped support for anything older than 3.4
we can assume nettle is using 'size_t' and thus avoid the back compat
looping logic.

Reviewed-by: Cédric Le Goater <clg@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>

show more ...

crypto/hash-nettle: Remove old hash API functions

Removes old hash implementation in the nettle hash driver.

Signed-off-by: Alejandro Zeise <alejandro.zeise@seagate.com>
Reviewed-by: Daniel P. Berr

crypto/hash-nettle: Remove old hash API functions

Removes old hash implementation in the nettle hash driver.

Signed-off-by: Alejandro Zeise <alejandro.zeise@seagate.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
[ clg: - Fixed spelling in commit log ]
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>

show more ...

crypto/hash-nettle: Implement new hash API

Implements the new hashing API in the nettle hash driver.
Supports creating/destroying a context, updating the context
with input data and obtaining an out

crypto/hash-nettle: Implement new hash API

Implements the new hashing API in the nettle hash driver.
Supports creating/destroying a context, updating the context
with input data and obtaining an output hash.

Signed-off-by: Alejandro Zeise <alejandro.zeise@seagate.com>
[ clg: - Dropped qcrypto_hash_supports() in qcrypto_nettle_hash_new() ]
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>

show more ...

qapi/crypto: Rename QCryptoHashAlgorithm to *Algo, and drop prefix

QAPI's 'prefix' feature can make the connection between enumeration
type and its constants less than obvious. It's best used with

qapi/crypto: Rename QCryptoHashAlgorithm to *Algo, and drop prefix

QAPI's 'prefix' feature can make the connection between enumeration
type and its constants less than obvious. It's best used with
restraint.

QCryptoHashAlgorithm has a 'prefix' that overrides the generated
enumeration constants' prefix to QCRYPTO_HASH_ALG.

We could simply drop 'prefix', but then the prefix becomes
QCRYPTO_HASH_ALGORITHM, which is rather long.

We could additionally rename the type to QCryptoHashAlg, but I think
the abbreviation "alg" is less than clear.

Rename the type to QCryptoHashAlgo instead. The prefix becomes to
QCRYPTO_HASH_ALGO.

Signed-off-by: Markus Armbruster <armbru@redhat.com>
Acked-by: Daniel P. Berrangé <berrange@redhat.com>
Message-ID: <20240904111836.3273842-12-armbru@redhat.com>
[Conflicts with merge commit 7bbadc60b58b resolved]

show more ...

crypto: drop back compatibility typedefs for nettle

Now that we only support modern nettle, we don't need to have local
typedefs to mask the real nettle types.

Reviewed-by: Thomas Huth <thuth@redha

crypto: drop back compatibility typedefs for nettle

Now that we only support modern nettle, we don't need to have local
typedefs to mask the real nettle types.

Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20210514120415.1368922-5-berrange@redhat.com>
Reviewed-by: Willian Rampazzo <willianr@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>

show more ...

crypto: bump min nettle to 3.4, dropping RHEL-7 support

It has been over two years since RHEL-8 was released, and thus per the
platform build policy, we no longer need to support RHEL-7 as a build
t

crypto: bump min nettle to 3.4, dropping RHEL-7 support

It has been over two years since RHEL-8 was released, and thus per the
platform build policy, we no longer need to support RHEL-7 as a build
target. This lets us increment the minimum required nettle version and
drop a lot of backwards compatibility code for 2.x series of nettle.

Per repology, current shipping versions are:

RHEL-8: 3.4.1
Debian Buster: 3.4.1
openSUSE Leap 15.2: 3.4.1
Ubuntu LTS 18.04: 3.4
Ubuntu LTS 20.04: 3.5.1
FreeBSD: 3.7.2
Fedora 33: 3.5.1
Fedora 34: 3.7.2
OpenBSD: 3.7.2
macOS HomeBrew: 3.7.2

Ubuntu LTS 18.04 has the oldest version and so 3.4 is the new minimum.

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20210514120415.1368922-4-berrange@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Willian Rampazzo <willianr@redhat.com>
[thuth: rebased to use .gitlab-ci.d/buildtest.yml]
Signed-off-by: Thomas Huth <thuth@redhat.com>

show more ...

crypto: Fix LGPL information in the file headers

It's either "GNU *Library* General Public License version 2" or "GNU
Lesser General Public License version *2.1*", but there was no "version
2.0" of

crypto: Fix LGPL information in the file headers

It's either "GNU *Library* General Public License version 2" or "GNU
Lesser General Public License version *2.1*", but there was no "version
2.0" of the "Lesser" license. So assume that version 2.1 is meant here.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>

show more ...

crypto: fix function signatures for nettle 2.7 vs 3

Nettle version 2.7.x used 'unsigned int' instead of 'size_t' for length
parameters in functions. Use a local typedef so that we can build with
the

crypto: fix function signatures for nettle 2.7 vs 3

Nettle version 2.7.x used 'unsigned int' instead of 'size_t' for length
parameters in functions. Use a local typedef so that we can build with
the correct signature depending on nettle version, as we already do in
the cipher code.

Reported-by: Amol Surati <suratiamol@gmail.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Tested-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>

show more ...

crypto: hash: add hash driver framework

1) makes the public APIs in hash-nettle/gcrypt/glib static,
and rename them with "nettle/gcrypt/glib" prefix.

2) introduces hash framework, including QCry

crypto: hash: add hash driver framework

1) makes the public APIs in hash-nettle/gcrypt/glib static,
and rename them with "nettle/gcrypt/glib" prefix.

2) introduces hash framework, including QCryptoHashDriver
and new public APIs.

Reviewed-by: Gonglei <arei.gonglei@huawei.com>
Signed-off-by: Longpeng(Mike) <longpeng2@huawei.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>

show more ...

crypto: don't open-code qcrypto_hash_supports

Call the existing qcrypto_hash_supports method from
qcrypto_hash_bytesv instead of open-coding it again.

Signed-off-by: Daniel P. Berrange <berrange@re

crypto: don't open-code qcrypto_hash_supports

Call the existing qcrypto_hash_supports method from
qcrypto_hash_bytesv instead of open-coding it again.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>

show more ...

crypto: implement sha224, sha384, sha512 and ripemd160 hashes

Wire up the nettle and gcrypt hash backends so that they can
support the sha224, sha384, sha512 and ripemd160 hash algorithms.

Signed-o

crypto: implement sha224, sha384, sha512 and ripemd160 hashes

Wire up the nettle and gcrypt hash backends so that they can
support the sha224, sha384, sha512 and ripemd160 hash algorithms.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>

show more ...

crypto: switch hash code to use nettle/gcrypt directly

Currently the internal hash code is using the gnutls hash APIs.
GNUTLS in turn is wrapping either nettle or gcrypt. Not only
were the GNUTLS ha

crypto: switch hash code to use nettle/gcrypt directly

Currently the internal hash code is using the gnutls hash APIs.
GNUTLS in turn is wrapping either nettle or gcrypt. Not only
were the GNUTLS hash APIs not added until GNUTLS 2.9.10, but
they don't expose support for all the algorithms QEMU needs
to use with LUKS.

Address this by directly wrapping nettle/gcrypt in QEMU and
avoiding GNUTLS's extra layer of indirection. This gives us
support for hash functions on a much wider range of platforms
and opens up ability to support more hash functions. It also
avoids a GNUTLS bug which would not correctly handle hashing
of large data blocks if int != size_t.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>

show more ...