On 03/23/2013 12:00 AM, Sachin Shetty wrote:
Hi,
We are using Apache HttpClient to download files from remote server, the files
are encrypted, so we wrap a CipherOutputStream around the InputStream returned
from HttpClient.
While doing this, we always see this error this error the first time and then
at random times:
java.security.ProviderException: update() failed
at sun.security.pkcs11.P11Cipher.implUpdate(P11Cipher.java:565)
at sun.security.pkcs11.P11Cipher.engineUpdate(P11Cipher.java:464)
at sun.security.pkcs11.P11Cipher.engineUpdate(P11Cipher.java:452)
at javax.crypto.Cipher.update(DashoA13*..)
at javax.crypto.CipherInputStream.a(DashoA13*..)
at javax.crypto.CipherInputStream.read(DashoA13*..)
at javax.crypto.CipherInputStream.read(DashoA13*..)
at com.purato.eos.gcs.GcsClient.copyStream(GcsClient.java:762)
at com.purato.eos.gcs.GcsClient.main(GcsClient.java:821)
Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_DATA_LEN_RANGE
at sun.security.pkcs11.wrapper.PKCS11.C_DecryptUpdate(Native Method)
at sun.security.pkcs11.P11Cipher.implUpdate(P11Cipher.java:549)
... 8 more
This isn't using NSS. It may be using softoken (through the wrapper),
but it's not clear because the stack traceback ends before we get to
softoken.
What you are having here is probably a disagreement between what sun
java expects and what softoken provides (assuming softoken is involved).
It may be a bug in either, or simply something Java wants that NSS
softoken doesn't supply.
In any case I don't usually bother debugging softoken issues in other
libraries since softoken is primarily for use in NSS. If a library user
points out an actual PKCS #11 problem with softoken (which do exist),
then I'm more likely to try to get it into some version of NSS in a best
effort basis.
We do have some Java bindings for NSS itself (JSS), and there is a JSS
maintainer, though I don't want to mislead to on the level of support
for that either.
bob
Here are some intersting findings
1. This only happens when trying to decrypt a file being streamed remotely, the
same file when fed from the file system is ok
2. This problem does not happen when nss is disable and default SUNJCE is used
3. This problem does not happen when the remote file being streamed is small i.e.
< 692 bytes in my case
4. Just a side note: HttpClient maintains keep alive connections, so the first
time it takes a couple of seconds for the first set of bytes to arrive, but in
subsequent calls it is immediate and may be that is the reason it does not fail
4. I wrapped the input stream returned by HttpClient to see what calls
CipherInpytStream is making to the underlying remote input stream, and there is
no difference in the calls, or the bytes returned. Just that at the first
download, nss errores out at 692 bytes, but after that it goes fine.
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
