Consider the case where we ask for 4000 bytes in a read. From the
recv where data is grabbed off the network, you are given 1448 bytes
in the first chunk. This is enough data to decrypt, so in
transport.c, this call is made:
rc = decrypt(session, &p->buf[p->readidx], p->wptr, numdecrypt);
However, numdecrypt is 1448, and the encryption blocksize is 32.
1448 / 32 gives a remainder of 8, so we have 8 bytes that cannot be
decrypted for this chunk of data, since it represents only a partial
block.
Inside decrypt(), we see the following loop:
while(len >= blocksize) {
... decrypt block of data ...
}
This loop will process 1440 bytes of data that we passed in, and then
8 bytes are left in the buffer. However, we didn't outside of this
function we assumed that all 1448 bytes were processed and copied into
the decrypted packet buffer.
Back at where decrypt was called, we increment the write pointer the
entire 1448 bytes of numdecrypt, so now those 8 unprocessed bytes are
effectively skipped.
/* advance the read pointer */
p->readidx += numdecrypt;
/* advance write pointer */
p->wptr += numdecrypt;
/* increse data_num */
p->data_num += numdecrypt;
I don't have a patch for this because I don't fully understand the
architecture of this system yet (it doesn't seem to be as simple as
adjusting the write pointer), but I will try to have something soon.
-Lucas
On Feb 13, 2007, at 12:56 PM, Daniel Stenberg wrote:
> On Mon, 12 Feb 2007, Lucas Newman wrote:
>
>> I think I understand what is happening now. If a large read blocks
>> in the middle, the chunk of data obtained is processed in
>> transport.c to determine if a full packet was snagged. While
>> processing half of a packet, if the data is not a multiple of the
>> crypto block size, the extra bytes are discarded from the end of
>> the chunk, and the remainder of the packet is missing those bytes,
>> hence the MAC failure.
>>
>> To see this happening, add the following line to transport.c:441:
>> fprintf(stderr, "Bytes being discarded: %d\n", numdecrypt % session-
>> >remote.crypt->blocksize);
>>
>> If you are able to read a whole packet at once, you will never
>> discard any bytes when decrypting, so that is why the behavior only
>> appears when doing large, blocking reads.
>>
>> A solution would be to retain the extra bytes and just process them
>> in the next iteration.
>
> I must be stupid, but I read the code around line 441 and I can't
> see how the bytes are being discarded.
>
> Do you have a suggested patch to fix the problem you see?
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
libssh2-devel mailing list
libssh2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libssh2-devel
