I’m fascinated by ciphers. There is a great book on code breaking by Simon Singh called The Code Book: The Science of Secrecy from Ancient Egypt to Quantum Cryptography. The book is full of different encoding methods people have used throughout the ages to hide their secret messages. This book was the inspiration for an application I had in mind to make – something that would allow you to choose an encoding method from a large range of methods, and encode a message so that another person receiving the message could decode it (with the right key). I even had a name for this application: “Decoder Ring” – based on the simple circular substitution ciphers that were put in to circular rings in the early 1900s, mainly for kids to write secret messages to one another.
My business partner Elroy – a brilliant graphic artist, amongst other skills – and I had been looking for a new project to do together. I approached Elroy with the idea and suggested he could start to think about the graphical design of this application, and I would start to build it. Elroy and I discussed the interface, and some of the functionality of the application, but we were also busy with many other things, so we didn’t really start to progress until almost a year after our initial discussions.
Goals
Development would be for the iPhone, in Objective-C. I had been using Objective-C for many years writing Mac applications, so Objective-C was not new to me. Also, Elroy and I had been working on an iPhone chess application for some time (which never saw the light of day), so iPhone development wasn’t new to us. We’d also collaborated on a fun little iPhone application called “upside down” that was already in the App Store.
Development began. For those who understand the basics of Objective-C, I initially started by creating an Objective-C category on NSString – something that would extend NSString to allow you to encode and decode strings using a password and encryption method. The first method to tackle I decided was the Vigenère cipher – a fun and clever cipher from the 1500s. I wrote the code for this quite quickly, and the basic application came together within a few days. It had only one method of encoding, and no graphics or icon. You typed a message. You pressed Encode. You typed a password. You saw the encoded message on screen. You sent it via email or SMS.
Testing
As I started to work on other encryption methods, a number of problems were revealed. When demoing the raw software to friends, it became apparent that most people weren’t interested in all the different types of encryption methods throughout history. All they wanted was to send a secret message to someone else. They didn’t want to know the details – only that the message was secure. Though I thought the idea of multiple methods was very cool, apparently only geeks who love ciphers had any interest. So we had to rethink.
Research
The Vigenère cipher was not particularly secure, but wasn’t too bad as far as simple encoding methods go. But it had a major flaw – it worked only with the roman alphabet. One of the things I realised was that typing in Japanese didn’t work with it. Nor did Emoji you could enter on your iPhone. This was very much something that only worked for the English alphabet. And it didn’t work for numbers either. Suddenly this method didn’t seem like a great choice.
That wasn’t going to cut it. Elroy and I had decided we wanted to not only make a great, simple app, that was beautiful and functional, but we wanted it to work in non-English languages, and initially have a large selection of languages for the interface itself. We live in Melbourne, Australia, and this is a multicultural society. We have friends from all over the world who would help us internationalise our app.
People say that the way to produce successful applications on the iPhone is to start with something simple, and “polish the crap out of it”. And that is what we decided to do.
I went back to the drawing board and looked at encryption methods. Rather than use something old, I decided to use something new. I went for the Advanced Encryption Standard – a symmetric-key encryption standard adopted by the U.S. government, with a 128 bit key. This would encrypt the message more securely, and would work with any text, not just English. It was fast, and worked perfectly for our needs.
Testing
As the early research had shown the majority of users didn’t want to mess about choosing methods of encoding, which meant that the focus of the app shifted from being about the encoding, to being more about getting messages securely to friends. With this shift we began to feel that the ‘decoder ring’ name felt less appropriate, so Elroy began working on UI designs that we’re more indicative of ‘security’ or ‘safety.’ Stripping out any notion of multiple encoding methods also meant that the UI requirements were greatly simplified.
User Interface
So, Elroy began work on the look and feel of the application. He mocked up images and sent them to me, I gave feedback, and we went back and forth until we had a look we felt was perfect for the application. What we eventually settled on was the idea of using a padlock and metal textures in the UI, to represent strength and security. The paper print-out style text area maintained the old-school spy-tech feel we felt was appropriate. The decision was also made to make the UI as textless as possible, instead relying on (hopefully) intuitive icons for functions like delete, SMS, email, clipboard, etc. Elroy worked on the icons and graphics, and suggested methods to display the text.
Localization
By using Apple’s localisation methods, all strings in the application that are displayed to the user are placed in a file “Localizable.strings”. To localise for a different language, you basically take the file, and replace the text with the other language and tell Xcode what language the new text represents. The file ends up with code such as the following for Japanese:
/* Dialog buttons */
"OK" = "OK";
"Cancel" = "キャンセル";
/* Encode dialog */
"Encoding Key" = "暗号化パスワード";
"Enter key to encode message." = "パスワードを入力。";Within a short timeframe we had English, French, Japanese, Malay, Indonesian, Korean, Chinese, Spanish, Italian and Greek localizations. And the iPhone took care of displaying the correct text for the language of the user.
User Interface
Elroy wanted the text to not just change on screen when encrypted, but to animate in some way. We experimented with a couple of animations. One animation we tried was to have the paper ripped off the screen, and then a new encrypted message roll down the page. Though cool, this didn’t quite feel right, and in the end we went with the current animation, where the page is retracted, and then comes back down encrypted. The intention of this animation was to indicate to the user that the app was functioning prior to sending them to the phone’s SMS or email client, rather than simply kicking them out of the app without warning. We also added some simple sound effects (with the option to turn them off). We really polished the interface until it looked and felt great.
Testing
With all software, one of the areas that takes the most time (and is usually under-estimated) is testing. With ten languages, the application had to undergo thorough testing with a number of volunteers to ensure it worked as expected, and displayed text correctly. Minor tweaks were often made, and a new version sent out for testing. At the same time, we needed a name for the application. Everyone had a suggestion – “Decoder”, “Encoder”, “SecretKeeper”, “TalkSecret”, “Enkrypt”. We wanted something simple – a single word – and were amazed when I checked and discovered that the name “Secret” was still available for use in the iTunes App Store. We registered it with Apple quickly, to ensure no one else used it while we were finishing the graphics.
Release
Finally, we decided the software was ready for release.
Unfortunately, Apple didn’t think so. Well, actually it wasn’t Apple, it was the US government. You see, the encryption method we chose to use is not exportable according to the US government. They consider it too strong. That meant the software needed to change.
So, a last minute change was made to use the Data Encryption Standard with a 64 bit key. That was the limit that the US government would allow.
Now, some reading this may be thinking, why does it matter what the US government says? In Europe they don’t have this restriction, so why can’t the Europeans have the stronger encryption?
Well, the issue is that even if we deliver the software to Europeans, it is downloaded from Apple’s servers in the US. So what the US government says goes. We could have asked the US government for an exception, but that would have involved us sending all source code to the US government for inspection, and then waiting a potentially long time for a response. In the end it was easier to go with DES. And most people would say that was more than safe enough for the purposes of this application.
Learnings
That last minute change though actually created a bug that was patched some time later. That’s the trouble with last minute changes – testing hadn’t picked up the bug. But in the end this was fixed, and Secret has been available now since January 2011 with very positive feedback. Interestingly it has been extremely popular in Japan, which is an indication to other developers out there that taking the time to internationalise does have its rewards.
App: Secret
Jamie CurmiJamie is a Software Engineer and CTO of an Australian health care company. Over the years Jamie has worked in Academia, Artificial Intelligence, Telecommunications and the Health Care Industry. In his spare time he writes Mac and iPhone software for his own company Curmi.com, rarely updates his blog, and watches too much TV.
