SHA3

A new SHA3 algorithm is available for use with the Hash function. You can now use SHA3-256 (SHA3 with 256-bit digest) and SHA3-512 (SHA3 with a 512 bit digest) from the Crypto.HashAlgorithms enumeration for stronger encryption or compatibility with something else that uses them.

Var hash As String
hash = Crypto.Hash("YourPasswordSentence", Crypto.HashAlgorithms.SHA3_512)

BlowFish / TwoFish

The BlowFish and TwoFish encryption algorithms can now be used in Xojo. These two algorithms are similar, with BlowFish being the original algorithm and TwoFish being a newer, more secure version that was derived from BlowFish.

You can use them in Xojo with the Crypto.BlowFishEncrypt, Crypto.BlowFishDecrypt, Crypto.TwoFishEncrypt and Crypto.TwoFishDecrypt methods.

You can use either to encrypt data, but in general you’ll want to avoid BlowFish for your own code, although it might prove useful for compatibility with other libraries or tools.

AES

AES (Advanced Encryption Standard) is also used to encrypt data. You can do this using the Crypto.AESEncrypt and Crypto.AESDecrypt methods. Here is a quick sample:

Var encrypted As MemoryBlock

Var dataToEncrypt As MemoryBlock = "Secret!"
Var key As MemoryBlock = Crypto.GenerateRandomBytes(16)
Var initVector As MemoryBlock = Crypto.GenerateRandomBytes(16)
encrypted = Crypto.AESEncrypt(key, dataToEncrypt, Crypto.BlockModes.CBC, initVector)

Var decrypted As MemoryBlock
decrypted = Crypto.AESDecrypt(key, encrypted, Crypto.BlockModes.CBC, initVector)
// decrypted = "Secret!"

CRC-32

CRC32 is just a simple way to test data integrity and is not cryptographically secure. It still has its uses for fast data comparison and simple hash tables. It can be called like this:

Var crc32 As String
crc32 = Crypto.Hash("StringOrDataToTest", Crypto.HashAlgorithms.CRC32)

RSASign

RSASign now takes an optional parameter and RSASignModes let you specify the hash to use.

Learn more about the Crypto module in the Xojo Documentation.

Updated (Nov 22, 2021): Added AES section

Systems like Apple’s iMessage (their text messaging service) use encryption ensuring that all messages sent between Apple devices via iMessage are encrypted with keys that Apple does not have. They keys are on your device. Law enforcement agencies want Apple and others to provide a means of decrypting those messages without having to obtain the device itself. The problem is that if the government and Apple can get in, others will inevitably find a way to exploit that same back door too, making us and our data less safe and secure.

What some governments have failed to understand is that the bad guys can bypass any back door by using their own encryption. The smart bad guys probably assume that these back doors exist now (or at least aren’t taking any chances) and are already using their own encryption for their communications. How hard is it to write software to encrypt and decrypt messages? Do bad guys have access to programmers smart enough to do this? Yes, they almost certainly do.

Let’s take a look at what is involved in using Xojo to write an app that encrypts and decrypts messages. First, two keys need to be generated, a public key and a private one. The public key allows anyone to encrypt a message that only the holder of the matching private key can decrypt. Public keys can only encrypt. They are no good for decrypting messages. This means you can give anyone your public key which they can then use to send encrypted messages to you that no one else but you can decrypt.

Dim privateKey As String
Dim publicKey As String
If Crypto.RSAGenerateKeyPair(KeySize, privateKey, publicKey) Then
 PrivKey.Text = privateKey
 PubKey.Text = publickey
 SaveNewKeys(privateKey, publicKey)
Else
 Beep
 MsgBox "An error has occured. Keys could not be generated."
End If

This is just 10 lines of code and it could be further reduced. I wrote this to make it easier to read. The important function is RSAGenerateKeyPair on the third line. Next, you need to be able to encrypt a message using someone else’s public key. Let’s take a look at the code to do that:

Dim publicKey As String = RecipientsPublicKey.Text
Dim msg As MemoryBlock = OriginalMessage.Text
try
 Dim encryptedData As MemoryBlock = Crypto.RSAEncrypt(msg, publicKey)
 beep
 If encryptedData = Nil Then
  MsgBox("Encryption failed.")
 else
  Dim c As New Clipboard
  c.Text = Encodebase64(encryptedData)
  c.close
  MsgBox("Your encrypted message has been copied to the clipboard.")
 End If
