Yesterday I reported an issue under "Jsch cipher problems when
JsafeJCEFIPS provider is enabled".
>From looking at the archives, it does not show up very well so I may
have goofed on the formatting.
In summary though, I noticed that whenever I'm using Jsch in an
environment where RSA's
JsafeJCEFIPS Crypt4j library is setup as the primary provider, my SSH
connections would fail whenever
using the aes*-ctr ciphers.
I did some more research today and it looks like it's due to the use
of the same buffer for both the
input and output arguments to the s2ccipher.update() calls in Session.java.
I made some local changes which seemed to fix the issue in my
environment. Attached is the
diff I used to resolve my problem. Note, I know it's probably not a
final ultimate solution it's
more of a proof of concept to show the problem and one way that
"seems" to fix the problem.
Without this patch, when stepping through the code, what seems to
happen at these update calls
is that what's left in the output buffer in the end is 0s. The number
of 0s are also the exact
length of the data that should be there. Once we break it up into two
separate buffers, everything
is fine though.
I looked at the javadoc for the update method in javax.crypto.Cipher
and it does state that:
"Note: this method should be copy-safe, which means the input and
output buffers can reference the same
block of memory and no unprocessed input data is overwritten when the
result is copied into the output buffer."
This only seems to put a requirement on the unprocessed data though,
not the processed data.
In my case, the only parts of the input buffer that are getting
replaced by 0s are the parts we seem
to be processing. The rest of the buffer is not getting touched.
Any thoughts on whether or not this is actually a bug in Jsch?
Thank you for your feedback.
+-From: Sean Daley <spdaley@...> ---
|_Date: Thu, 16 Feb 2012 17:12:30 -0500 __
|I looked at the javadoc for the update method in javax.crypto.Cipher
|and it does state that:
|"Note: this method should be copy-safe, which means the input and
|output buffers can reference the same
|block of memory and no unprocessed input data is overwritten when the
|result is copied into the output buffer."
It seems to me that such a behavior has violated the statement,
"the input and output buffers can reference the same block of memory",
and it is an implementation bug of JsafeJCEFIPS, IMHO.
Anyway, you can implement your own "com.jcraft.jsch.Cipher" classes,
and must be able to use them like,
Session#setConfig("aes128-ctr", "your AES128CTR");
Session#setConfig("aes192-ctr", "your AES192CTR");
Session#setConfig("aes256-ctr", "your AES256CTR");
1-14-20 HONCHO AOBA-KU,
SENDAI, MIYAGI 980-0014 Japan.