Home > C++ > Hashing For Integrity

Hashing For Integrity

Introduction

Before I discovered the wild and wacky world of Bitcoin, I didn’t pay much attention to cryptography or system security. Those intertwined subject areas, though important, seemed boring to me. Plus, the field is loaded with all kinds of rich, complex, terminology and deep, bit-wise, computationally-intensive, mathematical computations:

Symmetric/Asymmetric key generation algorithms, secure key distribution, private/public key pairs, block and bitstream cipher algorithms: DES, 3DES, AES, Blowfish, encryption by substitution/translation, hashing algorithms for integrity: MD5, RSA, SHA1, SHA2, RIPEMD-160, digital signatures, message digests, confidentiality, authentication, non-repudiation.

But now that I’m a “Bitcoiner“, all these topics suddenly seem interesting to me. Thus, I decided to look for a C++ Crypto library and write some buggy, exploratory, code to learn what the hell is going on.

Out of the gate, I didn’t want to get bogged down or overwhelmed by interfacing directly with the bedrock openssl C library API which underpins most higher level Crypto libraries. I wanted an easier-to-use, abstraction-oriented wrapper library on top of it that would shield me from all of the low level details in openssl

I didn’t have to look far for a nice C++ Crypto library. Poco has a Crypto library. Poco is a well-known, highly polished, set of general purpose, open source libraries/frameworks that is widely deployed across the globe.

The next thing I needed to do was to narrow down the scope of the project. Instead of hacking together some big complicated application, I decided to learn how “hashing achieves message integrity“.

Hashing For Integrity

A hash is a one-way function. When a message, large or small, is sent through a hashing algorithm, the resulting output is NOT an encrypted message that can be decrypted further downstream. It’s a simple, fixed size (in terms of number of bits) value also known as a message “fingerprint“, or “digest“.

Let’s say “I owe you $100” and you want an acknowledgment from me of that fact. I could write it down on paper, sign the note, and give it to you. My signature conveys the fact that I authorized the IOU and it gives the message a degree of integrity.

If you received the note without my signature, I could deny the IOU and I could deny ever sending the note to you. I can even say that you made it up out of thin air to scam $100 from me.

By providing you with an electronic version of the “I owe you $100” note AND a fingerprint in the form of a hash value derived from the content of the note, you could at least verify that the note content is legit and hasn’t been tampered with.

You would do this verification by locally running the note content through the exact same hash function I did, and then comparing your hash value with the fingerprint/digest supplied directly with the note. If they match, then the note is legit. Otherwise, it means that the note was “altered” sometime after I generated the first hash value. Any little change, even a one bit mutation to the message, invalidates the fingerprint derived from the unaltered message. That’s the nature of hashing.

Using Poco::Crypto::SHA1Engine For Hashing

The class diagram in the figure below shows what I needed from the Poco.Crypto library in order to code up and simulate the behavior of a hashing system.

The Poco::Crypto:SHA1Engine class implements the SHA-1 message digest algorithm. (FIPS 180-1, see (http://www.itl.nist.gov/fipspubs/fip180-1.htm) ). Here’s a simple code usage example in which: an engine is created, a message is sent to it, and a hash value is returned:

The following console output from the code shows that the SH1Engine, in its default configuration, generates 160 bit hash values. The SH1Engine::digestToHex() converts the bit pattern into 40, 4bit, nibbles and returns a human-readable hexidecimal string:

The PocoCryptoExample Project

Using the Eclipse CDT, I coded up the design in the class diagram from the previous section. The PocoCryptoExample source tree is available on GitHub here: https://github.com/bulldozer00/PocoCryptoExample. All you have to do is download the source tree, import it into Eclipse as “an existing Eclipse project“, and build the executable using the internal CDT builder (see README.md).

The test driver code that exercises the design (in MessageIntegrityTest.cpp) is as follows:

  1. Initializes the Poco Crypto library (which in turn initializes the openssl library).
  2. Creates the Sender, Recipient, and the I owe you $100” message.
  3. Invokes the Sender to compute the message fingerprint, set the message and fingerprint within a ChannelMessage, and transmit the result to the Recipient.
  4. Upon receipt of the transaction status (success/failure) back from the Recipient, the test driver prints the result to the console.

The test driver then:

  1. Commands the Sender to simulate a man-in-the-middle attack by maliciously changing the message content to You owe me $10,000” and sending a  new ChannelMessage to the Recipient without changing the fingerprint from the prior ChannelMessage.
  2. Upon receipt of the transaction status (success/failure), the test driver prints the result to the console.
  3. Uninitializes the Poco Crypto library (which in turn uninitializes the openssl library) and exits.

Here is the console output produced by the program:

What’s Next?

A next step in the learning process can be to integrate a Poco::Crypto::Cipher class into the design so that message encryption/decryption capability can be added. As you can see from the example code on the Poco Cipher API page, it’s not as easy as adding the SHA1Engine. It is more difficult to create/use a Cipher object because the class depends on the CipherFactory and CipherKey classes.

With those additions, we can simulate sending an encrypted and fingerprinted (integrity AND confidentiality) message to “matchedRecipients who have the same Poco.Crypto objects in their code. A Recipient would then use the SH1Engine to first check that the fingerprint belongs to the message. If the message passes that test, the recipient would then use the Cipher to decrypt the message content.

You know what would be great? If the ISO C++ standards committee added a <crypto> library to the C++ standard library to complement the impressive random number generation and probability distribution functionality available in <random>.

Categories: C++ Tags: ,
  1. May 3, 2017 at 8:00 am

    Thanks, Tony, good article.

    • May 3, 2017 at 8:04 am

      You’re welcome Mark. I’ve been chomping at the bit to write a “substantially valuable” C++ post for quite awhile now. I may have pulled it off?

  2. May 3, 2017 at 12:02 pm

    Nice post. I’ve already suggested time ago in the cpplang Slack about but nobody was interested into it and the reply was: “we need cryptographers to verify the validity of the code and it is difficult to standardize it”.

    Not all the OSes/platforma come with a crypto engine capability, but it would be a big game changer IMHO

    • May 3, 2017 at 12:13 pm

      Thanks! That’s a great point about needing cryptographers to verify/validate. Unlike Poco and bitcoin and openssl, which are open source and therefore easily “inspectable”, I don’t know how anyone would be able to verify each std library implementation?

      • Michele
        May 3, 2017 at 3:23 pm

        as long as it could be standardized (an IEEE one), I guess it would be of wide interested, because C++ is one of the best languages out there for general purpose development.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: