some strange decryption errors + one enhancement notice

[Simon Josefsson]

Miroslav Kratochvil <exa.exa at gmail.com> writes:

> Well,
> I probably solved it - seems it was roughly the error from a] that I
> described in last post (my error was that I was calling
> gnutls_record_send for the same data, but with different (larger)
> buffer size), sometimes combined with this bug. GnuTLS 2.8.3 with my
> fixed version works perfectly now.

Great!

> I'm not sure whether there shouldn't be some kind of input checking in
> gnutls_record_send - if calling a retry with larger buffer size
> results in output data corruption, I guess it should be avoided.

Yes... although the documentation says to call it again using same
parameters.

> Anyway, this is the diff for that one assert I was missing when
> searching for the problem, I guess it could get helpful sometime:

Indeed, I have added it.

/Simon

> --- lib/gnutls_cipher.c.old	2009-09-11 17:43:18.000000000 +0200
> +++ lib/gnutls_cipher.c	2009-09-11 17:43:38.000000000 +0200
> @@ -571,7 +571,10 @@
>     * 1.0 protocol.
>     */
>    if (pad_failed != 0)
> +  {
> +    gnutls_assert ();
>      return pad_failed;
> +  }
>
>    /* HMAC was not the same.
>     */
>
>
> Thanks for help,
> Mirek Kratochvil
>
>
>
> On Fri, Sep 11, 2009 at 4:28 PM, Simon Josefsson <simon at josefsson.org> wrote:
>> Miroslav Kratochvil <exa.exa at gmail.com> writes:
>>
>>> Hi,
>>>
>>> I'm using GnuTLS library to develop a small and secure networking
>>> tool, see [1]. Recently I came to a very strange problem:
>>>
>>> My application is used for data transfer, and all sockets used are
>>> non-blocking. When there's too much of data to send, it usually comes
>>> to the state that the application needs to write, but socket is full
>>> (resulting in returning a 'would block' from gnutls_record_send() and
>>> waiting for a writeable socket). In these cases, the application
>>> usually starts to randomly fail in this way:
>>
>> Which version?  2.8.2 fixed a bug for non-blocking use:
>>
>> ** libgnutls: Avoid internal error when invoked after GNUTLS_E_AGAIN.
>> Report and patch by Tim Kosse <tim.kosse at filezilla-project.org> in
>> <http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3671>
>> and
>> <http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3670>.
>>
>> I'm not sure it is the same as you are seeing though...
>>
>> /Simon
>>