On Tuesday, March 26, 2013 4:23:19 AM UTC+5:30, Robert Relyea wrote: > 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. > > >
Hi Bob, We are basically following the instructions here: http://www.intel.in/content/dam/www/public/us/en/documents/white-papers/healthcare-and-intel-advanced-encryption-standards-new-instructions.pdf Do you know where I can find more help on this? Here is the full stack trace, but I am not sure if this is helpful. 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.filer.servlet.GenericFilerServiceServlet.copyStream(GenericFilerServiceServlet.java:458) at com.purato.eos.filer.servlet.GenericFilerServiceServlet.doGet(GenericFilerServiceServlet.java:274) at com.purato.eos.filer.servlet.GenericFilerServiceServlet.service(GenericFilerServiceServlet.java:83) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at com.purato.ui.web.filter.LogDiagnosticsFilter.doFilter(LogDiagnosticsFilter.java:31) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:929) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1002) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:585) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) 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) -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
