Bug in Cipher ?

I ve come across what I believe is a bug in the JRE. Posting to this forum to get input from someone else and double check I m not missing something before I submit a bug report.
In a nutshell, if I pass a bytebuffer which has a position >0 to the method
doFinal(clearBuffer, outBuffer); for the output buffer, the encryption gets corrupted every 4K bytes, for one full padding of 16 bytes. (encryption is correct for the first 4096 bytes)
If I don t advance the position, the encryption works fine.
package test;
import java.nio.ByteBuffer;
import java.util.Random;
import javax.crypto.Cipher;
import javax.crypto.spec.SecretKeySpec;
public class EncryptionBug {
     // set this buffer to at least 4096 bytes for the bug to appear
     static int BUFFER_LENGTH = 4111;
     //set this offset to >0 for the bug to appear
     static int OUTPUT_OFFSET = 4;
     public static void main(String[] args) {
          byte[] encryptionKey = new byte[16];
          new Random().nextBytes(encryptionKey);
          Cipher cipherEncrypt;
          try {
               SecretKeySpec skeySpec = new SecretKeySpec(encryptionKey, "AES");
               cipherEncrypt = Cipher.getInstance("AES");
               Cipher cipherDecrypt = Cipher.getInstance("AES");
               cipherEncrypt.init(Cipher.ENCRYPT_MODE, skeySpec);
               cipherDecrypt.init(Cipher.DECRYPT_MODE, skeySpec);
               byte data[] = new byte[BUFFER_LENGTH];
               new Random().nextBytes(data);
               ByteBuffer outBuffer = ByteBuffer.allocateDirect(65536);
               ByteBuffer clearBuffer = outBuffer.duplicate();
               clearBuffer.put(data);
               clearBuffer.flip();
               outBuffer.position(OUTPUT_OFFSET);
               int length = cipherEncrypt.doFinal(clearBuffer, outBuffer);
               byte[] encryptedBuffer = new byte[length];
               for (int i = 0; i < encryptedBuffer.length; i++) {
                    encryptedBuffer[i] = outBuffer.get(OUTPUT_OFFSET + i);
               byte encryptedDirect[] = cipherEncrypt.doFinal(data);
               for (int i = 0; i < encryptedBuffer.length; i++) {
                    if (encryptedDirect[i] != encryptedBuffer) {
                         System.out.println("********* corrupted index " + i + " "
                                   + encryptedBuffer[i] + " vs " + encryptedDirect[i]);
          } catch (Exception ex) {
               ex.printStackTrace();

Having looked at the Javadoc for duplicate() I seepublic abstract ByteBuffer duplicate()
    Creates a new byte buffer that shares this buffer's content.
    The content of the new buffer will be that of this buffer. Changes to this buffer's content will be visible in the new buffer, and vice versa; the two buffers' position, limit, and mark values will be independent.
    The new buffer's capacity, limit, position, and mark values will be identical to those of this buffer. The new buffer will be direct if, and only if, this buffer is direct, and it will be read-only if, and only if, this buffer is read-only.which indicates that the two buffers will have the same capacity and that they share the same backing array. This means that your outBuffer and your clearBuffer share the same byte array.
Your cipher is reading from one buffer and writing to the other which means it is overwriting the original data! At best this seems dangerous.
Based on this, I don't think you have found a bug in Cipher.

Similar Messages

  • Is it an bug in SunJCE Cipher implementation?

    i encountered an issue running the following piece of codes
    public static void main(String[] args) {
              try {
                   String clearText = args[0];
                   KeyGenerator kg = KeyGenerator.getInstance("DESede", "SunJCE");
                   kg.init(new SecureRandom());
                   SecretKey secretKey = kg.generateKey();
                   Cipher c = Cipher.getInstance("DESede/ECB/PKCS5Padding", "SunJCE");
                   c.init(Cipher.ENCRYPT_MODE, secretKey);
                   c.update(clearText.getBytes("ISO8859_1"));
                   byte[] encrypted = c.doFinal();
                   System.out.println("Size of encrypted byte array:" + encrypted.length);
                   c.init(Cipher.DECRYPT_MODE, secretKey);
                   c.update(encrypted);
                   byte[] decrypted = c.doFinal();
                   System.out.println("Size of encrypted byte array:" + decrypted.length);
                   String msg = new String(decrypted, "ISO8859_1");
                   System.out.println("Decrypted text:" + msg);     
              } catch (Exception e) {
                   System.out.println(e.toString());
    when starting with comandline parameter as "1", "12", ...., until "1234567", it runs fine, the size of encrypted byte array is 8, as expected, and the decrypted text mataches the original. however, when given the parameter as "12345678", a 8-character string, the DES block size, the size of the encrypted byte array is 0, no encrypted data generated. when given the parameter as "123456789", the size of encypted byte array is 8, the size of decrypted byte array is 1, and decrypted text is "9", the first block of the original data is lost. This pattern remains with other input data, seems when the size of input string is a multiple of DES block size, the entire data is lost. when it is not, then only the one in the last block remains.
    it's hard for me to believe this is caused by a bug in SunJCE, it's so obvious that it would be reported long ago, but i also could not find any coding issue in the code above. Any one can give me some suggestions/hints? i really appreciate it.
    I run the code on winXP box, with sun jdk 1.5.0_06 or jdk 1.4.2_11, same result. i also run the code on my linux box, with sun jdk 1.4.1_03, same result.

    Please use code tags the next time you post.
    The bug is in your code. You're throwing away the byte [] returned by Cipher.update().
    In your small example you're better off just skipping the update method and only using the doFinal(byte []) method e.g. ...
    Cipher c = Cipher.getInstance("DESede/ECB/PKCS5Padding", "SunJCE");
    c.init(Cipher.ENCRYPT_MODE, secretKey);
    byte[] encrypted = c.doFinal(clearText.getBytes("ISO8859_1"));

  • Is this a Weblogic bug?

    Hi all,
    Please help....I really don't know what to do with this problem as have try all methods that I know of...
    I suspect is this a Welogic bug? It happens intermittently too.....
    Need help on this weird exception i have. My stateless session EJB attempts to
    create an transaction when the exception occurs. My server is WL8.1 powered by
    Jdk1.4.2_05. My server is not using SSL, so find it strange that some certification
    is involved.
    java.lang.ExceptionInInitializerError
    at javax.crypto.Cipher.a(DashoA6275)
    at javax.crypto.Cipher.getInstance(DashoA6275)
    at com.entrust.toolkit.security.provider.AnsiRandom1.engineSetSeed(AnsiRandom1.java)
    at java.security.SecureRandom.setSeed(SecureRandom.java:369)
    at weblogic.transaction.internal.XidImpl.seedRandomGenerator(XidImpl.java:378)
    at weblogic.transaction.internal.XidImpl.create(XidImpl.java:266)
    at weblogic.transaction.internal.TransactionManagerImpl.getNewXID(TransactionManagerImpl.java:1719)
    at weblogic.transaction.internal.TransactionManagerImpl.internalBegin(TransactionManagerImpl.java:249)
    at weblogic.transaction.internal.ServerTransactionManagerImpl.internalBegin(ServerTransactionManagerImpl.java:303)
    at weblogic.transaction.internal.ServerTransactionManagerImpl.begin(ServerTransactionManagerImpl.java:259)
    at weblogic.ejb20.internal.MethodDescriptor.startTransaction(MethodDescriptor.java:255)
    at weblogic.ejb20.internal.MethodDescriptor.getInvokeTx(MethodDescriptor.java:377)
    at weblogic.ejb20.internal.EJBRuntimeUtils.createWrapWithTxs(EJBRuntimeUtils.java:325)
    at weblogic.ejb20.internal.StatelessEJBObject.preInvoke(StatelessEJBObject.java:64)
    at care2.preEnlisteeMgmt.business.assignmInstr.assignmInstrMgr.AssignmInstrMgrBean_xghsg0_EOImpl.setAssignmInstrs(AssignmInstrMgrBean_xghsg0_EOImpl.java:85)
    at care2.preEnlisteeMgmt.business.assignmInstr.AssignmInstrDelegate.setAssignmInstrs(AssignmInstrDelegate.java:116)
    at care2.presentation.assignmInstr.AssignmInstrDisplayAction.execute(AssignmInstrDisplayAction.java:205)
    at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:484)
    at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:274)
    at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482)
    at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:525)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
    at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:971)
    at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:402)
    at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:305)
    at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:6350)
    at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:317)
    at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:118)
    at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3635)
    at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2585)
    at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
    at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
    Caused by: java.lang.SecurityException: Cannot set up certs for trusted CAs
    at javax.crypto.SunJCE_b.(DashoA6275)
    ... 33 more
    Caused by: java.security.PrivilegedActionException: java.security.InvalidKeyException:
    InitVerify error: java.security.NoSuchAlgorithmException: Cannot find any provider
    supporting RSA/ECB/PKCS1Padding
    at java.security.AccessController.doPrivileged(Native Method)
    ... 34 more
    Caused by: java.security.InvalidKeyException: InitVerify error: java.security.NoSuchAlgorithmException:
    Cannot find any provider supporting RSA/ECB/PKCS1Padding
    at iaik.security.rsa.RSASignature.engineInitVerify(RSASignature.java)
    at java.security.Signature.initVerify(Signature.java:297)
    at iaik.x509.X509Certificate.verify(X509Certificate.java)
    at iaik.x509.X509Certificate.verify(X509Certificate.java)
    at javax.crypto.SunJCE_b.c(DashoA6275)
    at javax.crypto.SunJCE_b.b(DashoA6275)
    at javax.crypto.SunJCE_s.run(DashoA6275)
    ... 35 more

    Hi all,
    Please help....I really don't know what to do with this problem as have try all methods that I know of...
    I suspect is this a Welogic bug? It happens intermittently too.....
    Need help on this weird exception i have. My stateless session EJB attempts to
    create an transaction when the exception occurs. My server is WL8.1 powered by
    Jdk1.4.2_05. My server is not using SSL, so find it strange that some certification
    is involved.
    java.lang.ExceptionInInitializerError
    at javax.crypto.Cipher.a(DashoA6275)
    at javax.crypto.Cipher.getInstance(DashoA6275)
    at com.entrust.toolkit.security.provider.AnsiRandom1.engineSetSeed(AnsiRandom1.java)
    at java.security.SecureRandom.setSeed(SecureRandom.java:369)
    at weblogic.transaction.internal.XidImpl.seedRandomGenerator(XidImpl.java:378)
    at weblogic.transaction.internal.XidImpl.create(XidImpl.java:266)
    at weblogic.transaction.internal.TransactionManagerImpl.getNewXID(TransactionManagerImpl.java:1719)
    at weblogic.transaction.internal.TransactionManagerImpl.internalBegin(TransactionManagerImpl.java:249)
    at weblogic.transaction.internal.ServerTransactionManagerImpl.internalBegin(ServerTransactionManagerImpl.java:303)
    at weblogic.transaction.internal.ServerTransactionManagerImpl.begin(ServerTransactionManagerImpl.java:259)
    at weblogic.ejb20.internal.MethodDescriptor.startTransaction(MethodDescriptor.java:255)
    at weblogic.ejb20.internal.MethodDescriptor.getInvokeTx(MethodDescriptor.java:377)
    at weblogic.ejb20.internal.EJBRuntimeUtils.createWrapWithTxs(EJBRuntimeUtils.java:325)
    at weblogic.ejb20.internal.StatelessEJBObject.preInvoke(StatelessEJBObject.java:64)
    at care2.preEnlisteeMgmt.business.assignmInstr.assignmInstrMgr.AssignmInstrMgrBean_xghsg0_EOImpl.setAssignmInstrs(AssignmInstrMgrBean_xghsg0_EOImpl.java:85)
    at care2.preEnlisteeMgmt.business.assignmInstr.AssignmInstrDelegate.setAssignmInstrs(AssignmInstrDelegate.java:116)
    at care2.presentation.assignmInstr.AssignmInstrDisplayAction.execute(AssignmInstrDisplayAction.java:205)
    at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:484)
    at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:274)
    at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482)
    at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:525)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
    at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:971)
    at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:402)
    at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:305)
    at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:6350)
    at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:317)
    at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:118)
    at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3635)
    at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2585)
    at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
    at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
    Caused by: java.lang.SecurityException: Cannot set up certs for trusted CAs
    at javax.crypto.SunJCE_b.(DashoA6275)
    ... 33 more
    Caused by: java.security.PrivilegedActionException: java.security.InvalidKeyException:
    InitVerify error: java.security.NoSuchAlgorithmException: Cannot find any provider
    supporting RSA/ECB/PKCS1Padding
    at java.security.AccessController.doPrivileged(Native Method)
    ... 34 more
    Caused by: java.security.InvalidKeyException: InitVerify error: java.security.NoSuchAlgorithmException:
    Cannot find any provider supporting RSA/ECB/PKCS1Padding
    at iaik.security.rsa.RSASignature.engineInitVerify(RSASignature.java)
    at java.security.Signature.initVerify(Signature.java:297)
    at iaik.x509.X509Certificate.verify(X509Certificate.java)
    at iaik.x509.X509Certificate.verify(X509Certificate.java)
    at javax.crypto.SunJCE_b.c(DashoA6275)
    at javax.crypto.SunJCE_b.b(DashoA6275)
    at javax.crypto.SunJCE_s.run(DashoA6275)
    ... 35 more

  • New bug in IIS/SSL code ?

    Hello Team,
    Windows 2012 R2 Datacenter with all patches. IIS with SSL and SCEP (NDES) service.
    Problem occurs only when client is proposing SSL RSA cipher suite. For DH cipher suite everything is working fine.
    The SCEP communication from my router to IIS/SSL:
    - Client Hello with RSA cipher 
    - Server Hello with RSA cipher + Certificate
    - client sending Client Key Exchange + received ACK from server
    - client sending Change Cipher spec and..
    - server sends RST
    Screenshot from SSL session:
    http://tinypic.com/r/m93976/8
    The problem is not SCEP related. It can be recreated by any web browser accessing IIS via HTTPS. That web browser should have RSA cipher suite disabled (in firefox about:config/ssl). I have tested from locally installed firefox to exclude any interference
    on the network.
    Is this any well known bug ? (i can not find any). Please advise.
    Regards,
    Michal Garcarz

    I agree that it is weird - but I would still be interested in using another crypto provider at the server ... not just another certificate, but one associated with a key using a different CSP.
    If you say you use the 'default' one - which one is it? It depends on the certificate template or settings you made when creating the key.
    I suppose it is either the Software Key Storage provider (CNG) or the classical RSA SChannel CSP (Visible e.g. in the output of
    certutil -v -store run at the server). If all of your server certificates use one of these I'd try to test one more certificate that uses the other one - and if it is just to rule out an impact of the crypto provider.
    Elke

  • My SDK doesn't implement Cipher, course of action

    Hi, all. First of all let me tell you that I've checked the forum for this topic. Found 44 threads when searching for "Cipher". I've pretty clear that due to restrictions from the U.S. Goverment, the Sun JC kit doesn't implement the Cipher class. That's understood.
    Now, my SmartCard Vendor (DataCard Aptura) doesn't implement it neither the Cipher class on it's sdk. I've asked for support and they have told me that they won't add that Class. So I can't count on them.
    So, the purpose of this post is to find out the course of action. I've just two options, either I implement the class by myself or I get it (buy it, if it's possible) somewhere else. I don't want you to do my work, I just need some light because I'm new to this cryptography over smartCard thing.
    So I've this questions which require short answer (hope so):
    1.) According to your experience, should we implement it by ourselves? Or should we look for some vendor that has already implemented it?
    2.) I that were the case (that we should implement it by our own) could you estimate the amount of time (or resources) needed, considering just one programmer.
    3.) Are there some special considerations that I should take in order to save memory. Please notice that the current version of Aptura prohibits the use of transient arrays on the card, due to a bug inside the core of the VM. It doesn?t reclaim the space after it?s been used, for instance after a reset, it won?t reclaim the all the transient space used.
    4.) If it would take a considerable amount of time to implement the Cipher class by our own, do you know some vendor that has already implemented and can save us that time?
    Any other light or aspect that you might think it's important and I've missed here, would be appreciated.
    Many Thanks in advance.
    CL

    Well no. All I want is to have cryptography on my card (that I didn't choose for the project I just received like "this is the card"). And this vendor doesn't have an implementation of the Cipher class.
    As a parenthesis () there is not Int as you properly mentioned, but I implemented by hand, unsing Zhiqun Chen proposal (on her book JavaCard Technology for SmartCards). I know that approach is not quite efficient, but it works (considering that for financial purposes a short is not enough).
    Well, back to our business. Also I'm concious that the approach of implementing the cryptography by myself would not win the efficiency award for Smart Card, but I need to do something and trying to change the card at this point (I didn't choose it, as I told you) would not be the first solution, due to the fact that the production cards are already ordered. So that's the actual situation.
    So, I'm pretty sure the problem is on the side of my vendor. Is not that I'm washing my hands on him, it's just the fact. Here you'll find my little test I'm trying to run. It crashes after the following line on the process (APDU apdu) method:
    cipher.doFinal(data, START, (short) data.length, cipherText, START);
    And here's my code:
    //CVS Tests
    package com.datacode.bi.Purse;
    import javacard.framework.*;
    import javacardx.crypto.*;
    import javacard.security.*;
    public class Purse extends Applet
    public static final byte START = (byte) 0x00;
    private DESKey desKey;
    private Cipher cipher;
    private byte [] cipherText;
    protected Purse(byte[] bArray, short bOffset, byte bLength)
    cipherText = new byte [100];
    try {
    desKey = (DESKey) KeyBuilder.buildKey(KeyBuilder.TYPE_DES, KeyBuilder.LENGTH_DES, false);
    desKey.setKey( keyData, START);
    cipher = Cipher.getInstance(Cipher.ALG_DES_ECB_ISO9797_M1, false);
    cipher.init(desKey, Cipher.MODE_ENCRYPT);
    catch (CryptoException e) {
    register();
    * Installs Java Purse applet.
    * @param bArray to pass to register() method.
    * @param bOffset to pass to register() method.
    * @param bLength to pass to register() method.
         public static void install( byte[] bArray, short bOffset, byte bLength )
    byte instanceLength = (byte) bArray[bOffset];
    short instanceOffset = (short)(bOffset + 1);
              new Purse(bArray, instanceOffset, instanceLength);
    * Performs the session finalization.
         public void deselect()
    * Dispatches APDU commands.
    * @param apdu APDU object
         public void process(APDU apdu)
    byte[] buffer = apdu.getBuffer();
    try {
    //ISOException.throwIt(
    cipher.doFinal(data, START, (short) data.length, cipherText, START);
    //ISOException.throwIt(DEBUG_CODE);
    apdu.setOutgoing();
    apdu.setOutgoingLength((short) cipherText.length);
    apdu.sendBytesLong(cipherText, START, (short) cipherText.length);
    catch (APDUException e) {
    catch (CryptoException e) {
    private final static byte [] keyData = {    (byte) 'C',
    (byte) 'a',
    (byte) 'r',
    (byte) 'p',
    (byte) 'e',
    (byte) ' ',
    (byte) 'D',
    (byte) 'i'
    private static final byte [] data = { (byte) 68,
    (byte) 111,
    (byte) 32,
    (byte) 121,
    (byte) 111,
    (byte) 117,
    (byte) 32,
    (byte) 98,
    (byte) 121,
    (byte) 116,
    (byte) 101,
    (byte) 44,
    (byte) 32,
    (byte) 119,
    (byte) 104,
    (byte) 101,
    (byte) 110,
    (byte) 32,
    (byte) 73,
    (byte) 32,
    (byte) 107,
    (byte) 110,
    (byte) 111,
    (byte) 99,
    (byte) 63,
    (byte) 65
    private static final short DEBUG_CODE = (short) 0x9999;
    >
    Aptura prohibits the use of transient arrays on the
    card,based on that I would try other vendors, IBM
    JCOP, Datakey, G&D Sm@rtCafe, Gem+ GemXpress RAD, and
    SLB all implement the javacard.security,
    javacard.crypto classes and the transient arrays are
    COD/COR.

  • SJSAS EE 8.1_02 / Bug in jss4.jar breaks our new release

    +[Full environment description below]+
    Problem description: our application server contains several applications including one J2EE application made of several WARs and EJBs. One of these EJBs starts some internal services that use an open source library called jsch [1] to make SFTP transfers (we use jsch 0.1.31). This jsch library relies on javax.crypto and negotiates encryption with the remote SFTP server. Doing so, it selects a cryptographic cipher. This works well from our development and build environments but fails on our test server which uses Sun App Server 8.1_02. This server doesn't deploy a JavaCAPS application internally (we have a separate App. Server for it).
    For some reasons (that I do not yet completely understand), our test (and production) Sun AS contains in the classpath a library (jss4.jar) and this library contains a cipher that is used for the transfer. The library may be related to Sun Application Manager or for some security setup but I am not yet sure. It may be standard with Sun AS EE.
    As shown in the appendices below, this library seems to contain a bug causing the SFTP connection to fail. If the code is indeed the one that is used in jss4.jar, then the library is obviously broken. But the only Sun patch I've seen that upgrades the library was http://sunsolve.sun.com/search/document.do?assetkey=1-21-119211-14-1&searchclause=jss4.jar . Tt doesn't seem to address our problem (at least in the patch documentation).
    I think that we now need some help/feedback from Sun. We have to either
    * find out if we can remove this library from the classpath
    * find a way to bypass the use of the cryptographic component
    * or get a fix for the library itself.
    Is it possible for someone at Sun to help us fix this issue ? We've to release again the application with a fix ASAP.
    Cheers,
    Jerome
    Appendix 1 ** Environment:
    SJSAS EE 8.1_02
    java -versionjava version "1.5.0_07"
    Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-b03)
    Java HotSpot(TM) Server VM (build 1.5.0_07-b03, mixed mode)
    uname -aSunOS ast-b2bdev 5.10 Generic_118822-27 sun4u sparc SUNW,Sun-Fire-V210
    ls -la /usr/share/lib/mps/secv1/jss4.jarlrwxrwxrwx   1 root     root          11 Dec 12  2005 /usr/share/lib/mps/secv1/jss4.jar -> ../jss4.jar
    ls -la /usr/share/lib/mps/jss4.jar -rw-r--r--   1 root     bin       657089 Jul 29  2005 /usr/share/lib/mps/jss4.jar
    md5 /usr/share/lib/mps/jss4.jar 1c9f9b09a1d632f31458caef5cfe4812        /usr/share/lib/mps/jss4.jarAppendix 2 ** stack trace that we see while running our program
    I've finally managed to get a full stack trace:
    [#|2007-11-05T18:23:00.980+0100|WARNING|sun-appserver-ee8.1_02|javax.enterprise.system.stream.err|_ThreadID=230 ;|
    javax.crypto.ShortBufferException: 32 needed, 20480 supplied
            at org.mozilla.jss.provider.javax.crypto.JSSCipherSpi.engineUpdate(JSSCipherSpi.java:338)
            at javax.crypto.Cipher.update(DashoA12275)
            at com.jcraft.jsch.jce.TripleDESCBC.update(TripleDESCBC.java:81)
            at com.jcraft.jsch.Session.encode(Session.java:800)
            at com.jcraft.jsch.Session._write(Session.java:1135)
            at com.jcraft.jsch.Session.write (Session.java:1132)
            at com.jcraft.jsch.UserAuth.start(UserAuth.java:52)
            at com.jcraft.jsch.UserAuthNone.start(UserAuthNone.java:36)
            at com.jcraft.jsch.Session.connect(Session.java:350)
            at com.jcraft.jsch.Session.connect(Session.java:145)
            at org.apache.commons.vfs.provider.sftp.SftpClientFactory.createConnection(SftpClientFactory.java:210)
            at org.apache.commons.vfs.provider.sftp.SftpFileProvider.doCreateFileSystem (SftpFileProvider.java:90)
            at org.apache.commons.vfs.provider.AbstractOriginatingFileProvider.findFile(AbstractOriginatingFileProvider.java:81)
            at org.apache.commons.vfs.provider.AbstractOriginatingFileProvider.findFile (AbstractOriginatingFileProvider.java:62)
            at org.apache.commons.vfs.impl.DefaultFileSystemManager.resolveFile(DefaultFileSystemManager.java:641)
            at org.apache.commons.vfs.impl.DefaultFileSystemManager.resolveFile (DefaultFileSystemManager.java:582)Appendix 3 ** potential matching bug in JSSCipherSpi as identified by jsch author
    ---------- Forwarded message ----------
    From: Atsuhiko Yamanaka <[email protected]>
    Date: Nov 6, 2007 2:12 AM
    Subject: Re: [JSch-users] javax.crypto.ShortBufferException in Session with 0.1.31 ?
    To: [email protected]
    Cc: [email protected]
    - Hide quoted text -
      +-From: "Jerome Lacoste" <[email protected]> --
      |_Date: Mon, 5 Nov 2007 18:39:50 +0100 _______________
      |
      |I've finally managed to get a full stack trace:
      |[#|2007-11-05T18:23:
      |00.980+0100|WARNING|sun-appserver-ee8.1_02|javax.enterprise.system.stream.err|_ThreadID=230
      |;|
      |javax.crypto.ShortBufferException: 32 needed, 20480 supplied
      |        at org.mozilla.jss.provider.javax.crypto.JSSCipherSpi.engineUpdate(
      |JSSCipherSpi.java:338)
      |        at javax.crypto.Cipher.update (DashoA12275)
    Sign, I knew.
    Before writing my last message, I had found the following buggy code[1],
       public int engineUpdate(byte[] input, int inputOffset, int inputLen,
           byte[] output, int outputOffset) throws ShortBufferException
           byte[] bytes = engineUpdate(input, inputOffset, inputLen);
           if( bytes.length < output.length-outputOffset ) {
               throw new ShortBufferException(bytes.length +  " needed, " +
                   (output.length-outputOffset) + " supplied");
           System.arraycopy(bytes, 0, output, outputOffset, bytes.length);
           return bytes.length;
    and I had strongly believed that the problem had come from it,
    but it is contradict to your success with your own compiled jar.
    [1] http://www.koders.com/java/fidF0D62D7385480B906B3CC88210B02AF4A84FF467.aspx

    +[Full environment description below]+
    Problem description: our application server contains several applications including one J2EE application made of several WARs and EJBs. One of these EJBs starts some internal services that use an open source library called jsch [1] to make SFTP transfers (we use jsch 0.1.31). This jsch library relies on javax.crypto and negotiates encryption with the remote SFTP server. Doing so, it selects a cryptographic cipher. This works well from our development and build environments but fails on our test server which uses Sun App Server 8.1_02. This server doesn't deploy a JavaCAPS application internally (we have a separate App. Server for it).
    For some reasons (that I do not yet completely understand), our test (and production) Sun AS contains in the classpath a library (jss4.jar) and this library contains a cipher that is used for the transfer. The library may be related to Sun Application Manager or for some security setup but I am not yet sure. It may be standard with Sun AS EE.
    As shown in the appendices below, this library seems to contain a bug causing the SFTP connection to fail. If the code is indeed the one that is used in jss4.jar, then the library is obviously broken. But the only Sun patch I've seen that upgrades the library was http://sunsolve.sun.com/search/document.do?assetkey=1-21-119211-14-1&searchclause=jss4.jar . Tt doesn't seem to address our problem (at least in the patch documentation).
    I think that we now need some help/feedback from Sun. We have to either
    * find out if we can remove this library from the classpath
    * find a way to bypass the use of the cryptographic component
    * or get a fix for the library itself.
    Is it possible for someone at Sun to help us fix this issue ? We've to release again the application with a fix ASAP.
    Cheers,
    Jerome
    Appendix 1 ** Environment:
    SJSAS EE 8.1_02
    java -versionjava version "1.5.0_07"
    Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-b03)
    Java HotSpot(TM) Server VM (build 1.5.0_07-b03, mixed mode)
    uname -aSunOS ast-b2bdev 5.10 Generic_118822-27 sun4u sparc SUNW,Sun-Fire-V210
    ls -la /usr/share/lib/mps/secv1/jss4.jarlrwxrwxrwx   1 root     root          11 Dec 12  2005 /usr/share/lib/mps/secv1/jss4.jar -> ../jss4.jar
    ls -la /usr/share/lib/mps/jss4.jar -rw-r--r--   1 root     bin       657089 Jul 29  2005 /usr/share/lib/mps/jss4.jar
    md5 /usr/share/lib/mps/jss4.jar 1c9f9b09a1d632f31458caef5cfe4812        /usr/share/lib/mps/jss4.jarAppendix 2 ** stack trace that we see while running our program
    I've finally managed to get a full stack trace:
    [#|2007-11-05T18:23:00.980+0100|WARNING|sun-appserver-ee8.1_02|javax.enterprise.system.stream.err|_ThreadID=230 ;|
    javax.crypto.ShortBufferException: 32 needed, 20480 supplied
            at org.mozilla.jss.provider.javax.crypto.JSSCipherSpi.engineUpdate(JSSCipherSpi.java:338)
            at javax.crypto.Cipher.update(DashoA12275)
            at com.jcraft.jsch.jce.TripleDESCBC.update(TripleDESCBC.java:81)
            at com.jcraft.jsch.Session.encode(Session.java:800)
            at com.jcraft.jsch.Session._write(Session.java:1135)
            at com.jcraft.jsch.Session.write (Session.java:1132)
            at com.jcraft.jsch.UserAuth.start(UserAuth.java:52)
            at com.jcraft.jsch.UserAuthNone.start(UserAuthNone.java:36)
            at com.jcraft.jsch.Session.connect(Session.java:350)
            at com.jcraft.jsch.Session.connect(Session.java:145)
            at org.apache.commons.vfs.provider.sftp.SftpClientFactory.createConnection(SftpClientFactory.java:210)
            at org.apache.commons.vfs.provider.sftp.SftpFileProvider.doCreateFileSystem (SftpFileProvider.java:90)
            at org.apache.commons.vfs.provider.AbstractOriginatingFileProvider.findFile(AbstractOriginatingFileProvider.java:81)
            at org.apache.commons.vfs.provider.AbstractOriginatingFileProvider.findFile (AbstractOriginatingFileProvider.java:62)
            at org.apache.commons.vfs.impl.DefaultFileSystemManager.resolveFile(DefaultFileSystemManager.java:641)
            at org.apache.commons.vfs.impl.DefaultFileSystemManager.resolveFile (DefaultFileSystemManager.java:582)Appendix 3 ** potential matching bug in JSSCipherSpi as identified by jsch author
    ---------- Forwarded message ----------
    From: Atsuhiko Yamanaka <[email protected]>
    Date: Nov 6, 2007 2:12 AM
    Subject: Re: [JSch-users] javax.crypto.ShortBufferException in Session with 0.1.31 ?
    To: [email protected]
    Cc: [email protected]
    - Hide quoted text -
      +-From: "Jerome Lacoste" <[email protected]> --
      |_Date: Mon, 5 Nov 2007 18:39:50 +0100 _______________
      |
      |I've finally managed to get a full stack trace:
      |[#|2007-11-05T18:23:
      |00.980+0100|WARNING|sun-appserver-ee8.1_02|javax.enterprise.system.stream.err|_ThreadID=230
      |;|
      |javax.crypto.ShortBufferException: 32 needed, 20480 supplied
      |        at org.mozilla.jss.provider.javax.crypto.JSSCipherSpi.engineUpdate(
      |JSSCipherSpi.java:338)
      |        at javax.crypto.Cipher.update (DashoA12275)
    Sign, I knew.
    Before writing my last message, I had found the following buggy code[1],
       public int engineUpdate(byte[] input, int inputOffset, int inputLen,
           byte[] output, int outputOffset) throws ShortBufferException
           byte[] bytes = engineUpdate(input, inputOffset, inputLen);
           if( bytes.length < output.length-outputOffset ) {
               throw new ShortBufferException(bytes.length +  " needed, " +
                   (output.length-outputOffset) + " supplied");
           System.arraycopy(bytes, 0, output, outputOffset, bytes.length);
           return bytes.length;
    and I had strongly believed that the problem had come from it,
    but it is contradict to your success with your own compiled jar.
    [1] http://www.koders.com/java/fidF0D62D7385480B906B3CC88210B02AF4A84FF467.aspx

  • Bug report regarding SSL library used by Sharepoint web server

    I have attempted to report this by email to the [email protected] address, but they tell me this is not the correct address to use and have refused to give me a better one or forward my bug report on to the correct people. I'm hoping that by posting it here I will get the attention of someone who can fix the problem.PROBLEM DESCRIPTION:Accessing the Sharepoint web servers (157.55.229.87) is not possible from a Scientific Linux 6.5 system using OpenSSL 1.0.1e. Analysis of the network traffic shows the client successfully connects to the server and sends a TLS handshake. The server responds with a TCP ACK, but does not include a TLS handshake response. After 30 seconds the server tears the connection down with a TCP RST.
    This is reproducable with the following command:
    openssl s_client -showcerts -connect sexeysschool-my.sharepoint.com:443
    DIAGNOSIS:
    The client's TLS handshake contains several length fields - one in the TLSv1 record layer, another in the Client Hello handshake payload and one for each of the cipher suites list and extension list. Each of the length headers is 16 bits long, so should be able to contain any value up to 65535.
    By hand-editing the handshake packet and replaying it, I have discovered that if the value of the TLSv1 record layer length header is <= 255, the Sharepoint server responds correctly. However, if the length header exceeds 255, the Sharepoint server does not respond.
    Under Scientific Linux 6.5, 74 cipher suites (totalling 148 octets) and 5 extensions (totalling 65 octets) are presented by the client, yielding a TLSv1 record layer length of 258 octets.
    Please let me know if I can be of any further help, and if possible it would be useful to have some feedback regarding this issue so that we can keep our customers informed.

    Hi Mark,
    According to your description, my understanding is that the Article Date column displayed with the value based on GMT0 in the Refinement web part.
    Microsoft SharePoint stores date and time values in Coordinated Universal Time (UTC, but also named GMT or Zulu) format, and almost all date and time values that are returned by members of the object model are in UTC format. So the value
    of the Article Date column stores the date and time in UTC format in the database, and the search indexes the UTC value of the Article Date column after crawling the database so that it displays the UTC value in Refinement web part.
    The list column values displayed in the lists that are obtained through the indexer for the SPListItem class are already formatted in the local time for the site so if you’re working on current context list item and fetch a datetime field
    like so SPContext.Current.ListItem["Your-DateTime-Field"] you’ll retrieve a DateTime object according the specified time zone in the regional settings.
    More references:
    http://francoisverbeeck.wordpress.com/2012/05/24/sharepoint-tip-of-the-day-be-careful-when-wor/
    Thanks,
    Victoria
    Forum Support
    Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact
    [email protected]
    Victoria Xia
    TechNet Community Support

  • Cipher transformation that outputs non-padded plaintext final partial block

    I have written some Java code to read from and write to an existing data format that encrypts its data using a known symmetric key. It appears to be using the "AES/ECB/NoPadding" transformation / algorithm for all blocks, except for the final block, if the final block is a partial block. Any partial final block is just written out plaintext. When I use an "AES/ECB/NoPadding" Cipher in a CipherInputStream or a CipherOutputStream to read from or write to such a byte stream, respectively, everything works fine, except that any partial final block is omitted, as is expected from what I know of the behavior of "AES/ECB/NoPadding".
    (FYI, all of these questions relate to the Oracle JDK 7u2. For classes whose source is not included with this JDK, e.g., com.sun.crypto.provider.AESCipher, I looked at the source from the OpenJDK 7u2. I only looked at the default crypto provider included in the JDK, which I assume is the SunJCE, but I may be wrong.)
    1) Is there any other transformation that will properly decrypt / encrypt all the full blocks, but read / write, respectively, a partial final block as plaintext? (I assume not, but I also assume that it won't hurt to ask)
    2) Is there any way to obtain the buffered partial final block's data from Cipher? I can get the length of the leftover data from getOutputSize(0), but I haven't found a way to get the content. (I assume that this is done intentionally, to keep the Cipher-related classes as secure as possible)
    If I knew the length of the input, I could just determine the index of the end of the last full block, but I'd like this code to work with any arbitrary InputStream, and there's no way to know the length of an InputStream (without reading until you receive a -1, of course).
    I will probably wind up using a wrapping InputStream / OutputStream that always buffers the last partial block read from / written to it, respectively, until it's received a -1 from a read, or a flush call, respectively, but I wanted to avoid this if I could possibly use the crypto API more effectively.
    As an aside, I investigated exposing a partial final block's data by creating a wrapper class for one or more of the crypto classes. This appears difficult since many of these classes are final. Some other non-final crypto classes have final methods that use non-exposed private members, so those might be difficult, if not impossible, to wrap properly. The best plan that I devised is to create a CipherSpi subclass that wraps around a Cipher, and then use a Cipher subclass that wraps around both the wrapping CipherSpi subclass and the original Cipher. This appears convoluted, so I haven't yet thoroughly investigated its feasibility.
    I don't think that I can plug in a new mode or padding implementation to the existing SunJCE classes, since com.sun.crypto.provider.CipherCore seems to limit the potential implementations to those of which it is already aware.
    Please let me know if I've overlooked or misunderstood anything (this is the first time that I've used the crypto API).
    Thanks.

    Ross wrote:
    It's an existing data format from a huge company. I can't change it, so I cannot switch to CBC or any other mode that is not compatible with ECB for all but a partial final block. If the existing data format is not binary then you have another problem. Ciphertext is binary and storing binary in a 'char' or 'varchar' column is likely to corrupt the ciphertext and in order to reversibly convert it to ASCII or one of the other character encodings then you are going to have to encode it as Base64 (approx 33% inflation), Hex (100% inflation) or ASCII85 (approx 25% inflation).
    I'm just trying to read and write from it. I don't care about security, since the data is on my computer, and it's not sensitive data (at all; it's data about music files). I don't understand this. If it's not sensitive then why are you considering encrypting it? Seems to me to be a pointless requirement!
    I will never transmit the data anywhere, and, even if someone got hold of the data, I wouldn't care in the slightest.Again, why encrypt it then?
    >
    You're definitely right about it being a major security bug, though, so thanks for the recommendation. I just want a nice programmatic interface to read and write the data. I understand why the crypto API would want to make it difficult to obtain partial final block info, but was just wondering if there is any easy way to obtain it anyway. You could use one of the stream ciphers or one of the techniques that turns a block cipher into a stream cipher resulting in one byte per byte. To make it secure you will still need to use a random IV (or something similar) so there will still be an inflation. You can normally get away with just 8 bytes for the IV. The output is still binary bytes and will need to be encoded (Base64, Hex or ASCII85) if you are going to try to store it in a 'char' or 'varchar' which will result in further inflation.
    I just wrote the cyclic buffer & associated input & output streams, so I'll probably just use those since I probably won't be able to extricate the partial final block from the crypto classes.I don't understand this.
    Note - pretty much every time one encrypts data one ends up with ciphertext longer than the cleartext. This is fundamental to encryption and is nothing particularly to do with Java. One can often use compression of the original cleartext prior to encryption but this does not guarantee to result in smaller ciphertext than cleartext.
    Note 1 - it seems to me that all you are trying to do is obfuscate the data so why not just use a simple insecure substitution cipher? This way you end up with ciphertext of the same length as the cleartext and using the same character set so nothing in the database structure has to change.

  • Is this aWeblogic bug?

    Hi all,
    Please help....I really don't know what to do with this problem as have try all methods that I know of...
    I suspect is this a Welogic bug? It happens intermittently too.....
    Need help on this weird exception i have. My stateless session EJB attempts to
    create an transaction when the exception occurs. My server is WL8.1 powered by
    Jdk1.4.2_05. My server is not using SSL, so find it strange that some certification
    is involved.
    java.lang.ExceptionInInitializerError
    at javax.crypto.Cipher.a(DashoA6275)
    at javax.crypto.Cipher.getInstance(DashoA6275)
    at com.entrust.toolkit.security.provider.AnsiRandom1.engineSetSeed(AnsiRandom1.java)
    at java.security.SecureRandom.setSeed(SecureRandom.java:369)
    at weblogic.transaction.internal.XidImpl.seedRandomGenerator(XidImpl.java:378)
    at weblogic.transaction.internal.XidImpl.create(XidImpl.java:266)
    at weblogic.transaction.internal.TransactionManagerImpl.getNewXID(TransactionManagerImpl.java:1719)
    at weblogic.transaction.internal.TransactionManagerImpl.internalBegin(TransactionManagerImpl.java:249)
    at weblogic.transaction.internal.ServerTransactionManagerImpl.internalBegin(ServerTransactionManagerImpl.java:303)
    at weblogic.transaction.internal.ServerTransactionManagerImpl.begin(ServerTransactionManagerImpl.java:259)
    at weblogic.ejb20.internal.MethodDescriptor.startTransaction(MethodDescriptor.java:255)
    at weblogic.ejb20.internal.MethodDescriptor.getInvokeTx(MethodDescriptor.java:377)
    at weblogic.ejb20.internal.EJBRuntimeUtils.createWrapWithTxs(EJBRuntimeUtils.java:325)
    at weblogic.ejb20.internal.StatelessEJBObject.preInvoke(StatelessEJBObject.java:64)
    at care2.preEnlisteeMgmt.business.assignmInstr.assignmInstrMgr.AssignmInstrMgrBean_xghsg0_EOImpl.setAssignmInstrs(AssignmInstrMgrBean_xghsg0_EOImpl.java:85)
    at care2.preEnlisteeMgmt.business.assignmInstr.AssignmInstrDelegate.setAssignmInstrs(AssignmInstrDelegate.java:116)
    at care2.presentation.assignmInstr.AssignmInstrDisplayAction.execute(AssignmInstrDisplayAction.java:205)
    at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:484)
    at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:274)
    at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482)
    at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:525)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
    at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:971)
    at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:402)
    at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:305)
    at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:6350)
    at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:317)
    at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:118)
    at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3635)
    at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2585)
    at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
    at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
    Caused by: java.lang.SecurityException: Cannot set up certs for trusted CAs
    at javax.crypto.SunJCE_b.(DashoA6275)
    ... 33 more
    Caused by: java.security.PrivilegedActionException: java.security.InvalidKeyException:
    InitVerify error: java.security.NoSuchAlgorithmException: Cannot find any provider
    supporting RSA/ECB/PKCS1Padding
    at java.security.AccessController.doPrivileged(Native Method)
    ... 34 more
    Caused by: java.security.InvalidKeyException: InitVerify error: java.security.NoSuchAlgorithmException:
    Cannot find any provider supporting RSA/ECB/PKCS1Padding
    at iaik.security.rsa.RSASignature.engineInitVerify(RSASignature.java)
    at java.security.Signature.initVerify(Signature.java:297)
    at iaik.x509.X509Certificate.verify(X509Certificate.java)
    at iaik.x509.X509Certificate.verify(X509Certificate.java)
    at javax.crypto.SunJCE_b.c(DashoA6275)
    at javax.crypto.SunJCE_b.b(DashoA6275)
    at javax.crypto.SunJCE_s.run(DashoA6275)
    ... 35 more

    hi, I found that
    when the database is set to "Oracle 9i" and call interface of connection pool is set to "OCI 8i/9i",
    obiee generates separate n sqls if the table involves n phyical tables (including alias).
    when the database is set to "Oracle 10g R2/ 11g" and call interface of connection pool is set to "OCI 10g/11g",
    obiee only generate ONE long sql to query regardless of no. of phyiscal tables.
    I think this may be the reason of the discrepancies!!!

  • Weak cipher suites supported on WCS port 8082

    Hi
    Port 8082 is used for health monitoring in WCS, a web service is running on this port so we can login via web and check the status.
    I would like to know, is there a way to limit the cipher suite supported on this port? For port 443, this can be done by modify the Apache configuration file, however this doesn't work for 8082. The version is 5.2.148.0.
    Thanks and Regars,
    Leo

    Hi ,
    "SSL RC4 Cipher Suites Supported" has been documented in bug CSCum03709. 
    CSCum03709    PI 2.0.0.0.294 with SSH vulnerabilities
    Presently, there is no workaround for this vulnerability, however, the fix will be implemented in
    Prime Infrastructure 2.2.which is planned to be released around the end of this year ( tentative)
    Thanks-
    Afroz
    ***Ratings Encourages Contributors ***

  • BUG #CSCur27131 - Evaluation of CVE-2014-3566 on Cisco Email Security Appliance

    I have raised a support case with TAC to try and get more information on the preferred config as well as what Ciphers then become available. Points raised in the support case are as follows:
    Current config based from existing artilce pre-POODLE > MEDIUM:HIGH:-SSLv2:-aNULL:@STRENGTH
    Should the new config be > MEDIUM:HIGH:-SSLv2:-SSLv3:-aNULL:@STRENGTH
    Use of strength meaning that the Ciphers are ordered and presented strongest to weakest as negotiation should occur at the first mutually accepted cipher.
    What are the TLSv1 Ciphers used by Ironport (verify under sslconfig CLI appears only to list SSL ciphers)
    Finally, does the Ironport support or plan to support in the future TLSv1.1 and TLSv1.2 ciphers?
    Response from TAC so far is the same as the referenced article - https://tools.cisco.com/bugsearch/bug/CSCur27131 which doesn't address all my points
    Paul

    Negating SSLv2 and SSLv3 in the cipher suite has no effect as long as only enabled TLSv1 is enabled.
    And reordering ciphers by strength won't bring anything since the client's ciphers order will always be preferred.
    Also, MD5 should be disabled as it's widely considered too weak for the job.
    My recommendation would be to use the following suite > HIGH:MEDIUM:!aNULL:!MD5

  • Cipher.getInstance closes Applet JAR file.

    I am trying to use a Cipher in a signed Applet in java plugin-1.4 under I.E. Once I execute a Cipher.getInstance the applet jar file is closed and I cannot create any new classes that havent been previously loaded from it. The classloader ends up returning an "IlleagleStateException: Zip file closed".
    Is this a known bug? Is there a workaround? Perhaps a way to re-open the JAR file.
    I have been combing the FAQ's without finding any other refrences to the problem.

    I haven't found a solution to the original problem but for someone else that is looking for a workaround for this. I found that if I use two JAR with my Cipher in the second one, I can still load class files out of the first. I.E. <PARAM NAME = java_archive VALUE = "supportClasses.jar,mainApplet.jar"> where mainApplet.jar contains the code that uses the Cipher.

  • Cisco Prime Infrastucture vulnerability SSL RC4 Cipher Suites Supported

    Hi All,
    I have a question on how to disable RC4 Cipher Suites Supported on Cisco Prime Infrastructure Platform.
    My Client have use Nessus Software to scan on prime. and found on below vulnerability
    SSL RC4 Cipher Suites Supported
    Cisco prime infrastructure deploy on latest 2.1
    we have gain the root access and modifier the ssl.conf and restart the service also unable to solve.
    /opt/CSCOlumos/httpd/ssl/backup/ssl.conf
    /opt/CSCOlumos/httpd/ssl/ssl.conf
    C:\Program Files\Tenable\Nessus>nessuscmd -v -p 443 -i 21643 192.168.1.55
    Starting nessuscmd 5.2.7
    Scanning '192.168.1.55'...
    Host 192.168.1.55 is up
    Discovered open port https (443/tcp) on 192.168.1.55
    [i] Plugin 21643 reported a result on port https (443/tcp) of 192.168.1.55
    + Results found on 192.168.1.55 :
       - Port https (443/tcp) is open
         [i] Plugin ID 21643
          | Here is the list of SSL ciphers supported by the remote server :
          | Each group is reported per SSL Version.
          | SSL Version : TLSv1
          |   Medium Strength Ciphers (>= 56-bit and < 112-bit key)
          |       DES-CBC-SHA                  Kx=RSA         Au=RSA      Enc=DES-C
          | C(56)          Mac=SHA1
          |       RC4-MD5                      Kx=RSA         Au=RSA      Enc=RC4(1
          | 8)             Mac=MD5
          |       RC4-SHA                      Kx=RSA         Au=RSA      Enc=RC4(1
          | 8)             Mac=SHA1
          |
          | SSL Version : SSLv3
          |   Medium Strength Ciphers (>= 56-bit and < 112-bit key)
          |       DES-CBC-SHA                  Kx=RSA         Au=RSA      Enc=DES-C
          | C(56)          Mac=SHA1
          |       DES-CBC-SHA                  Kx=RSA         Au=RSA      Enc=DES-C
          | C(56)          Mac=SHA1
          |   High Strength Ciphers (>= 112-bit key)
          |       EDH-RSA-DES-CBC3-SHA         Kx=DH          Au=RSA      Enc=3DES(
          | 68)            Mac=SHA1
          |       RC4-MD5                      Kx=RSA         Au=RSA      Enc=RC4(1
          | 8)             Mac=MD5
          |       RC4-SHA                      Kx=RSA         Au=RSA      Enc=RC4(1
          | 8)             Mac=SHA1
          | The fields above are :

    Hi ,
    "SSL RC4 Cipher Suites Supported" has been documented in bug CSCum03709. 
    CSCum03709    PI 2.0.0.0.294 with SSH vulnerabilities
    Presently, there is no workaround for this vulnerability, however, the fix will be implemented in
    Prime Infrastructure 2.2.which is planned to be released around the end of this year ( tentative)
    Thanks-
    Afroz
    ***Ratings Encourages Contributors ***

  • Com.sleepycat.db.Database.verify(), not working with encrypted db. bug?

    Hi,
    I have a berkeley database file encrypted with a password (In fact, there are two databases embedded in the same physical file). The Berkeley api version that I'm using is the 5.3.21:
    The databases work fine, and I can read all the encrypted data (in both databases)...
    However, if I try to verifiy the database with the method, com.sleepycat.db.Database.verify(), I get the following error...
    BDB0196 Encrypted checksum: no encryption key specified
    BDB0522 Page 0: metadata page corrupted
    BDB0196 Encrypted checksum: no encryption key specified
    BDB3016 C:\cneDir\env-cipher/inforep.db: pgin failed for page 0
    Even if setup the databaseConfig object with my password... This is the code that I'm using:
        private static void doVerify(String args[], String symmetricKey) {
            DatabaseConfig dbConfig;
            VerifyConfig verifyConfig;
            String filename;
            String dbName;
            boolean result;
            filename = args[0] + "/" + args[1];
            dbName   = args[2];
            dbConfig = new DatabaseConfig();
            dbConfig.setEncrypted(symmetricKey);
            System.out.println("Is encrypted: " + dbConfig.getEncrypted());
            dbConfig.setChecksum(true);
            verifyConfig = new VerifyConfig();
            verifyConfig.setNoOrderCheck(false);
            try {
                result = Database.verify(filename, dbName, System.out, verifyConfig, dbConfig);
                System.out.println("Everything is OK? " + result);
            } catch (Exception ex) {
                System.out.println("D OH!");
                ex.printStackTrace();
            }This forced me to take the source code of the Java API to see what is happening...
    Atfer looking the API source code, it seems to me that the method com.sleepycat.db.Database.verify(), never sets the password at any point of its execution... So, I take the source code and I modify the method to set my password (Hardcoded):
        public static boolean verify(final String fileName,
                                     final String databaseName,
                                     final java.io.PrintStream dumpStream,
                                     VerifyConfig verifyConfig,
                                     DatabaseConfig dbConfig)
            throws DatabaseException, java.io.FileNotFoundException {
            final Db db = DatabaseConfig.checkNull(dbConfig).createDatabase(null);
            //db.set_flags(DbConstants.DB_ENCRYPT);
            db.set_encrypt("1234", DbConstants.DB_ENCRYPT_AES);   //Here, 1234 is my password
            return db.verify(fileName, databaseName, dumpStream,
                             VerifyConfig.checkNull(verifyConfig).getFlags());
        }Atfer this modification, the method com.sleepycat.db.Database.verify() returns true and doesn't throw any exception. So, I'm guessing that this could be a bug, right??

    Hi Carlos,
    It is a bug and the fix will be included in the next release(6.0). Thank you for pointing out this issue.
    Regards,
    -Jin

  • Index with "or" clause (BUG still exists?)

    The change log for 2.3.10 mentions "Fixed a bug that caused incorrect query plans to be generated for predicates that used the "or" operator in conjunction with indexes [#15328]."
    But looks like the Bug still exists.
    I am listing the steps to-repro. Let me know if i have missed something (or if the bug needs to be fixed)
    DATA
    dbxml> openContainer test.dbxml
    dbxml> getDocuments
    2 documents found
    dbxml> print
    <node><value>a</value></node>
    <node><value>b</value></node>
    INDEX (just one string equality index on node "value")
    dbxml> listIndexes
    Index: unique-node-metadata-equality-string for node {http://www.sleepycat.com/2002/dbxml}:name
    Index: node-element-equality-string for node {}:value
    2 indexes found.
    QUERY
    setVerbose 2 2
    preload test.dbxml
    query 'let $temp := fn:compare("test", "test") = 0
    let $results := for $i in collection("test.dbxml")
    where ($temp or $i/node[value = ("a")])
    return $i
    return <out>{$temp}{$results}</out>'
    When $temp is true i expected the result set to contain both the records, but that was not the case with the index. It works well when there is no index!
    Result WITH INDEX
    dbxml> print
    <out>true<node><value>a</value></node></out>
    Result WITHOUT INDEX
    dbxml> print
    <out>true<node><value>a</value></node><node><value>b</value></node></out>

    Hi Vijay,
    This is a completely different bug, relating to predicate expressions that do not examine nodes. Please try the following patch, to see if it fixes this bug for you:
    --- dbxml-2.3.10-original/dbxml/src/dbxml/optimizer/QueryPlanGenerator.cpp     2007-04-18 10:05:24.000000000 +0100
    +++ dbxml-2.3.10/dbxml/src/dbxml/optimizer/QueryPlanGenerator.cpp     2007-08-08 11:32:10.000000000 +0100
    @@ -1566,11 +1572,12 @@
         else if(name == Or::name) {
              UnionQP *unionOp = new (&memMgr_) UnionQP(&memMgr_);
    +          result.operation = unionOp;
              for(VectorOfASTNodes::iterator i = args.begin(); i != args.end(); ++i) {
                   PathResult ret = generate(*i, ids);
                   unionOp->addArg(ret.operation);
    +               if(ret.operation == 0) result.operation = 0;
    -          result.operation = unionOp;
         // These operators use the presence of the node arguments, not their valueJohn

Maybe you are looking for

  • HP-UX vs. NT performace issue

    I have a J2EE application that I've recently ported from a WINNT development box to a 2-CPU HP L-class server. I am running Weblogic 6.1, SP1 on both machines. On a particularly memory-intensive piece of the application, I've notice a performance dro

  • 10.6.8 update sends mini mac into panic screen what now?

    After update mini mac is now a brick Unable to safe boot or use any key commands So is it time to reinstall software?

  • Problem with a query with WITH clause

    Hi, i'm facing with a problem, so i describe a little: create table schoolboys ( id integer, name varchar2(20) create table marks ( schoolboy_id integer, mark integer, mark_type char(1)) create table avg_marks ( schoolboy_id integer, avg_mark number

  • WHEN I CREATE  SOURCE SYSTEM IN BW

    Hi,   When i create source system in BW  it is automatically saying that it has RFC Destination already  exists in the source system. Do you want to transfer,check this destination or cancel the source system?   it has three option copy,check,cancel

  • Magic Mouse triggering Mission Control on remote machine, how do I stop it?

    I'm not sure if this is a bug or not, but here's the deal: sometimes, when I single finger scroll with my Magic Mouse, it will trigger Mission Control on the remote mac. Probably happens about 50% of the time. The other 50% it correctly scrolls the d