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 message inte…

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 thread "…

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 used is defined by PKCS#1 [3][4], it is the industry standard definition. Most of the …