Re: libnettle/libhogweed WIP

[Ted Zlatanov]

On Sat, 15 Jul 2017 12:15:20 +0300 Eli Zaretskii <address@hidden> wrote: 

EZ> What I see (without really understanding what should happen) is that
EZ> gnutls-symmetric-decrypt returns a string that is 32-byte long,
EZ> whereas the original input before encryption was a 16-byte string.  In
EZ> the decrypted string, the first 16 bytes are identical to the input
EZ> before encryption, the rest seem to be binary garbage.  When the
EZ> original 16-byte input is encrypted by gnutls-symmetric-encrypt, the
EZ> result is a 32-byte string.  All of this happens in the first call to
EZ> encryption and decryption functions produced by the loop in
EZ> test-gnutls-005-aead-ciphers.  Does this makes sense and/or ring any
EZ> bells?  Do you need me to provide any further information?

EZ> The version of GnuTLS library I have here is 3.4.15, btw.

The size of the output is determined by the cipher's parameters. So we
need to know the parameters, which are in cplist.

Can you capture the full parameters and memory buffers passed into the
GnuTLS functions?

Here's the sequence we expect in the test, this in a let* form:

1. The IV may be actual data or it may be a list of 'iv-auto and ivsize
which tells extract_data_from_object() to generate a random IV (which is
returned as the second element by `gnutls-symmetric-encrypt').

2. We call (gnutls-symmetric-encrypt cplist (copy-sequence key) iv input 
(copy-sequence auth))

3. We need to make sure the cplist, key, iv, input, and auth make it
down to the GnuTLS C functions.

4. We need to look at the output returned from the GnuTLS C function and
make sure it makes it to the return of `gnutls-symmetric-encrypt'
together with the actual IV used.

5. We need to do the same as steps 1-4 for decryption.

If you can provide a recipe for testing your case, that would be
helpful. I may be able to duplicate it in a Docker container.

Ted