Oscar Sanderson

I’ve illustrated before just how easy it is to read QR Codes from an iPhone application using the ZBarSDK (original blog post), but if you’ve ever wondered how to generate a QR Code on-the-fly from within an iPhone application then look no further as this post demonstrates how the open source ‘libqrencode‘ C library can be easily integrated and used with minimal additional effort.

I’m not going to cover all of the minor steps in detail such as creating an Xcode project and hooking in a view controller, but a link to the sample Xcode project is included at the end of this post for anyone who wants to quickly give it a try.

[Step 1] Create a new Xcode project and hook in a view controller

Simply create an ‘Empty Application’ project and then hook a view controller in to the AppDelegate so that a view is shown when the app is launched.

[Step 2] Add ‘libqrencode’ source to the project

After downloading a copy of the ‘libqrencode’ C library from the official site it’s simply a matter of adding the enclosed source files (c/h) to your newly created Xcode project.

If you try compiling the app at this point you’ll get a few compilation errors that can be easily resolved with the following steps:

• Remove the ‘qrenc.c’ file from the project, as this has dependencies on other libraries
• Update ‘config.h’ to include values for the version related constants (i.e. MAJOR_VERSION, MICRO_VERISON, MINOR_VERSION, VERSION)

It’s worth highlighting at this point that the ‘libqrencode’ library does the hard work of converting the data into a QR Code representation, but it stops short of actually generating the final QR Code image, as this step is largely platform specific and would impose external library dependencies which may not always be desirable or necessary, as such the next step explains how the output of the ‘libqrencode’ library can be used to generate the actual QR Code image.

[Step 3] Implement a wrapper method that generates a QR Code image using the ‘libqrencode’ library

I chose to use an Objective-C Category to extend the UIImage class, but there are many different ways this wrapper could be implemented.

My method simply calls the ‘libqrencode’ library and then uses Core Graphics to convert the output to a UIImage that can be easily used within the iPhone application.

The caller can customise the generated QR Code as follows:

• iData: UTF8 string of the data to be encoded within the QR Code
• iLightColour: Colour to be used for the ‘light’ pixels (normally ‘white’)
• iDarkColour: Colour to be used for the ‘dark’ pixels (normally ‘black’)
• iQuietZone: Size of the ‘quite zone’ border (1 works with modern scanners, although 4 is required as per the official specification)
• iSize: Target size of the resultant image. The image will generally be less than or equal to this value as the image is scaled using whole multiples (i.e. x1,x2,…,x6), however the resultant image can be larger than what is requested if the requested size is too small to accommodate the QR Code

[Step 4] Hook the wrapper method into the view controller

In my example I created the view controller programatically, so it’s simply a case of adding the following code to the ‘viewDidLoad’ method.

[Step 5] Compile and run the application

The code shown in the previous step will produce the following output when the application is run:

Xcode sample project download

The sample Xcode project can be downloaded here and includes all necessary source code, including the tweaked ‘libqrencode’ C library source.

Presentation from the ‘Customer Loyalty Conference & Expo’

28th September 2012 (Manila, Philippines)

QR Codes are becoming increasingly popular but few people realize just how easy it is to support this technology from an iPhone application.

In this example, I’ll illustrate how to knock together a simple QR Code reader using the open source ZBarSDK. It’s not going to be an ‘All singing, all dancing’ application, but it will be sufficient to illustrate the point.

The following example assumes that you’re already familiar with both XCode and iPhone development.

Step 1: Create a Window-based iPhone application and name it ‘QRReader’

Step 2: Download ZBarSDK

Step 3: Run the ZBarSDK installer and follow the simple instructions for adding the SDK to your XCode project

Step 4: Add the following frameworks to your project:

• QuartzCore.framework
• AVFoundation.framework
• libiconv.dylib
• CoreVideo.framework
• CoreMedia.framework
• AudioToolbox.framework

Step 5: Add the main view to the Application Delegate, as follows:

At this point ZBarSDK is already integrated with the video feed from the camera, but we still need to implement the delegate so that the SDK can notify us when it has managed to detect a QR Code.

The following delegate method should now be added to the Application Delegate:

Step 6: Next we need to create a new UIViewController subclass and call it ‘QRCodeDetail’. This will be used to show the details of the QR Code once it has been read by the main view.

Update the header file to contain the following:

Remember to synthesize the variables:

Finally we update the ‘viewDidLoad’ method:

Step 7: Hook the QRCodeDetail view into the main view

Back in the Application Delegate we need to import our newly created view:

Then we need to update the ‘didFinishPickingMediaWithInfo’ method to load the ‘QRCodeDetail’ view whenever a QR Code is detected:

Step 8: Simply install on an iPhone and enjoy the QR Code Reader.

You can easily generate your own QR Codes here.

It may have taken a while but ‘9×9 Killer Sudoku’ games have finally been added to Mister Sudoku.

A total of 451 games were added to the FaceBook and iPhone (v1.2.1) versions of Mister Sudoku earlier this year (March-April).

Almost 12,000 of these games have been played with a total playing time in excess of 200 days.

The average playing time is just over 26 minutes per game and the maximum recorded duration of a single game is 30 hours, which certainly shows a level of determination on the part of the player!

Several years ago when PCI was first being discussed many people within the payments industry were arguing the merits of using Cryptographic Hashes compared to traditional Symmetric Key Encryption.

