[SNMP4J] SnmpV3 Encryption Provider as Configurable parameter

2011-11-09 Thread jones vinu
Hi Frank,  
 Yes I have tried the provider with The Provider positions as 1 and it works.
Sorry for the wrong message on this.

Thanks
Jones

___
SNMP4J mailing list
SNMP4J@agentpp.org
http://lists.agentpp.org/mailman/listinfo/snmp4j


Re: [SNMP4J] SnmpV3 Encryption Provider as Configurable parameter

2011-11-04 Thread Frank Fock
Hi Peter,

The Provider positions are 1-based. You wrote that you used 0
as position. That won't work (-1 is returned). Have you tried
it with position 1?

Best regards,
Frank

Am 03.11.2011 22:56, schrieb Frank Fock:
 Hi Peter,

 I will try to add the requested configurability.
 The ticket number is SFJ-52.

 Best regards,
 Frank


 Am 02.11.2011 13:36, schrieb Peter Verthez:
 Hi Frank,

 To elaborate on this (because the context wasn't really explained in the
 original mail of Jones):

 We found that in performance tests on our product (with a big number of
 agents) that there was a high thread contention for SNMPv3 managed
 agents.   A jstack showed that a lot of our threads were running in the
 following stack frame at the moment of the jstack, which indicates that
 this functionality generates a relatively big load:

 JM-282 prio=3 tid=0x00013f032800 nid=0x391 runnable
 [0xfffc89f38000]
   java.lang.Thread.State: RUNNABLE
at sun.security.pkcs11.wrapper.PKCS11.C_DestroyObject(Native Method)
at sun.security.pkcs11.SessionKeyRef.dispose(P11Key.java:1070)
at
 sun.security.pkcs11.SessionKeyRef.drainRefQueueBounded(P11Key.java:1046)
at sun.security.pkcs11.SessionKeyRef.init(P11Key.java:1061)
at sun.security.pkcs11.P11Key.init(P11Key.java:97)
at sun.security.pkcs11.P11Key$P11SecretKey.init(P11Key.java:374)
at sun.security.pkcs11.P11Key.secretKey(P11Key.java:266)
at
 sun.security.pkcs11.P11SecretKeyFactory.createKey(P11SecretKeyFactory.java:222)
at
 sun.security.pkcs11.P11SecretKeyFactory.convertKey(P11SecretKeyFactory.java:131)
at sun.security.pkcs11.P11Cipher.engineGetKeySize(P11Cipher.java:828)
at javax.crypto.Cipher.b(DashoA13*..)
at javax.crypto.Cipher.a(DashoA13*..)
at javax.crypto.Cipher.a(DashoA13*..)
at javax.crypto.Cipher.a(DashoA13*..)
- locked0xfffd81aa1ca8   (a java.lang.Object)
at javax.crypto.Cipher.init(DashoA13*..)
at javax.crypto.Cipher.init(DashoA13*..)
at org.snmp4j.security.PrivDES.encrypt(PrivDES.java:111)
at org.snmp4j.security.USM.generateResponseMessage(USM.java:461)
at org.snmp4j.security.USM.generateRequestMessage(USM.java:215)
at org.snmp4j.mp.MPv3.prepareOutgoingMessage(MPv3.java:767)
at
 org.snmp4j.MessageDispatcherImpl.sendPdu(MessageDispatcherImpl.java:444)
at org.snmp4j.Snmp.sendMessage(Snmp.java:1067)
at org.snmp4j.Snmp.send(Snmp.java:895)
- locked0xfffd81aa2068   (a 
 org.snmp4j.Snmp$SyncResponseListener)
