Open Standards in Cryptography and Cryptographic Protocols

Though I will talk about the types of cryptographies in one of my later blogs in this series, each of the cryptographic techniques involves using some open standards that provide a relevant focus to these studies. This blog describes some of the standards that govern the cryptographic techniques that I’ll talk about later.

• DES (Data Encryption Standard): This was officially declared as a standard for United States by the National Bureau of Standards in 1976. The size of the key is 56 bits so that it can fit on a single chip. As I mentioned in my first blog, that greater the size of the key, greater will be the security. A 56-bit size was considered small because cryptanalysts were able to crack the key in 22 hours and 15 minutes in the year 1999 using brute force technique, after which the DES standard was considered to be unsafe.
• Triple DES: After the failure of DES, a robust form known as Triple DES was devised. It is so named because it applies the DES algorithm thrice on the same block. The key size in each of the rounds is 56-bit. The algorithm is strongest when the keys are all independent and unequal resulting in 3 x 56 = 168 independent key bits. National Institute of Standards and Technology (NIST) considers it to be safe until at least 2030. When all the keys are identical, this algorithm is as weak as DES and is, therefore, not recommended by NIST. This particular option is backward compatible with DES.
• Advanced Encryption Standard: In 2003, the US Government announced that the AES encryption algorithm may be used for classified information. This standard comprises 3 ciphers – AES-128 (for SECRET level), AES-192 and AES-256 (for TOP SECRET level). Each of these ciphers has a 128-bit block size, with key sizes of 128, 192 and 256 bits, respectively. Suppose, using the 256-bit AES and a password length of 6 characters eg., “passwd” with 5 distinct characters, there will be 5^6=15626 options to choose from. If another letter is added to the password, the result would be 5^7=78125 which is a tremendous increase in output. Graphically it would look as below:
  Since the brute force attack only looks for passwords of the specified length and  attackers do not know the length of the password, they gradually keep increasing it after every unsuccessful attempt.  If they assume that only small letters were used and password length is 6 letters, there will be 26^6= 308915776 attempts. Adding one more character would make it 8031810176 i.e. 7722894400 more operations. If the number of characters in the password is increased from 6 to 8, one can imagine the tremendous increase in attempts that the hacker has to make. Add to it the complexity if both small and capital letters, numerals and special characters are used. The complexity would become in astronomical numbers which is very difficult for a hacker to crack since it would take years to get the right combination of characters that make up the password even on a highly specialized machine with sufficient hardware.
