Monday’s article, “Hacking Our Freedoms Away” resulted in a long email from one of my readers. The reader wrote that I was misleading you by making you believe that as the developer of Amitor® I cannot read the contents of the information my users store securely. The reader, who is obviously technically savvy, wrote that as the developer I have direct access to the database where the data is stored. As I was getting ready to respond to the writer, I figured I might as well turn my response into an explanation of how I cannot read the stored data even if I wanted to. This is also a quick primer on how data can be secured even from the technology people working in any organization.

The reader argued that I have direct access to the database where the data is stored. “You know as well as I that you can bypass any passwords you have used to secure the data and go directly to the source” the reader wrote. The reader was referring to the notion that I can open a session directly on my database and read the contents of each record. The reader assumed that my APP was storing the content in plain text.

The reader than added, “even if you encrypt it you still have the key to unlock the contents.” Again, another assumption by the reader. As many of you know, encryption is where you take a word, like “news” and jumble the letters up with algorithms to turn the word into this: “%hkDyg@-”.

There are many schemes, some more secure than others, that takes content and jumbles it up to make it unreadable to human eyes. They vary from simple letter substitutions to complex conversions of characters into jumbled code. Computers have made letter and word substitution more complex and as such the content becomes more secure.

What the reader had neglected to discover, by using my APP, is how the secure data is handled. Amitor® encrypts the contents by using a key substitution scheme. The APP takes the original plain text content, asks the user to create a key and then stores the jumbled characters into the database. So instead of me seeing: “This is my text in plain text”, I see this “©á è ™s™ } ñ§ºË+ €‰ÃÎ1~™ðÔr•û]дô«Î6ƒ» )4t”. I store my encrypted data in a binary format.

The second part of the reader’s comments was that even if I encrypted the data, I still have access to the passphrase or key to unlock the encrypted content. The reader I assumed that I stored the user’s key, or passphrase in the database. I do not.

Instead, when the user wants to store encrypted data he enters it into Amitor® and is then asked for a phrase to act as a password, or salt for those of you into encryption schemes. I do not store the key. That is the reason why I cannot decrypt a user’s encrypted content if the user forgets their passkey. It is also the reason why I cannot read my user’s secure content. By allowing the user to enter a key phrase, only that user has the key to decrypt the content. The longer, or more complex the key is, the harder it is to decrypt the message.

Some of you may be curious as to how this works so let give you a real world example.

The plain text phrase that I am going to encrypt is:

This is my text in plain text. Obviously you can and everyone else can read it. If I stored this in my database, then my reader would be correct in that I can read the content. However, what if I encrypt the text before I store it in the database?

Now, let me apply the following passphrase to the content:

This is my example from Amitor.

This is the result that is stored in the database.

©áè™s™}ñ§ºË+€‰ÃÎ1~™ðÔr•û]дô«¨×Î6ƒ»¨10ºv‰YÕ¸Ix±‰•á=Ìî׈G±Ï )4t6š–Šÿ`ئp£{Žš™‘½9Æ·ÓAˆ&El/ǧ²&Ë#þ¤ye®·-B·Ð<¯f”âí6¨ð+€aÔap .»)ûv!¥Ë*ʵtt2cʳ!QhŠ´˜Ò”:椀Êzœõ *Äl_æN#Å eq+Ÿ¼ýF0ù-—Z oŸ’$Ë nØΕV9šÔ¤Ô·gù<½æ¯¡ÛõóÌ”øX,&ès£Aý_[Ç—Ÿ%

As you can clearly see, no one, not even the original user who encrypted the message can read it. They would have to decrypt it first by typing in the key phrase they used to create the encrypted content.

Now, let us apply a different passphrase to the original plain-text content. For this example, let’s use:

El Paso News – blog no one reads

This is what we get from this passphrase:

ïÝײ¸2é„1Pø,Xøë13m‘l9Ræ‘|TFdŽŽ÷°I½>Žm¯Uß‹ºeõÙ¯‚¿lx/””¦ÂDt+‡â¥DðêŸàS•¢2Å¡4È z-ÎOºHÚúN;¥á°á9ÛÌãyb8°ç?g«Cèmá`±m.ûdS?5hÇz‚€ÀÃ4gŠˆ$–*gõ…ó>+E¯ÇG¿}™ñoÇÐô—Dö vJµ³/ ðÆÀ`»¬ôÝD ¯h<Õ#­ûÌŒÙ??_Œëp)VJ)=Á”Bðþyº.½+Ç̪/[Ú¯‰k²dŸ™6AGÖ’žTã˜m.

Clearly it is jumbled differently from the first one. If I tried to use the original passphrase to decrypt this second data set, the result would be just a jumbled mess. As you can see, unless I have the original key used to encrypt the content, I cannot read it. The only individual with the key to unlocking the code is the one that created it.

As I fully expect the reader to challenge me on whether the system is foolproof, let me share a detail about encryption. Anything that can be jumbled up with a mathematical formula can, theoretically, be unjumbled with math. The security is not in being foolproof but rather the amount of resources and time it would take to decrypt the content via brute force mathematical iterations against it.

For normal purposes it is would be near impossible to decrypt the content in a reasonable amount of time, and thus it is secure from normal prying eyes, including mine.