JDK-6346265 : GSSContext/Krb5 mechanism should not cache Cipher object
  • Type: Bug
  • Component: security-libs
  • Sub-Component: java.security
  • Affected Version: 6
  • Priority: P5
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2005-11-04
  • Updated: 2010-11-04
  • Resolved: 2005-12-03
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other JDK 6
5.0u7Fixed 6 b63Fixed
Description
sun.security.jgss.krb5.CipherHelper creates a private desCipher object and caches it.

this caching should not be done.  a new Cipher object should be retrieved as needed.  the caching can pose problems, for example, in multi-threaded environments since access to the object is not synchronized.
in JGSS workspace, 2 classes -- AesDkCrypto and ArcFourCrypto -- in the sun.security.krb5.internal.crypto.dk package also cache the Cipher in a similar style.
Comments
EVALUATION The cache mechanism was introduced to improve the performance of cipher initializing. However, it's not so important now since: 1. Only getInstance() is cached, init() is still called now and then. 2. The Cipher.getInstance() code was completely rewritten in Tiger. I [Andreas.Sterbenz] did some quick benchmarking just now, and it is about 10 times as fast as in 1.4.2. Also, a multi-thread test shows the cache bring errors.
09-11-2005