Catch rte As RuntimeException
 If rte IsA CryptoException Then
  Beep
  MsgBox "Encryption failed because the Public key provided is not valid."
 Else
  Raise rte
 End If
End Try

This is 21 lines of code, most of which is handling errors. The one line that is really doing the work is the fourth one that contains RSAEncrypt. Next we need to be be able to decrypt. Here’s what that code looks like:

Dim privateKey As String = privKey.Text
try
 Dim decryptedData As MemoryBlock = Crypto.RSADecrypt(DecodeBase64(EncryptedMessage.Text), privateKey)
 Decryptedmessage.Text = DefineEncoding(decryptedData.StringValue(0, decryptedData.size), Encodings.UTF8)
Catch rte As RuntimeException
 If rte IsA CryptoException Then
 Beep
 MsgBox "The message could not be decrypted because the incorrect key was provided."
 Else
 Raise rte
 End If
End Try

This is 12 lines of code and like the other code examples, is mostly error checking. The important line is the third one that calls RSADecrypt. There is some additional code to save the keys to a text file and load them back in automatically when the app is launched. However, even adding in all that code gets you to only about 80 lines total. In other words, this is not a big app and not beyond the ability of someone with intermediate programming skills or even perhaps a very dedicated novice. (To learn about this in more depth, read Using Public/Private Key Encryption in Xojo).

If you’d like to try out encrypting messages with the app from which the code above originated, you can download CryptoMessage for macOS, CryptoMessage for Windows or CryptoMessage for Linux. Have a friend do it as well and you can send encrypted messages back and forth. If you’re more adventurous and would like to try playing around with the source code itself, make sure you have Xojo installed (which can be downloaded and used for free) then download the CryptoMessage Xojo Project.

Xojo has a crypto library (the part that provides key generation, encryption and decryption) built-in to it. However, if a programmer wasn’t using Xojo, they could easily find a crypto library on the Internet to use. In other words, building your own app to encrypt and decrypt messages is not very challenging. As I mentioned earlier, the bad guys (at least the smart ones) are likely already doing this as they are probably sufficiently paranoid that despite public announcements to the contrary, the back doors already exist.

The assumption that compromising our security enables catching more bad guys is a flawed one that I have written about before. It won’t work and we will all suffer needlessly. Imagine not being able to carry on a private conversation via your smartphone. That would make your device feel a lot less useful. Some governments have “experts” that have suggested it would be possible to have a back door Law Enforcement could use but could not be compromised by anyone else. That is a logical impossibility. Governments do not possess magic powers. They are made of up people like you and me. That is wishful thinking at best and negligent at worse.

When your government starts making noises about doing this, I advise you to make it clear to them that for the reasons I have stated in this post, such a compromising security is all downside with no upside at all.

All the methods related to cryptography and data ciphering are available under the Crypto module of Xojo, using behind the scene the Crypto++ 5.6.3 library. From the practical side, this allows us to use the RSA public key ciphering and other algorithms to compute unique footprints for given data, as for example Hash, MD5 or SHA. Paul blogged about using Public/Private Key Encryption in Xojo back when we added RSA encryption functions in 2014.

Among the methods related to RSA, we can find the ones to create the Private/Public keys, test the integrity of the public key, signing the given data and, of course, check the integrity of the signature, and ciphering / deciphering the given group of data.

As you probably already know, when we work with RSA we have to keep the Private key in a safe place, using the Public one to give to other people/service/app to whom we want to share information with in a safe manner. This way the users and/or apps and services will be able to use our public key to cipher the data that they want to share with us, and we will be able to use our private key to decipher that group of data so it is legible again.

RSA: Creating and interchanging the keys

Generating the pair of keys could not be more easy in Xojo, with this snippet of code:

Dim publicKey As String
Dim privateKey As String
If Crypto.RSAGenerateKeyPair( 1024, privateKey, publicKey ) Then msgBox “Successfully generated Keys!"

As you can see, the RSAGenerateKeyPair method receives the Integer number that indicates the strength (robustness) of the generated keys, followed by the String variables containing the generated Private and Public keys, passed by reference.

