Decrypt integrity check failed after sending several correct messages

[Jose Miguel Such]

Thanks for replying 

> On Feb 11, 2008, at 6:08, Jose Miguel Such wrote:
> > The problem is solved if i retry to call gss_unwrap with the same
> > message
> > after waiting for 10 or 20 milliseconds once it has failed for the
> > first
> > time.
>
> That's ... really strange.  Does it fail if you immediately retry
> without waiting?
>
Yes, it does. I have to wait a number of milliseconds, and this number have to 
be increased as the number of processes does. For instance, when running 1400 
processes 10 milliseconds are enough, but when running 2000 processes i have 
to wait 20 milliseconds. I haven't tried more than 2000 processes.

> As far as I know, gss_unwrap should be completely deterministic.  Two
> invocations on the same input should get the same result.  Well,
> aside from sequence-number and timestamp checks, but decrypt-
> integrity-failed isn't the sort of error that would come up if those
> failed.  Aside from random hardware issues, I have no guess as to
> what the problem would be here.  I'd probably start with adding lots
> of debugging code to the libraries to log lots of info if the check
> fails, and then log some of the same info when you retry again.
> Sorry, I know it's not very helpful if you're not comfortable diving
> into the Kerberos code....
I haven't got into the kerberos code before, but if it is the only way ...

> Hmm... you said this is a large number of processes.  I assume they
> are all single-threaded?  Are you using shared memory or memory-
> mapped files for interprocess communication?
I use sockets for interprocess communication, because our processes are 
distributed among different hosts, so it allows as to communicate processes 
in both the same and different machines in the same way.

Processes are not single-threaded but there is a mutex inside each process 
avoiding that more than one thread access gss functions at a time.
>
> Ken