• Diffie–Hellman key exchange (D-H): This is a cryptographic protocol in which each party generates a public-private key pair distributing the public key. After obtaining an authentic copy of each other’s public keys, both parties can compute a shared secret offline. The shared secret can then be used as a cipher. The D-H scheme has been widely adopted. It is used for securing Internet Protocol communications. 
• SSL/TLS: TLS and its predecessor, Secure Socket Layer (SSL), are cryptographic protocols that provide transport level security between two points. The certificates necessary for TLS are handled in the form of X.509 certificates. When used with HTTP is known as HTTPS Session. It also supports other applications like Simple Mail Transfer protocol (SMTP). How it works is that the client and server first begin a handshake in order to identify each other. This is done by using digital certificates and public key cryptography. After they know each other, i.e. when the handshake is concluded, a secure connection is established, which is encrypted and decrypted with the key material until the connection closes.
• XML Encryption: It is a W3C Standard. This specification defines how to encrypt the contents of an XML element (containing cipher text, keying information, and algorithms). Unlike SSL, a point-to-point protocol that is decrypted at each point, XML encryption can be used in solutions where there are multiple network nodes between the front end application and the end data source. Also, SSL and TLS do not have the capacity to encrypt only specific parts of the document or to encrypt different portions of the document using different keys—which are critical to XML encryption. Apache’s XML Security package, Verisign’s open-source TSIK (Trust Services Integration Kit) package, as well as many others provide XML Encryption functionality.
• XML Signature: It is a W3C Standard. It relies on public key cryptography. Any part of an XML document can be digitally signed, by using DSA algorithm for example—becoming self-validating when the document recipient has the signer’s public key. It is used in SOAP (i.e. to communicate with Web Services), SAML etc. Apache’s XML Security package, Verisign’s open-source TSIK (Trust Services Integration Kit) package, as well as many others, provide XML signature capability.
• Security Assertion Markup Language (SAML): is an XML based standard by OASIS, for exchanging authentication and authorization information between an identity provider (for., a web application like portal) and a service provider (for e.g., a web service) commonly onto  standard protocols like SOAP (called SAML SOAP binding, that specifies how a SAML message is encapsulated in SOAP envelope). It is one of the building blocks for SSO that I’ll talk about in a later blog. How it works is that a principal (often the user), enrolls with the identity provider using its authentication services. When the principal requests for a service, the identity provider produces a SAML assertion (stating that the principal did indeed authenticate with the identity provider and is permitted to perform a certain action, A, on a certain resource, R, given evidence, E) and passes it to the service provider. This assertion could be digitally signed using XML Signature. On the basis of this assertion, the service provider will make an access control decision i.e. decide whether or not to give access to the principal. The SAML protocol defines how certain SAML assertions are packaged in a SAML request and response. SAML specifications recommend SSL/TLS for transport-level security and XML Signature and XML Encryption for message-level security.
• Kerberos: is an authentication protocol where both the client and server verify each other’s identity securely over an insecure network. For this it requires a trusted third party.
• Web Services Security (WSS): is an OASIS standard and plays a key role in the security of Web Services. The development of WSS continues, including work involving SAML. The protocol specifies how integrity and confidentiality can be enforced on messages and allows the communication of various security token formats, such as SAML, Kerberos, and X.509. 
• Diffie–Hellman key exchange (D-H): This is a cryptographic protocol in which each party generates a public-private key pair distributing the public key. After obtaining an authentic copy of each other’s public keys, both parties can compute a shared secret offline. The shared secret can then be used as a cipher. The D-H scheme has been widely adopted. It is used for securing Internet Protocol communications.
• SSL/TLS: TLS and its predecessor, Secure Socket Layer (SSL), are cryptographic protocols that provide transport level security between two points. The certificates necessary for TLS are handled in the form of X.509 certificates. When used with HTTP is known as HTTPS Session. It also supports other applications like Simple Mail Transfer protocol (SMTP). How it works is that the client and server first begin a handshake in order to identify each other. This is done by using digital certificates and public key cryptography. After they know each other, i.e. when the handshake is concluded, a secure connection is established, which is encrypted and decrypted with the key material until the connection closes.
• XML Encryption: It is a W3C Standard. This specification defines how to encrypt the contents of an XML element (containing cipher text, keying information, and algorithms). Unlike SSL, a point-to-point protocol that is decrypted at each point, XML encryption can be used in solutions where there are multiple network nodes between the front end application and the end data source. Also, SSL and TLS do not have the capacity to encrypt only specific parts of the document or to encrypt different portions of the document using different keys—which are critical to XML encryption. Apache’s XML Security package, Verisign’s open-source TSIK (Trust Services Integration Kit) package, as well as many others provide XML Encryption functionality.
• XML Signature: It is a W3C Standard. It relies on public key cryptography. Any part of an XML document can be digitally signed, by using DSA algorithm for example—becoming self-validating when the document recipient has the signer’s public key. It is used in SOAP (i.e. to communicate with Web Services), SAML etc. Apache’s XML Security package, Verisign’s open-source TSIK (Trust Services Integration Kit) package, as well as many others, provide XML signature capability.
• Security Assertion Markup Language (SAML): is an XML based standard by OASIS, for exchanging authentication and authorization information between an identity provider for., a web application like portal) and a service provider (for e.g., a web service) commonly onto  standard protocols like SOAP (called SAML SOAP binding, that specifies how a SAML message is encapsulated in SOAP envelope). It is one of the building blocks for SSO that I’ll talk about in a later blog. How it works is that a principal (often the user), enrolls with the identity provider using its authentication services. When the principal requests for a service, the identity provider produces a SAML assertion (stating that the principal did indeed authenticate with the identity provider and is permitted to perform a certain action, A, on a certain resource, R, given evidence, E) and passes it to the service provider. This assertion could be digitally signed using XML Signature. On the basis of this assertion, the service provider will make an access control decision i.e. decide whether or not to give access to the principal. The SAML protocol defines how certain SAML assertions are packaged in a SAML request and response. SAML specifications recommend SSL/TLS for transport-level security and XML Signature and XML Encryption for message-level security.
• Kerberos: is an authentication protocol where both the client and server verify each other’s identity securely over an insecure network. For this it requires a trusted third party.
• Web Services Security (WSS): is an OASIS standard and plays a key role in the security of Web Services. The development of WSS continues, including work involving SAML. The protocol specifies how integrity and confidentiality can be enforced on messages and allows the communication of various security token formats, such as SAML, Kerberos, and X.509.

Advertisement