at org.snmp4j.Snmp.send(Snmp.java:875)

 Originally, our performance team pointed in the direction of SNMP4J,
 saying that SNMP4J should probably not call Cipher.init() so much, but I
 could show them that section 8.1.1.1 in RFC 2574 requires to init the
 Cipher for each packet separately.

 So then we started looking at alternatives, and we found that if we
 hacked SNMP4J to use the Apache BouncyCastle security provider, the
 thread contention was gone and our application behaved properly.   So
 presumably the Sun JCE security provider that is used by default by
 SNMP4J is not very optimally written.

 Now, we would not like to have to maintain our own patch on SNMP4J, so
 that is where the question from Jones came from: we tried to change the
 default security provider that SNMP4J uses without touching SNMP4J's
 code, but Security.insertProviderAt() apparently doesn't help in that
 even if we insert the provider at position 0.

 Could an API be added to permit applications to change the security
 provider that SNMP4J uses?

 Best regards,
 Peter.


 On 24/10/2011 9:00, jones vinu wrote:
 Hi Frank,
 We would want to change the Cipher encryption provider in 
 our application used by snmp4j since the Sun JCE provider is heavy weight . 
 But unfortunately we have not been able to change it without modifying 
 snmp4j since the Sun JCE provider is considered as the default provider 
 even when we  insert Apache bouncy castle as the first priority provider. 
 Hence it would be good if we have option to configure the provider as a 
 Configurable parameter in some property file.

 Security.insertProviderAt(new BouncyCastleProvider(), 0);
