[gnutls-devel] GnuTLS | crypto-api: add gnutls_aead_cipher_{en, de}crypt_vec (!1052)

[Development of GNU's TLS library]

Merge request https://gitlab.com/gnutls/gnutls/merge_requests/1052 was reviewed by Simo Sorce

--
  
Simo Sorce started a new discussion on lib/crypto-api.c: https://gitlab.com/gnutls/gnutls/merge_requests/1052#note_201528179

> +		}
> +
> +		ret = copy_to_iov(&ptext, iov, iovcnt);

Ok, so I was wondering about ptext.size here and I was really confused.

It seem you are using the difference between size and capacity in iov_store to keep the tag from being copied and copying in later.

That's pretty hard to figure out, I would not use this trick to cope with the gnutls_aead_cipher_encrypt() api, I would leave iov_store always faithfully represent the size of the store with the size field, and keep track in the functions that needed it (like this one) whether there is extra data in there.

I would add an optional size parameter to copy_to_iov() so that you can truncate the copy short if needed as in this case instead.

So in this function you would call:
```
 copy_to_iov(&ptext, iov, iovcnt, ptext.size - _tag_size);
```

--
  
Simo Sorce started a new discussion on lib/iov.c: https://gitlab.com/gnutls/gnutls/merge_requests/1052#note_201528185

> +		iter->iov_offset = 0;
> +	}
> +	return GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE;

Still trying to figure out if an io vector with a size that is not an exact multiple of the block_size is legal or not.

If it is legal this code can incorrectly fail with GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE if the last io vector is < block_size

If it is illegal I think you should return a different error like GNUTLS_E_RECEIVED_ILLEGAL_PARAMETER, because it is not that data is missing but that it does not conform to the expected parameter sizes I think, but that may be subject to interpretation, feel free to ignore if GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE is normally used to express a function parameter is not ok size wise.


-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1052
You're receiving this email because of your account on gitlab.com.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20190808/23fc76d3/attachment.html>