Posts

Showing posts from June, 2009

TLS and NIST'S Policy on Hash Functions

NIST'S Policy on Hash Functions March 15, 2006: The SHA-2 family of hash functions (i.e., SHA-224, SHA-256, SHA-384 and SHA-512) may be used by Federal agencies for all applications using secure hash algorithms. Federal agencies should stop using SHA-1 for digital signatures, digital time stamping and other applications that require collision resistance as soon as practical, and must use the SHA-2 family of hash functions for these applications after 2010. After 2010, Federal agencies may use SHA-1 only for the following applications: hash-based message authentication codes (HMACs); key derivation functions (KDFs); and random number generators (RNGs). Regardless of use, NIST encourages application and protocol designers to use the SHA-2 family of hash functions for all new applications and protocols. TLS specifics of hash functions MAC constructionsA number of operations in the TLS record and handshake layer require a keyed Message Authentication Code (MAC) to protect mes...

JSSE Troubleshooting: Certificates Order in TLS Handshaking

Issue: Failed with a exception: java.security.cert.CertPathValidatorException: subject/issuer name chaining check failed. Example: Test case: 1 // 2 // JSSE Troubleshooting: Disordered Certificate List in TLS Handshaking 3 // 4 import java.net.*; 5 6 public class DisorderedCertificateList { 7 public static void main(String[] Arguments) throws Exception { 8 URL url = new URL("https://myservice.example.com/"); 9 URLConnection connection = url.openConnection(); 10 11 connection.getInputStream().close(); 12 } 13 } Test environment: The HTTPS server, myservice.example.com, is configurated with a certificate path that the certificates in the path is out of order. For example, the expected certificate path is server_certificate -> intermediate ca -> seld-signed root ca. However, the certificate path is configurated as server_certificate -> seld-signed root ca -> intermediate ca. Test Result: Exception in ...

RSA AlgorithmIdentifier of X.509 Certificate

By far, RSA is a most wide used cryptography algorithm. Both ITU-T X.509 and IETF PKIX WG define the RSA algorithm identifier, however, they are not identical. ITU-T X.509[1] defines the algorithm as: rsa ALGORITHM ::= { KeySize IDENTIFIED BY id-ea-rsa } KeySize ::= INTEGER id-ea-rsa OBJECT IDENTIFIER ::= {joint-iso-itu-t(2) ds(5) algorithm(8) encryptionAlgorithm(1) rsa(1)} While IETF PKIX WG[2] defines the algorithm as: rsaPublicKey ALGORITHM-ID ::= {OID rsaEncryption PARMS NULL} rsaEncryption OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) rsaEncryption(1)} There two differences: 1. different OID. ITU-T defines it as "2.5.8.1.1", while PKIX WG defines it as "1.2.840.113549.1.1.1" 2. different algorithm parameters ITU-T defines a parameter for RSA, "KeySize", while PKIX WG defines it as null. Indeed, the RSA encryption algorithm PKIX WG u...