The most obvious of these benefits seemed to be that the use of Cryptographic Hash algorithms fundamentally addressed the age-old challenge of implementing a robust key management policy, furthermore as these Cryptographic Hash algorithms are One-Way functions they have the added advantage of being totally secure… or do they?

What follows is a simple explanation as to why hashes can collide, and why our inherent need for ‘quick answers’ has tricked us into believing otherwise.

Other topics such as why using hashing on a relatively small data set such as PANs opens the door to brute force attacks, why a ‘salt’ should be protected in a similar fashion to a ‘symmetric key’, will be saved for a another day.

The difference between ‘Intentional’ and ‘Accidental’ Collisions

The web is full of research findings detailing just how difficult it would be to ‘intentionally’ create a hash collision for a modern Cryptographic Hash algorithm such as SHA-256.

A casual Google search using a phrase such as ‘SHA2 collision probability’ will return a multitude of results all explaining how difficult it is to ‘intentionally’ manufacture a collision but few if any that actually explain why collisions can occur by ‘accident’.

This is clearly reassuring as one of the main requirements of any Cryptographic Hash Algorithm is that it must be ‘infeasible for a potential attacker to find two messages with the same hash’.

But this is where our inherent need for ‘quick answers’ gets the better of us. We do a quick search, glance at the results, seeing what we expect or want to see, without taking the time to properly understand and digest the information that is presented to us.

Remember, the focus here is not on the ability of an attacker to ‘intentionally’ find a collision, but moreover the possibility of a collision ‘accidentally’ occurring.

If we were using a Hash Algorithm for the traditional purpose of creating a hash of a document then the security would revolve around the infeasibility of an attacker being able to engineer an ‘intentional’ collision, as we’re using the hash to prevent any tampering of the document contents.

However, in the context of ‘PAN Hashing’ the underlying intention is to render the PAN unreadable without incurring the overheads associated with symmetric key management. As such, the occurrence of collisions would prevent us from being able to prove with absolute certainty that a given ‘hash’ was the result of a given ‘PAN’, something that we would always be able to prove if we encrypted the PAN using a Symmetric algorithm (i.e. AES).

Why One-Way algorithms are designed to Collide

The real irony when discussing hash collisions lies in what is perceived to be one of the biggest strengths of Cryptographic Hash algorithms, the fact that they are One-Way irreversible algorithms.

Did you ever take the time to contemplate how these algorithms ensure that they are One-Way?

We don’t need to delve into any advanced mathematics here, as a simple example will suffice. Let’s consider the following One-Way function:

C = (A + B) MOD 10

The function is One-Way / Irreversible because simply by knowing A and C it is not possible to deduce B, and likewise by knowing B and C it is not possible to deduce A, as illustrated by the following examples:

A=5, C=9 –> B=4,14,24,34, …

B=2, C=1 –> A=9,19,29,39, …

The reason that the function is One-Way / Irreversible is quite simple… it produces ‘collisions’!

If you take a look at standard Cryptographic Hash Algorithms such as the SHA family of hashes, you’ll see the same technique (i.e. Addition modulo 2ⁿ) being used to ensure that the algorithm is One-Way / Irreversible.

Conclusion

Hopefully by this point you’re convinced that Cryptographic Hash Algorithms such as the SHA family do collide and that this is an intended and fundamental part of their design.

Whilst the likelihood of two or more valid PANs colliding and resulting in the same hash is probably extremely low, the point remains that it could theoretically happen.

Before using a Cryptographic Hash algorithm as a means of providing ‘pseudo encryption’ of PANs, it is important to first understand the fundamental properties of the algorithm and what it was originally intended for.

‘Mister Sudoku’ is now available for both the iPhone and Facebook.

The latest version (v1.0.1) of the iPhone application can be downloaded from the AppStore by clicking on the attached screenshot.

The Facebook version can be accessed directly from your Web Browser by simply adding the ‘Mister Sudoku’ application from within Facebook.

Mister Sudoku gives you access to a multitude of Sudoku game types including the popular Jigsaw and Killer variants. With varying levels of difficulty and sizes there are games for everyone and every occasion.

One of the distinctive features of Mister Sudoku is that you can seamlessly switch between Facebook and the iPhone whilst maintaining a single consolidated scoreboard. All that is required is to enable ‘Facebook Connect’ from within the iPhone application and all your scores will be automatically synchronized with Facebook.

The latest version includes a pack/unpack benchmarking module, along with sample MSVC 6.0 project files. The benchmark test is the same as the one published by jPOS.

The benchmarks were run on a Dell Inspiron 6000 laptop (Intel Pentium M – 2.00GHz).

In ‘Static Memory’ mode it is possible to perform in excess of 130,000 pack/unpack operations per second, as shown by the following screenshot: 

 The throughput in ‘Dynamic Memory’ mode is lower but still manages just under 100,000 pack/unpack operations per second, as shown by the following screenshot:

See the ISO 8583 page for more details…

I’ve just released an updated version (v0.0.2) that includes a 1987 message handler… See the ISO 8583 page for more details…

It’s been almost two years since I wrote my ISO 8583 library and I’ve finally managed to get around to publishing it. Since its original conception back in 2005 I’ve made a few minor changes, mainly with regards to naming conventions and to facilitate the addition of different version handlers in the near future.

This version includes the ISO 8583:1993 (binary) message handler.

Check out the ISO 8583 page for further details…