tomaswolf commented on issue #455: URL: https://github.com/apache/mina-sshd/issues/455#issuecomment-1911774253
* Which exact AES variant was it? (CTR? CBC? GCM? Size?) * How can I reproduce the problem in a unit test? That miracle appears to happen frequently. All the other Java SSH implementation that I checked basically do it that way (calling only update()). Not all of them are doing in-place processing, though. For CTR and CBC, this could be fixed by calling doFinal() and then re-initializing the cipher with the same key: * for CTR, take the previous IV, treat it as a MSB-first counter and add in the number of blocks processed, then set that as new IV. We won't be able to check for IV re-use, but that's no problem since key exchanges should occur long before a wrap-around in the IV can occur. * for CBC, use the last encrypted block as new IV. If GCM, then something must be wrong with buffer size calculations. For AES-GCM, current code already calls doFinal() and then re-inits the cipher. With CTR or CBC, the only way I can imagine this `ShortBufferException` having happened on encoding (as shown by the stack traces) is that encoding message _n-1_ did not return all encoded bytes, and then encoding message _n_ tried to return the last block(s) from message _n-1_ together with all blocks for message _n_. Off-topic: we should also improve the exception handling for such cases and make sure we include the exact algorithm/transformation name into the exception message. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