try {
Cipher alg = Cipher.getInstance(DESede/CBC/NoPadding);
System.out.println(alg.getProvider());
} catch (NoSuchAlgorithmException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (NoSuchPaddingException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
 Output :SunJCE version 1.6

 And using it as
 Cipher alg = Cipher.getInstance(DESede/CBC/NoPadding,BC);
 Output :BC version 1.4

 Thanks
 Jones

 ___
 SNMP4J mailing list
 SNMP4J@agentpp.org
 

Re: [SNMP4J] SnmpV3 Encryption Provider as Configurable parameter

2011-11-03 Thread Frank Fock
Hi Peter,

I will try to add the requested configurability.
The ticket number is SFJ-52.

Best regards,
Frank


Am 02.11.2011 13:36, schrieb Peter Verthez:
 Hi Frank,

 To elaborate on this (because the context wasn't really explained in the
 original mail of Jones):

 We found that in performance tests on our product (with a big number of
 agents) that there was a high thread contention for SNMPv3 managed
 agents.   A jstack showed that a lot of our threads were running in the
 following stack frame at the moment of the jstack, which indicates that
 this functionality generates a relatively big load:

 JM-282 prio=3 tid=0x00013f032800 nid=0x391 runnable
 [0xfffc89f38000]
  java.lang.Thread.State: RUNNABLE
   at sun.security.pkcs11.wrapper.PKCS11.C_DestroyObject(Native Method)
   at sun.security.pkcs11.SessionKeyRef.dispose(P11Key.java:1070)
   at
 sun.security.pkcs11.SessionKeyRef.drainRefQueueBounded(P11Key.java:1046)
   at sun.security.pkcs11.SessionKeyRef.init(P11Key.java:1061)
   at sun.security.pkcs11.P11Key.init(P11Key.java:97)
   at sun.security.pkcs11.P11Key$P11SecretKey.init(P11Key.java:374)
   at sun.security.pkcs11.P11Key.secretKey(P11Key.java:266)
   at
 sun.security.pkcs11.P11SecretKeyFactory.createKey(P11SecretKeyFactory.java:222)
   at
 sun.security.pkcs11.P11SecretKeyFactory.convertKey(P11SecretKeyFactory.java:131)
   at sun.security.pkcs11.P11Cipher.engineGetKeySize(P11Cipher.java:828)
   at javax.crypto.Cipher.b(DashoA13*..)
   at javax.crypto.Cipher.a(DashoA13*..)
   at javax.crypto.Cipher.a(DashoA13*..)
   at javax.crypto.Cipher.a(DashoA13*..)
   - locked0xfffd81aa1ca8  (a java.lang.Object)
   at javax.crypto.Cipher.init(DashoA13*..)
   at javax.crypto.Cipher.init(DashoA13*..)
   at org.snmp4j.security.PrivDES.encrypt(PrivDES.java:111)
   at org.snmp4j.security.USM.generateResponseMessage(USM.java:461)
   at org.snmp4j.security.USM.generateRequestMessage(USM.java:215)
   at org.snmp4j.mp.MPv3.prepareOutgoingMessage(MPv3.java:767)
   at
 org.snmp4j.MessageDispatcherImpl.sendPdu(MessageDispatcherImpl.java:444)
   at org.snmp4j.Snmp.sendMessage(Snmp.java:1067)
   at org.snmp4j.Snmp.send(Snmp.java:895)
   - locked0xfffd81aa2068  (a org.snmp4j.Snmp$SyncResponseListener)
   at org.snmp4j.Snmp.send(Snmp.java:875)

 Originally, our performance team pointed in the direction of SNMP4J,
 saying that SNMP4J should probably not call Cipher.init() so much, but I
 could show them that section 8.1.1.1 in RFC 2574 requires to init the
 Cipher for each packet separately.

 So then we started looking at alternatives, and we found that if we
 hacked SNMP4J to use the Apache BouncyCastle security provider, the
 thread contention was gone and our application behaved properly.   So
 presumably the Sun JCE security provider that is used by default by
 SNMP4J is not very optimally written.

 Now, we would not like to have to maintain our own patch on SNMP4J, so
 that is where the question from Jones came from: we tried to change the
 default security provider that SNMP4J uses without touching SNMP4J's
 code, but Security.insertProviderAt() apparently doesn't help in that
 even if we insert the provider at position 0.

 Could an API be added to permit applications to change the security
 provider that SNMP4J uses?

 Best regards,
 Peter.


 On 24/10/2011 9:00, jones vinu wrote:
 Hi Frank,
We would want to change the Cipher encryption provider in our 
 application used by snmp4j since the Sun JCE provider is heavy weight . But 
 unfortunately we have not been able to change it without modifying snmp4j 
 since the Sun JCE provider is considered as the default provider even when 
 we  insert Apache bouncy castle as the first priority provider. Hence it 
 would be good if we have option to configure the provider as a Configurable 
 parameter in some property file.

 Security.insertProviderAt(new BouncyCastleProvider(), 0);
   try {
   Cipher alg = Cipher.getInstance(DESede/CBC/NoPadding);
   System.out.println(alg.getProvider());
   } catch (NoSuchAlgorithmException e) {
   // TODO Auto-generated catch block
   e.printStackTrace();
   } catch (NoSuchPaddingException e) {
   // TODO Auto-generated catch block
   e.printStackTrace();
   }
 Output :SunJCE version 1.6

 And using it as
Cipher alg = Cipher.getInstance(DESede/CBC/NoPadding,BC);
 Output :BC version 1.4

 Thanks
 Jones

 ___
 SNMP4J mailing list
 SNMP4J@agentpp.org
 http://lists.agentpp.org/mailman/listinfo/snmp4j


___
SNMP4J mailing list
SNMP4J@agentpp.org
http://lists.agentpp.org/mailman/listinfo/snmp4j


Re: [SNMP4J] SnmpV3 Encryption Provider as Configurable parameter

2011-11-02 Thread Peter Verthez
Hi Frank,

To elaborate on this (because the context wasn't really explained in the 
original mail of Jones):

We found that in performance tests on our product (with a big number of 
agents) that there was a high thread contention for SNMPv3 managed 
agents.   A jstack showed that a lot of our threads were running in the 
following stack frame at the moment of the jstack, which indicates that 
this functionality generates a relatively big load:

JM-282 prio=3 tid=0x00013f032800 nid=0x391 runnable 
[0xfffc89f38000]
java.lang.Thread.State: RUNNABLE
 at sun.security.pkcs11.wrapper.PKCS11.C_DestroyObject(Native Method)
 at sun.security.pkcs11.SessionKeyRef.dispose(P11Key.java:1070)
 at 
sun.security.pkcs11.SessionKeyRef.drainRefQueueBounded(P11Key.java:1046)
 at sun.security.pkcs11.SessionKeyRef.init(P11Key.java:1061)
 at sun.security.pkcs11.P11Key.init(P11Key.java:97)
 at sun.security.pkcs11.P11Key$P11SecretKey.init(P11Key.java:374)
 at sun.security.pkcs11.P11Key.secretKey(P11Key.java:266)
 at 
sun.security.pkcs11.P11SecretKeyFactory.createKey(P11SecretKeyFactory.java:222)
 at 
sun.security.pkcs11.P11SecretKeyFactory.convertKey(P11SecretKeyFactory.java:131)
 at sun.security.pkcs11.P11Cipher.engineGetKeySize(P11Cipher.java:828)
 at javax.crypto.Cipher.b(DashoA13*..)
 at javax.crypto.Cipher.a(DashoA13*..)
 at javax.crypto.Cipher.a(DashoA13*..)
 at javax.crypto.Cipher.a(DashoA13*..)
 - locked 0xfffd81aa1ca8 (a java.lang.Object)
 at javax.crypto.Cipher.init(DashoA13*..)
 at javax.crypto.Cipher.init(DashoA13*..)
 at org.snmp4j.security.PrivDES.encrypt(PrivDES.java:111)
 at org.snmp4j.security.USM.generateResponseMessage(USM.java:461)
 at org.snmp4j.security.USM.generateRequestMessage(USM.java:215)
 at org.snmp4j.mp.MPv3.prepareOutgoingMessage(MPv3.java:767)
 at 
org.snmp4j.MessageDispatcherImpl.sendPdu(MessageDispatcherImpl.java:444)
 at org.snmp4j.Snmp.sendMessage(Snmp.java:1067)
 at org.snmp4j.Snmp.send(Snmp.java:895)
 - locked 0xfffd81aa2068 (a org.snmp4j.Snmp$SyncResponseListener)
 at org.snmp4j.Snmp.send(Snmp.java:875)

Originally, our performance team pointed in the direction of SNMP4J, 
saying that SNMP4J should probably not call Cipher.init() so much, but I 
could show them that section 8.1.1.1 in RFC 2574 requires to init the 
Cipher for each packet separately.

So then we started looking at alternatives, and we found that if we 
hacked SNMP4J to use the Apache BouncyCastle security provider, the 
thread contention was gone and our application behaved properly.   So 
presumably the Sun JCE security provider that is used by default by 
SNMP4J is not very optimally written.

Now, we would not like to have to maintain our own patch on SNMP4J, so 
that is where the question from Jones came from: we tried to change the 
default security provider that SNMP4J uses without touching SNMP4J's 
code, but Security.insertProviderAt() apparently doesn't help in that 
even if we insert the provider at position 0.

Could an API be added to permit applications to change the security 
provider that SNMP4J uses?

Best regards,
Peter.


On 24/10/2011 9:00, jones vinu wrote:
 Hi Frank,
   We would want to change the Cipher encryption provider in our 
 application used by snmp4j since the Sun JCE provider is heavy weight . But 
 unfortunately we have not been able to change it without modifying snmp4j 
 since the Sun JCE provider is considered as the default provider even when we 
  insert Apache bouncy castle as the first priority provider. Hence it would 
 be good if we have option to configure the provider as a Configurable 
 parameter in some property file.

 Security.insertProviderAt(new BouncyCastleProvider(), 0);
  try {
  Cipher alg = Cipher.getInstance(DESede/CBC/NoPadding);
  System.out.println(alg.getProvider());
  } catch (NoSuchAlgorithmException e) {
  // TODO Auto-generated catch block
  e.printStackTrace();
  } catch (NoSuchPaddingException e) {
  // TODO Auto-generated catch block
  e.printStackTrace();
  }
 Output :SunJCE version 1.6

 And using it as
   Cipher alg = Cipher.getInstance(DESede/CBC/NoPadding,BC);
 Output :BC version 1.4

 Thanks
 Jones

 ___
 SNMP4J mailing list
 SNMP4J@agentpp.org
 http://lists.agentpp.org/mailman/listinfo/snmp4j


-- 
Peter Verthez
Systems Engineer Network Mgt.
Alcatel-Lucent Bell NV


___
SNMP4J mailing list
SNMP4J@agentpp.org
http://lists.agentpp.org/mailman/listinfo/snmp4j


[SNMP4J] SnmpV3 Encryption Provider as Configurable parameter

2011-10-24 Thread jones vinu
Hi Frank,
 We would want to change the Cipher encryption provider in our 
application used by snmp4j since the Sun JCE provider is heavy weight . But 
unfortunately we have not been able to change it without modifying snmp4j since 
the Sun JCE provider is considered as the default provider even when we  insert 
Apache bouncy castle as the first priority provider. Hence it would be good if 
we have option to configure the provider as a Configurable parameter in some 
property file.

Security.insertProviderAt(new BouncyCastleProvider(), 0);
        try {
            Cipher alg = Cipher.getInstance(DESede/CBC/NoPadding);
            System.out.println(alg.getProvider());
        } catch (NoSuchAlgorithmException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        } catch (NoSuchPaddingException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }
Output :SunJCE version 1.6

And using it as 
 Cipher alg = Cipher.getInstance(DESede/CBC/NoPadding,BC);
Output :BC version 1.4

Thanks
Jones

___
SNMP4J mailing list
SNMP4J@agentpp.org
http://lists.agentpp.org/mailman/listinfo/snmp4j