aboutsummaryrefslogtreecommitdiff
path: root/crypto/pbkdf-gcrypt.c
AgeCommit message (Collapse)Author
2024-11-05crypto: Introduce SM3 hash hmac pbkdf algorithmliequan che
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>
2024-09-10qapi/crypto: Rename QCryptoHashAlgorithm to *Algo, and drop prefixMarkus Armbruster
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]
2024-09-09crypto: check gnutls & gcrypt support the requested pbkdf hashDaniel P. Berrangé
Both gnutls and gcrypt can be configured to exclude support for certain algorithms via a runtime check against system crypto policies. Thus it is not sufficient to have a compile time test for hash support in their pbkdf implementations. Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-07-19crypto: Fix LGPL information in the file headersThomas Huth
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>
2017-09-04qapi: Mechanically convert FOO_lookup[...] to FOO_str(...)Markus Armbruster
Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <1503564371-26090-14-git-send-email-armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2016-09-19crypto: support more hash algorithms for pbkdfDaniel P. Berrange
Currently pbkdf is only supported with SHA1 and SHA256. Expand this to support all algorithms known to QEMU. Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2016-09-19crypto: use uint64_t for pbkdf iteration count parametersDaniel P. Berrange
The qcrypto_pbkdf_count_iters method uses a 64 bit int but then checks its value against INT32_MAX before returning it. This bounds check is premature, because the calling code may well scale the iteration count by some value. It is thus better to return a 64-bit integer and let the caller do range checking. For consistency the qcrypto_pbkdf method is also changed to accept a 64bit int, though this is somewhat academic since nettle is limited to taking an 'int' while gcrypt is limited to taking a 'long int'. Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2016-07-12Use #include "..." for our own headers, <...> for othersMarkus Armbruster
Tracked down with an ugly, brittle and probably buggy Perl script. Also move includes converted to <...> up so they get included before ours where that's obviously okay. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Tested-by: Eric Blake <eblake@redhat.com> Reviewed-by: Richard Henderson <rth@twiddle.net>
2016-03-22include/qemu/osdep.h: Don't include qapi/error.hMarkus Armbruster
Commit 57cb38b included qapi/error.h into qemu/osdep.h to get the Error typedef. Since then, we've moved to include qemu/osdep.h everywhere. Its file comment explains: "To avoid getting into possible circular include dependencies, this file should not include any other QEMU headers, with the exceptions of config-host.h, compiler.h, os-posix.h and os-win32.h, all of which are doing a similar job to this file and are under similar constraints." qapi/error.h doesn't do a similar job, and it doesn't adhere to similar constraints: it includes qapi-types.h. That's in excess of 100KiB of crap most .c files don't actually need. Add the typedef to qemu/typedefs.h, and include that instead of qapi/error.h. Include qapi/error.h in .c files that need it and don't get it now. Include qapi-types.h in qom/object.h for uint16List. Update scripts/clean-includes accordingly. Update it further to match reality: replace config.h by config-target.h, add sysemu/os-posix.h, sysemu/os-win32.h. Update the list of includes in the qemu/osdep.h comment quoted above similarly. This reduces the number of objects depending on qapi/error.h from "all of them" to less than a third. Unfortunately, the number depending on qapi-types.h shrinks only a little. More work is needed for that one. Signed-off-by: Markus Armbruster <armbru@redhat.com> [Fix compilation without the spice devel packages. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-03-17crypto: add support for PBKDF2 algorithmDaniel P. Berrange
The LUKS data format includes use of PBKDF2 (Password-Based Key Derivation Function). The Nettle library can provide an implementation of this, but we don't want code directly depending on a specific crypto library backend. Introduce a new include/crypto/pbkdf.h header which defines a QEMU API for invoking PBKDK2. The initial implementations are backed by nettle & gcrypt, which are commonly available with distros shipping GNUTLS. The test suite data is taken from the cryptsetup codebase under the LGPLv2.1+ license. This merely aims to verify that whatever backend we provide for this function in QEMU will comply with the spec. Reviewed-by: Fam Zheng <famz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>