JDK-5051665 : The SHA1 MessageDigestSPI implementation is too slow
  • Type: Enhancement
  • Component: security-libs
  • Sub-Component: java.security
  • Affected Version: 1.4.2
  • Priority: P4
  • Status: Resolved
  • Resolution: Won't Fix
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2004-05-24
  • Updated: 2016-08-15
  • Resolved: 2016-08-15
Related Reports
Relates :  
JDK-5090493 - COMPILE SKIPPED: 'unsupported calling sequence' due to method signature
Description
Name: js151677			Date: 05/24/2004


A DESCRIPTION OF THE REQUEST :
I studied the performances of the SHA1 MessageDigestSPI SPI, and it is MUCH too slow. Lots of optimizations are possible, up to the point to make the digest TWICE faster!


JUSTIFICATION :
The SHA-1 (FIPS PUB 180-1 or 180-2, whose specification is published by NIST) is a very common standard secure hash which is part of the SHS (Secure Hash Standard) in U.S. It is also part of various protocols using it natively (HTTP, authentication protocols, secured signatures...)
It is also used to certify the content of files in archives (where it also competes with MD5), in a more secure way than just CRC32 or Adler32 used in ZIP/JAR archives.


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
It is needed for signing JARs. Its performance is critical to accelerate the verification of potentially very large files.
So optimization for performance (but still with correctness) is needed.
The two classes are a freely reusable implementation and test for SHA-1, whose performance (for large files) is more than TWICE the implementation in the JCE (tested on Java 1.5 RC 1 on Windows XP).

I am the author of these classes developped independantly of other open-source or commercial implementations that I tested but don't have the level of performance I have made here.

Onte: In the past I could have access to the current JCE sources, but today they don't seem to be accessible, or I did not find it.

ACTUAL -
The JCE implementation of SHA1 (also MD5, SHA-224, SHA256, SHA-384, SHA-256 on which I am working) is still too slow.



CUSTOMER SUBMITTED WORKAROUND :
This is not a bug, just a RFE for performance.
(Incident Review ID: 270795) 
======================================================================
Comments
With modern processors equipped with hardware optimizations for SHA1 and SHA2, and SHA1 in some cases is being phased out. There is no point pursuing this RFE.
15-08-2016
EVALUATION This bug talks about improving the performance of the SHA-1 code in order to improve JAR signing performance (I assume the submitter actually meant JAR verification, which is much more frequent than signing). A couple of notes first: (a) for JAR signing/verification, the JAR file is not hashed as a whole, instead each class is hashed separately. As such, it is the SHA-1 performance for small pieces of data (500-10000 bytes) that is relevant. (b) hashing is not where the majority of the time is spent in JAR verification. In other words, SHA-1 may not be the low hanging fruit. All that being said, I certainly agree that performance is a valuable goal, both for JAR verification in general as well as SHA-1 in particular. However, I am unable to verify the claim by the submitter that our SHA-1 implementation could be sped up by 100% (for large inputs). The code attached to this bug report does not include SHA-1 related code, only some Diffie-Hellman application code. Given that, I have examined two other SHA-1 implementations, BouncyCastle 1.23 and IAIK 3.03 on Windows for 64 byte, 4 kbyte, and 256 kbyte inputs using both the client and server HotSpot compiler with JDK 1.5-beta1. BouncyCastle was slower in all tests. IAIK was the same speed using the server compiler (-0.3% to +3.0%) but faster when using the client compiler (+25% to +45%). Obviously 45% is a significant speedup. However, this is achieved by aggressive loop unrolling and similar tweaks, which are not a prefered methods of optimization. The reason is that they increase footprint and may be ineffective or even counter productive and some (more advanced) JVM implementations. The fact that Sun and IAIK SHA-1 implementation are almost the same speed when using the HotSpot server compiler is a case in point. As a result, I do not plan to make changes of that nature. If the submitter has more specific suggestions, I would be most interested to hear them. Lacking that, I cannot see any promising optimization opportunities at this point, so I am marking the bug incomplete. If I receive no further comments, I will still keep this bug open, but it become a low priority. ###@###.### 2004-05-24 No further information recevied, downgrading to P5. ###@###.### 2005-04-01 02:05:09 GMT
24-05-2004