Re: some strange decryption errors + one enhancement notice

[Miroslav Kratochvil]

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.

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.

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

--- 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 <address@hidden> wrote:
> Miroslav Kratochvil <address@hidden> 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 <address@hidden> 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
>