But in some cases it is possible that you want to use these keys beyond the scope of Xojo, for example when integrating your app with a service or solution developed in PHP. In these cases you have to consider that the keys generated with Xojo are in hexadecimal format.

What does this mean? Well, a public key generated with Xojo will look like this chunk of data:

30819D300D06092A864886F70D010101050003818B0030818702818100B4B531D3402C250D8640E739601F01FBE8ABB39635BE1778A7F4E55C49419C0595EF5A5824EA8E7A1871FB63B8960EDBB97B08C2E7EA43229903AEBCB45B9FD9E24780B15BCADB5E026849592CC1FA9B399EBD8457CC4E7A686CF53E9146E1D867ACEB675728E8821DEDA4C2F807FD668A81601F551484C5D1334B62D5E90E33020111

While other external libraries (as is the case in most of the web development frameworks), expect other data format codified as Base64. This is, something like this:

-----BEGIN PUBLIC KEY-----

MIGHAoGBALS1MdNALCUNhkDnOWAfAfvoq7OWNb4XeKf05VxJQZwFle9aWCTqjnoYcftjuJYO27l7
CMLn6kMimQOuvLRbn9niR4CxW8rbXgJoSVkswfqbOZ69hFfMTnpobPU+kUbh2Ges62dXKOiCHe2k
wvgH/WaKgWAfVRSExdEzS2LV6Q4zAgER

-----END PUBLIC KEY-----

So the first step to encode our Xojo keys (Public or Private ones) as Base64 is converting them previously from his hexadecimal form to the DER encoding (Distinguished Encoding Rules). Here is where we have to employ the DEREncodePrivateKey and DEREncodePublicKey methods if we want to encode the Private or the Public key, respectively. Once we have done this, we will be able to encode the resulting chunk of data as Base64 without forgetting to add the header “—–BEGIN PUBLIC KEY—–“ and the footer “—–END PUBLIC KEY—–“ with the accompanying ends of lines, or maybe the header “—–BEGIN CERTIFICATE—–” and the footer “—–END CERTIFICATE—–“ if we are dealing with a Public Key (for the Private keys we have to use the header “—–BEGIN RSA PRIVATE KEY—–” and the footer “—–END RSA PRIVATE KEY—–“).

You can interchange and use the Private and Public keys generated with Xojo using the PHPSecLib library.

In addition, as pointed by Thom McGrath, you can use also these keys with OpenSSL this way:

if (@openssl_public_encrypt($data, $result, $public_key, OPENSSL_PKCS1_OAEP_PADDING)) {
         return $result;
 } else {
         throw new \Exception('Unable to encrypt');
 }

Xojo’s Crypto library will be able to use a private key to decrypt $result in this case.

Finally, if you are interested in the cryptography topic, let me recommend you some good books: Applied Cryptography and Cryptography Engineering.

Javier Rodri­guez has been the Xojo Spanish Evangelist since 2008, he’s also a Developer, Consultant and Trainer who has be using Xojo since 1998. He manages AprendeXojo.com and is the developer behind the GuancheMOS plug-in for Xojo Developers and the Snippery app, among others.

The answer is yes. There are plenty of options that don’t require a global back door. I’m not passing judgment on whether these are inherently good or bad options, just that they are available when there is a reason to track a Bad Guy.

Keyloggers
A keylogger is used to track everything someone types. They come in both software and hardware varieties. Once installed, they can provide regular data about passwords and other communications the Bad Guy is making. Some store the data for later retrieval, while others broadcast it on a regular basis. They exist in varieties for both computers and cell phones.

Online Man in the Middle
With proper authorization, the Good Guys can stand between the Bad Guys and common online services they might be using. Working with their internet provider, they can gather data similar to keyloggers by intercepting and relaying data back and forth.

Digital Evidence Collection
When a warrant is served and computers or mobile devices are retrieved for analysis, gathering evidence quickly is paramount. The Bad Guys may have countermeasures installed on their devices, so being able to copy data from hard drives and other storage mediums across platforms while they are still online is important. Once images of the data are created, the evidence can be safely analyzed without being concerned about time bombs or other countermeasures. Xojo has been used to create tools that are used for both digital evidence collection and analysis. Being a cross platform tool is a particular advantage in this scenario.

