constant time compare is not used anywhere important

[Bernd Eckenfels]

Hello,

while researching on the SSL3 rsaHandshakeFix (dont ask :) I noticed
that JSSE uses Arrays.equals() in some places to compare
byte arrays with cryptographic material, at least
in one instance it does even use it to verify and reject a MAC in a
network protocol.

I am not sure if this specific instance is anyway near to beeing
relevant. Especially as I suspect there might be things
(like intrinsics) going on as this is really wrong all over
the place.

I think the openjdk code should anyway follow best practice and avoid a
optimized equals method in all crypto code.


functions working on key material, password hashes or macs:

http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8-b132/java/security/Identity.java#272
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8-b132/javax/crypto/spec/SecretKeySpec.java#229
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8-b132/sun/security/pkcs11/wrapper/Functions.java#460
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8-b132/sun/security/rsa/RSASignature.java#197
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8-b132/sun/security/pkcs12/PKCS12KeyStore.java#2005
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8-b132/com/sun/crypto/provider/AESCrypt.java#91
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8-b132/com/sun/crypto/provider/CipherCore.java#570
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8-b132/com/sun/crypto/provider/PBKDF2KeyImpl.java#155
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8-b132/java/security/Signature.java#1274
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8-b132/com/sun/crypto/provider/DESKey.java#116

http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8-b132/sun/security/ssl/HandshakeMessage.java#1910



Most likely uncritical but still in crypto code:

http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8-b132/java/security/cert/Certificate.java#116
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8-b132/com/sun/crypto/provider/PBMAC1Core.java#138
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8-b132/sun/security/krb5/internal/KRBError.java#494
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8-b132/java/security/cert/X509CertSelector.java#2072
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8-b132/org/ietf/jgss/ChannelBinding.java#194
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8-b132/javax/crypto/spec/RC2ParameterSpec.java#144
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8-b132/sun/security/pkcs11/P11KeyStore.java#2463


(there are more)

I guess all of them can be converted to MessageDigst.equals(). And as
this is branch free, it might not even be slower. (I am not sure if
an intrinsic applied here)

Gruss
Bernd

PS: (i know, non-comment policy but I dont really see a reason to
embargo this. Java is hardly a good candidate for safe crypto
(unfortunatelly).