Friday, 31 July 2015

Hash-based message authentication code

In cryptography, a keyed-hash message authentication code (HMAC) is a specific construction for calculating a message authentication code (MAC) involving a cryptographic hash function in combination with a secret cryptographic key.

As with any MAC, it may be used to simultaneously verify both the data integrity and the authentication of a message.

Any cryptographic hash function, such as MD5 or SHA-1, may be used in the calculation of an HMAC; the resulting MAC algorithm is termed HMAC-MD5 or HMAC-SHA1 accordingly.

The cryptographic strength of the HMAC depends upon the cryptographic strength of the underlying hash function, the size of its hash output, and on the size and quality of the key.

An iterative hash function breaks up a message into blocks of a fixed size and iterates over them with a compression function.

For example, MD5 and SHA-1 operate on 512-bit blocks. The size of the output of HMAC is the same as that of the underlying hash function (128 or 160 bits in the case of MD5 or SHA-1, respectively), although it can be truncated if desired.

HMAC-SHA1 and HMAC-MD5 are used within the IPsec and TLS protocols.

Signature generating algorithm on Client and Server side


import javax.crypto.Mac;

import javax.crypto.spec.SecretKeySpec;

import org.apache.commons.codec.binary.Base64;

import org.apache.log4j.Logger;

import com.francetelecom.csrtool.model.logging.FuncLogging;

import com.francetelecom.csrtool.utils.CSRToolUtil;


 * Utility class to generate HMAC message digest based on key and (SHA256/SHA512) algorithm 


public class HMACGenerator {

        /** HMAC256 **/

        public static final String HMAC256 = "HmacSHA256";

        /** HMAC512 **/

        public static final String HMAC512 = "HmacSHA512";

        /** LOGGER Constant */

        private static final Logger LOGGER = Logger.getLogger(HMACGenerator.class);


         * Generates a encrypted message digest based on HMACSHA256 or HMACSHA512 algorithm on the data                                           and specific key

         * @param base64Key - base64 private key

         * @param data refers to the data need to be encrypted

         * @param algorithm refers to the message digest algorithm been used (256 -> HMACSHA256) and (512                                                                   -> HMACSHA512)

         * @return HMAC encrypted String


        public static String generateHMACUsingBase64Key(String base64Key, String data) {

                if(Util.isStringNullOrEmpty(base64Key) || Util.isStringNullOrEmpty(data)) {

                        return null;


                // Decode Base64 key (string) to bytes

                byte[] secretkeyByte = Base64.decodeBase64(base64Key.getBytes());

                // Generate secret key specific to algorithm

                SecretKeySpec signingKey = new SecretKeySpec(secretkeyByte, HMAC256);

                String base64Digest = null;

                byte[] dataBytes = data.getBytes();

                try {

                        // Load and initialize algorithm using signing key

                        Mac mac = Mac.getInstance(HMAC256);


                        // Generate the HMAC using input data bytes

                        byte[] rawHmac = mac.doFinal(dataBytes);

                        // Convert raw HMAC into Base64 HMAC

                        byte[] hash = Base64.encodeBase64(rawHmac);

                        base64Digest = new String(hash);

                } catch (NoSuchAlgorithmException e) {

                } catch (InvalidKeyException e) {



                return base64Digest;





SOAP is a protocol.

REST is an architectural style.

SOAP stands for Simple Object Access Protocol.

REST stands for REpresentational State Transfer.

SOAP can't use REST because it is a protocol.

REST can use SOAP web services because it is a concept and can use any protocol like HTTP, SOAP.

SOAP uses services interfaces to expose the business logic.

REST uses URI to expose business logic.

JAX-WS is the java API for SOAP web services.

JAX-RS is the java API for RESTful web services.

SOAP defines standards to be strictly followed.

REST does not define too much standards like SOAP.

SOAP requires more bandwidth and resource than REST.

REST requires less bandwidth and resource than SOAP.

SOAP defines its own security.

RESTful web services inherits security measures from the underlying transport.

SOAP permits XML data format only.

REST permits different data format such as Plain text, HTML, XML, JSON etc.

SOAP is less preferred.

More preferred than SOAP.

Representational State Transfer

Representational State Transfer (REST) is a software architecture style for building scalable web services. REST gives a coordinated set of constraints to the design of components in a distributed hypermedia system that can lead to a more performant and maintainable architecture.

REST stands for Representational State Transfer. (It is sometimes spelled "ReST".) It relies on a stateless, client-server, cacheable communications protocol -- and in virtually all cases, the HTTP protocol is used.

REST is an architecture style for designing networked applications. The idea is that, rather than using complex mechanisms such as CORBA, RPC or SOAP to connect between machines, simple HTTP is used to make calls between machines.

REST is a lightweight alternative to mechanisms like RPC (Remote Procedure Calls) and Web Services (SOAP, WSDL, et al.).

RESTful programming is about:

1.Resources being identified by a persistent identifier: URIs are the found everywhere/ubiquitous choice of identifier these days.

2.Resources being manipulated using a common set of verbs: HTTP methods are the commonly seen case - the venerable Create, Retrieve, Update, Delete becomes POST, GET, PUT, and DELETE.

3.The actual representation retrieved for a resource is dependent on the request and not the identifier: use HTTP Accept headers to control whether you want XML, HTTP, or even a Java Object representing the resource.

4.Maintaining the state in the object and representing the state in the representation.

5.Representing the relationships between resources in the representation of the resource: the links between objects are embedded directly in the representation.

6.Resource representations describe how the representation can be used and under what circumstances it should be discarded/refetched in a consistent manner: usage of HTTP Cache-Control headers.

Understanding REST

Understanding REST
REST stands for Representational State Transfer.
It is stateless, client-server relationship, cacheable communications protocol and use HTTP protocol.

REST is an architecture style for designing networked applications.

It is useful over the complex mechanisms such as CORBA, RPC or SOAP to connect between machines because HTTP is used to make calls between machines.

World Wide Web itself, based on HTTP, can be viewed as a REST-based architecture.

REST is a lightweight alternative to mechanisms like RPC (Remote Procedure Calls) and Web Services (SOAP, WSDL etc.).

Principles of REST
Resources expose easily understood directory structure URIs.
Representations transfer JSON or XML to represent data objects and attributes.
Messages use HTTP methods explicitly (for example, GET, POST, PUT, and DELETE).
Stateless interactions store no client context on the server between requests. State dependencies limit and restrict scalability. The client holds session state.

HTTP methods
Use HTTP methods to map CRUD (create, retrieve, update, delete) operations to HTTP requests.

Retrieve information.
Retrieve an address with an ID of 1:
GET /addresses/1

Request that the resource at the URI do something with the provided entity.
Often POST is used to create a new entity, but it can also be used to update an entity.
Create a new address:
POST /addresses

Store an entity at a URI.
PUT can create a new entity or update an existing one.

A PUT request is idempotent. Idempotency is the main difference between the expectations of PUT versus a POST request.

Modify the address with an ID of 1:
PUT /addresses/1

Request that a resource be removed.
Delete an address with an ID of 1:
DELETE /addresses/1

HTTP status codes
Status codes indicate the result of the HTTP request.
1XX – informational
2XX – success
3XX – redirection
4XX - client error
5XX - server error

Media types
The Accept and Content-Type HTTP headers can be used to describe the content being sent or requested within an HTTP request.
JSON response:
The client may set Accept to application/json if it is requesting a response in JSON.
XML response:
Set Content-Type to application/xml tells the client that the data being sent in the request is XML.
Related Posts Plugin for WordPress, Blogger...