None of the above options require a global back door, and they can all be limited to just the Bad Guys in question when surveillance is warranted. A recently released Harvard study has similar findings. Some options are better than others depending on the region in the world and the technical prowess of the Bad Guys. Smartphone Encryption is a Red Herring, but the Good Guys have other options. We don’t need universal back doors.

Today, terrorists are using encryption to hide their communications just like the Nazis did in WWII. What makes encryption different today is that it is also being used by millions of ordinary people, many of whom have no idea they are even using it. Almost every smartphone in use today, encrypts text messages and other data automatically. This is all done behind the scenes without the user ever being aware of it.

The type of encryption used on the iPhone and Android is called AES and it’s formidable. Intercepting your text messages isn’t actually difficult but decrypting those messages is, at best, impractical. To decrypt a message, just like with the Enigma machine, you need to know the key that was used to encrypt it. If you don’t have that key, you’d have to guess at what the key might be then look at the results of decrypting the message with that key to see if you have anything but unintelligible gibberish. Even with access to the fastest computers in the world, it could literally take years to guess the right key. It will come as no surprise that governments at almost every level don’t like this one bit. At their most transparent, they are used to getting a search warrant and being able to look at whatever you’ve got to see if it supports their suspicion that you are in fact up to no good. At their least, they wish to get on your phone (ideally from a secure, remote location) and take your data without a warrant or you having any idea they were ever there. The problem for governments is that they can’t. In Apple’s case, even if Apple was willing to compile with a request that they decrypt the data on your phone, they can’t. The key is stored on your phone in a way that even Apple can’t get to it. In this sense, Apple is in complete alignment with you in terms of your privacy.

There are lawmakers here in the United States that want to force companies like Apple and Google to provide a back door. This would be a way for Apple to get into your data should a search warrant (presumably) be issued. Apple’s CEO Tim Cook as pointed out what a bad idea this is. Back doors don’t get used by just the good guys. They will get used by the bad guys as well. In an effort to make it possible for law enforcement to get at the data of the tiny percentage of the population that is doing wrong, we would be opening everyone up to being hacked remotely. It’s not possible to make a back door that only the good guys can use. Think about your contacts, text messages, email, photos, all being exposed. Just the increased level of extortion alone would be so bad that your smartphone would go back to being useful as nothing more than a phone. Do any of you really want to go back to the 1980s?

What is worse than that, however, is what is not being talked about in the news. Smartphone encryption is a red herring. A back door wouldn’t solve the problem. Bad guys would simply write their own apps to encrypt the data themselves before they send it. This is incredibly easy to do. Xojo, the development tool my company created, has this same type of AES encryption built-in. Many other development tools have it as well. I could write an app to encrypt a message in a few minutes. Even if you have never written a line of code in your life, after a few hours learning Xojo, you could write the same app yourself. If you or I can do it, the bad guys can too. The smartest of them are almost certainly already doing this today. The end result would be that every law-abiding citizen’s personal and private data would become hackable- causing a digital tsunami of cybercrime that would be impossible for law enforcement to stop while achieving next to nothing towards actual security.

I understand why our lawmakers and law enforcement are concerned about encryption. It is a barrier to evidence for them. Tim Cook has argued that we have to balance law enforcement with our personal privacy. That’s certainly true. However, in this case, you don’t even have to go that far. What our elected officials are proposing will not work and will only create an exponentially greater problem. You may be asking yourself, “Surely they have thought of this, right?” Clearly they haven’t. Too often people make decisions without complete information or having taken sufficient time to to think the matter through. We have all seen this many times in our lives. Smartphone encryption is just the latest example. It’s not the first and won’t be the last. I’m all for looking for better ways to catch the bad guys but smartphone back doors will not work. Your elected officials are wasting your precious taxpayer dollars. If you want to stop this, contact them and ask them to better educate themselves on this topic. You can point them to this blog post to start. I can’t speak for countries outside the United States, but here elected officials give considerable weight to their constituents that reach out to them. You can contact your Representatives in the House here and your Senators here.

Lastly, while I am proud of Tim Cook for fighting back on this issue, it saddens me that he appears alone on the world stage while doing this. Powerful people in technology such as Mark Zukerberg of Facebook, Larry Page and Sergey Brin of Google, Satya Nadella of Microsoft and others should be taking an equal stand. They are in an even better position than we are as individuals to make it clear that the proposed solution won’t work. Until then, contact your elected officials and tell them that dog won’t hunt.