Commit Graph

13 Commits

Author SHA1 Message Date
Ján Tomko
ac9ad77303 Remove explicit check for gnutls_rnd
Introduced in gnutls 2.12, but we require gnutls >= 3.2
Check added by commit <2d23d14>.

Signed-off-by: Ján Tomko <jtomko@redhat.com>
2018-05-16 10:40:40 +02:00
Ján Tomko
c25fbbec68 virCryptoHashBuf: return the length of the hash in bytes
virCryptoHashString also needs to know the size of the returned hash.
Return it if the hash conversion succeeded so the caller does not need
to access the hashinfo array.

This should make virCryptoHashString build without gnutls.
Also fixes the missing return value for the virCryptoHashBuf stub.

Signed-off-by: Ján Tomko <jtomko@redhat.com>
Suggested-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
2018-05-16 10:40:40 +02:00
Ján Tomko
799011bbe7 vircrypto: Rely on GnuTLS for hash functions
Ditch the use of gnulib's digest functions in favor of GnuTLS,
which might be more likely to get FIPS-certified.

Signed-off-by: Ján Tomko <jtomko@redhat.com>
2018-05-14 14:05:21 +02:00
Ján Tomko
0eeedd61a9 Introduce virCryptoHashBuf
A function that keeps the hash in binary form instead of converting
it to human-readable hexadecimal form.

Signed-off-by: Ján Tomko <jtomko@redhat.com>
2018-05-14 13:57:45 +02:00
Daniel P. Berrange
71890992da Fix padding of encrypted data
If we are encoding a block of data that is 16 bytes in length,
we cannot leave it as 16 bytes, we must pad it out to the next
block boundary, 32 bytes. Without this padding, the decoder will
incorrectly treat the last byte of plain text as the padding
length, as it can't distinguish padded from non-padded data.

The problem exhibited itself when using a 16 byte passphrase
for a LUKS volume

  $ virsh secret-set-value 55806c7d-8e93-456f-829b-607d8c198367 \
       $(echo -n 1234567812345678 | base64)
  Secret value set

  $ virsh start demo
  error: Failed to start domain demo
  error: internal error: process exited while connecting to monitor: >>>>>>>>>>Len 16
  2017-05-02T10:35:40.016390Z qemu-system-x86_64: -object \
    secret,id=virtio-disk1-luks-secret0,data=SEtNi5vDUeyseMKHwc1c1Q==,\
    keyid=masterKey0,iv=zm7apUB1A6dPcH53VW960Q==,format=base64: \
    Incorrect number of padding bytes (56) found on decrypted data

Notice how the padding '56' corresponds to the ordinal value of
the character '8'.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2017-05-02 17:27:13 +01:00
Nitesh Konkar
d276da48bc Fix typos and grammar
Signed-off-by: Nitesh Konkar <nitkon12@linux.vnet.ibm.com>
2016-11-23 12:08:15 -05:00
John Ferlan
456ccc14d5 util: Perform proper virRandomBytes return value checking
Document the return value of virRandomBytes as 0 or some errno value and
then make sure all callers make the proper checks.
2016-06-07 10:18:36 -04:00
John Ferlan
896c4862d5 util: Alter virCryptoEncryptData for non GNUTLS builds
Rather than intermixing the ATTRIBUTE_UNUSED - use HAVE_GNUTLS_CIPHER_ENCRYPT
for the whole function instead.
2016-06-07 07:38:25 -04:00
Mikhail Feoktistov
33705aeec0 util: fix build without GNUTLS 2016-05-22 08:53:58 +03:00
John Ferlan
238032505f util: Introduce virCryptoGenerateRandom
Move the logic from qemuDomainGenerateRandomKey into this new
function, altering the comments, variable names, and error messages
to keep things more generic.

NB: Although perhaps more reasonable to add soemthing to virrandom.c.
    The virrandom.c was included in the setuid_rpc_client, so I chose
    placement in vircrypto.
2016-05-20 11:09:05 -04:00
John Ferlan
1ce9c08ab3 util: Introduce encryption APIs
Introduce virCryptoHaveCipher and virCryptoEncryptData to handle
performing encryption.

 virCryptoHaveCipher:
   Boolean function to determine whether the requested cipher algorithm
   is available. It's expected this API will be called prior to
   virCryptoEncryptdata. It will return true/false.

 virCryptoEncryptData:
   Based on the requested cipher type, call the specific encryption
   API to encrypt the data.

Currently the only algorithm support is the AES 256 CBC encryption.

Adjust tests for the API's
2016-05-20 11:09:01 -04:00
Nehal J Wani
03fc0c626d vircrypto: fix Invalid write in virCryptoHashString()
While running vircryptotest, it was found that valgrind pointed out the
following error:

==27453== Invalid write of size 1
==27453==    at 0x4C7D7C9: virCryptoHashString (vircrypto.c:76)
==27453==    by 0x401C4E: testCryptoHash (vircryptotest.c:41)
==27453==    by 0x402A11: virtTestRun (testutils.c:199)
==27453==    by 0x401AD5: mymain (vircryptotest.c:76)
==27453==    by 0x40318D: virtTestMain (testutils.c:782)
==27453==    by 0x3E6CE1ED1C: (below main) (libc-start.c:226)
==27453==  Address 0x51f0541 is 0 bytes after a block of size 65 alloc'd
==27453==    at 0x4A0577B: calloc (vg_replace_malloc.c:593)
==27453==    by 0x4C69F2E: virAllocN (viralloc.c:189)
==27453==    by 0x4C7D76B: virCryptoHashString (vircrypto.c:69)
==27453==    by 0x401C4E: testCryptoHash (vircryptotest.c:41)
==27453==    by 0x402A11: virtTestRun (testutils.c:199)
==27453==    by 0x401AD5: mymain (vircryptotest.c:76)
==27453==    by 0x40318D: virtTestMain (testutils.c:782)
==27453==    by 0x3E6CE1ED1C: (below main) (libc-start.c:226)
==27453==

...and many more.  Two observations: hashstrlen was already set
to include the trailing NUL byte (so writing to hashstrlen as
the array offset was indeed writing one byte beyond bounds), and
VIR_ALLOC_N already guarantees zero-initialization (so we already
have a trailing NUL without needing to explicitly write one).

Signed-off-by: Eric Blake <eblake@redhat.com>
2014-03-12 16:01:30 -06:00
Daniel P. Berrange
3a7fe8d508 Add helper APIs for generating cryptographic hashes
GNULIB provides APIs for calculating md5 and sha256 hashes,
but these APIs only return you raw byte arrays. Most users
in libvirt want the hash in printable string format. Add
some helper APIs in util/vircrypto.{c,h} for doing this.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-03-10 16:39:18 +00:00