My answer was, of course, “Let me have a look and get back to you.”

I went to my favourite dev tool, Xojo, and went through the process of developing a solution. The connection is a REST API, so I’ll start with a web project and use the HandleURL event. And I’ll use a URLConnection to pass on the request.  Wait … could it be that simple?

Function HandleURL(request As WebRequest, response As WebResponse) Handles HandleURL as Boolean

  // Create the outbound connection
  Var connector As New URLConnection
 
  // Copy the content of the request
  connector.SetRequestContent(request.Body, request.MIMEType)

  // Send the request
  Var result As String
  Try
    result = connector.SendSync("POST", kAddress + request.Path)
  Catch err As RuntimeException
    // Catch DNS, Certificate & Timeout errors
    response.Status = 500
    response.Write(err.Message)
    Return True
  End

  // Return the result of the request
  response.Status = connector.HTTPStatusCode
  response.Write(result)

  Return True

End Function

The answer is, “Yes!”  This is all the code in the entire project.

You will notice that there is no security, but in this instance that is fine as the virtual machine is running this is on the same network as the client server and the firewall is configured to only allow connections from that server.

After processing over 60 thousand requests, memory use is 7.3MB and never exceeded 13MB. CPU usage was at the maximum 1.5%.

Even after using Xojo for 20 years this still blows my mind.

Wayne Golding has been a Xojo developer since 2005 and is a Xojo MVP. He operates the IT Company Axis Direct Ltd which primarily develops applications using Xojo that integrate with Xero www.xero.com. Wayne’s hobby is robotics where he uses Xojo to build applications for his Raspberry Pi, often implementing IoT for remote control.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Encrypting PDF files with PDFDocument is based in the use of the PDFPermissions class. You’ll need to create a new instance of the class passing along the “Owner” and “User” passwords. For example:

Var d As New PDFDocument
Var g As Graphics = d.Graphics

Var p As New PDFPermissions("OwnerPassword","UserPassword")

In addition, you can set other properties for the PDFPermissions instance; all of them are read/write and will be applied by the PDF viewer app for when the document is opened using the “user” password.

• AllowCopyingContents is set to False by default. When set to True it will allow copying contents from the PDF, as for example the selected text or image.
• AllowModifyingContents is set to False by default. When set to True it will all to modify the contents of the protected PDF document.
• AllowPrinting is se to False by default. When it is set to True it will be possible to print the PDF.

Once the PDFPermissions instance has been created and the desired properties had been set, all you need to do is to assign such instance to the Permissions property for the PDFDocument instance you want to encrypt:

d.Permissions = p

Then, when it’s saving the document to a file, PDFDocument will encrypt all the streams of data containing sensitive information, as it can be the text or Images rendered on every one of the PDF pages plus the metadata information itself. The used encryption algorithm is AES 128 bits.

That’s all! You can distinguish an encrypted PDF file from an unencrypted one because, usually, the first one will be displayed with the image of a Lock in the icon. When you open an encrypted PDF in the viewer app you’ll be asked to type a password. If you enter the passord set to the “Owner” user, you’ll be able to do all the kind of operations allowed by the viewer app, while if you enter the “User” password, then the kind of options available will be determined by those set using the PDFPermissions properties.

Javier Menendez is an engineer at Xojo and has been using Xojo since 1998. He lives in Castellón, Spain and hosts regular Xojo hangouts en español. Ask Javier questions on Twitter at @XojoES or on the Xojo Forum.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

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

Is it the most secure or robust encryption algorithm around? Not really. But it provides a good amount of performance and you can take further steps in order to correct some of its flaws. So, continue reading if you are interested in having this one in your developer toolset implemented as a Class with separate methods to encrypt and decrypt a block of information (even if it uses the same function in both cases).

Add a new Class to your project and name it ARC4. Next, add the three properties needed to implement it:

• Name: mBox
• Type: MemoryBlock
• Scope: Private

• Name: mKeyBlock
• Type: MemoryBlock
• Scope: Private

• Name: mKeyLength
• Type: Integer
• Scope: Private

ARC4 uses a main state box with a length of 256 bytes and the first one will be the one pointed by the mBox property. The second one, mKeyBlock, is declared as a MemoryBlock just to be more efficient in accessing the individual bytes of the provided Key. Lastly, the mKeyLength property is just a convenience property so we can access the original Key length from our Methods.

Now, let’s add the required Class methods, starting with the Constructor. This one will let the user provide the Key string as part of the instance initialization; so we don’t need to provide it again every time we want to encrypt or decrypt a new block of data.

With our ARC4 class selected in the Navigator, add a new method and type the following values in the Inspector Panel:

• Name: Constructor
• Parameters: Key As String
• Scope: Public

Next, type the following snippet of code in the associated Code Editor for the method:

// If Key is not an empty String
// We call the Key method in order
// to initialize the State box

If Not (key.IsEmpty) Then
  Me.Key = key
Else
  // Empty String, so we raise an exception
  Raise New RuntimeException(kkeynotinitialized,Integer(ARCError.KeyNotInitialized))
End If

As you can see, the main thing that the Constructor does is call the Key Method; it’s in charge of initializing the required state box with the provided key. If the key is an empty String, it will raise a Runtime Exception giving a descriptive error message an error number.

Now, let’s add the Key method to our RC4 class:

• Name: Key
• Parameters: Assigns Value As String
• Scope: Public

Being a Public method means that you can change the Key String without needing to create a new instance, if that is what you want to do. For example, you may want to initialize the Class instance using a key, encrypt some blocks of data using that one and then change to a different key in order to encrypt other blocks of data. Just remember that you’ll need to use the same keys in order to reverse to plain data those blocks encrypted with a given key.

In addition, the use of the Assigns keyword is simply syntactic sugar to make it possible to call the method using the equal operator to pass along the required parameter instead of using the regular syntax when calling a method in Xojo code. So, for example, you can use call it using:

MyRC4Instance.Key = "MySecretKey"

Instead of:

MyRC4Instance.Key("MySecretKey")

This is the code snippet that’s going to execute this method:

// Disabling some features for better speed
#Pragma DisableBackgroundTasks
#Pragma DisableBoundsChecking
#Pragma NilObjectChecking False
#Pragma StackOverflowChecking False

// Initialize the index values
Var mFirstIndex As UInt8
Var mSecondIndex As UInt8

// Let's check that this is not an Empty Key String
If Not (value.IsEmpty) Then

  // Trim key length if greater than 256 = max 2048 bits supported by ARC4
  If value.Length > 256 Then value = value.Left(256)

  // Pad the key if it is less than the required min 40 bits (5 bytes)
  // We are going to pad the key repeating the remaining 'n' characters
  // from the begining of the key.
  If value.Length < 5 Then

    Var pad As Integer = 5-value.Length

    value = value + value.Left(pad)

  End If

  // Initialize the State Box if this is the first call to the method.
  // The State box has a maximum of 256 bytes.
  If mBox = Nil Then mBox = New MemoryBlock(256)

  // Just in case there is an older Key in use
  // Let's get rid of the old MemoryBlock storing it
  // And create a new one with the Key lenght (in bytes)
  mKeyBlock = Nil
  mkeyBlock = value
  mKeyLength = value.Length

  // Required initialization of the State Box
  For n As Integer = mFirstIndex To 255
    mBox.UInt8Value(n) = n
  Next

  mFirstIndex = 0

  // Last step on State Box initialization
  // Permutation of values in the State Box
  // using for that the provided Key.

  For n As Integer = mFirstIndex To 255

    mSecondIndex = (mSecondIndex + mBox.UInt8Value(n) + mkeyblock.UInt8Value(n Mod mKeyLength)) Mod 256

    SwapValues(n,mSecondIndex)

  Next

Else

  // If the provided key is an empty String, we raise a new Runtime Exception
  // with a descriptive error message and error number.
  Raise New RuntimeException(kKeyNotInitialized, Integer(ARCError.KeyNotInitialized))
End If

As you can see, both the Constructor and the Key methods raise a Runtime Exception if the provided Key is an empty string. Both the message and error number are defined as a Constant (the message error) and an Enumerator (Error value) as part of the class itself. So go ahead and add a Constant to the ARC4 class using these values:

• Constant Name: kKeyNotInitialized
• Default Value: Key Not Initialized
• Type: String
• Scope: Protected

And for the Enumerator:

• Name: ARCError
• Type: Integer
• Scope: Public
• Value: KeyNotInitialized = -1

In addition, the Key method calls the SwapValues method in order to make the values permutation in the State Box. So add a new method using these values in the Inspector Panel:

• Method Name: SwapValues
• Parameters: FirstValue As UInt8, SecondValue As UInt8
• Scope: Private

While the code to type in the associated Code Editor will be:

Var tmp As UInt8

tmp = mBox.UInt8Value(SecondValue)
mBox.UInt8Value(SecondValue) = mBox.UInt8Value(FirstValue)
mBox.UInt8Value(FirstValue) = tmp

Now just two additional methods left to be added to the class- the ones in charge of encrypting and decrypting a given block of data.

In order to encrypt the data, add a new Method with the following values in the Inspector Panel:

• Method Name: Encrypt
• Parameters: Value As String
• Return Type: MemoryBlock
• Scope: Public

And with the following block of code in the associated Code Editor:

// Disabling some features for better speed
#Pragma DisableBackgroundTasks
#Pragma DisableBoundsChecking
#Pragma NilObjectChecking False
#Pragma StackOverflowChecking False

// Index initialization
Var mFirstIndex As Integer
Var mSecondIndex As Integer

Var k As UInt8

// If we have a non initialized mKeyBlock
// that means that the key has not being initialized
// so we raise an exception
If mKeyBlock <> Nil Then

  // Initialize Key again

  me.Key = mKeyBlock.StringValue(0,mKeyBlock.Size)

  // Let's put the text to encrypt into a memoryblock
  // so it is faster to iterate through their bytes
  Var target As MemoryBlock = value
  Var temp As UInt8
  Var maxSize As Integer = target.Size-1

  // And we calculate the new bytes values (encrypted values)
  // using the ARC4 algorithm
  // Basically, every byte in the source block will be XORed
  // with the calculated byte from the State box.
  For n As Integer = 0 To maxSize

    mFirstIndex = (mFirstIndex + 1) Mod 256
    mSecondIndex = (mSecondIndex + mBox.UInt8Value(mFirstIndex)) Mod 256

    SwapValues(mFirstIndex,mSecondIndex)

    k = mBox.UInt8Value((mBox.UInt8Value(mFirstIndex) + mBox.UInt8Value(mSecondIndex)) Mod 256)

    target.UInt8Value(n) = target.UInt8Value(n) Xor k
  Next

  //…and return the block of data already encrypted
  Return target

Else
  Raise New RuntimeException(kKeyNotInitialized, Integer(ARCError.KeyNotInitialized))
End If

And the last Method, the one in charge of decrypting a block of ARC4 encrypted data:

• Method Name: Decrypt
• Parameters: Source As MemoryBlock
• Return Type: MemoryBlock
• Scope: Public

Typing the following code fragment in the associated Code Editor:

If Not (Source Is Nil) Then

  // Simply call the same method we use to
  // encrypt data, avoiding code duplication
  // and returning the now deciphered data to the caller
  Return Me.Encrypt(Source)

End If

And, that’s all! If you are interested in more information about the ARC4 algorithm you can read this article on the Wikipedia. Or better yet, read the excellent books “Applied Cryptography” and “Cryptography Engineering” to dig in even more on this and other cyphering algorithms. Of course, remember that the Crypto module included in the Xojo framework has a good bunch of these ready to use!

Of course, you also can download the Xojo example project that includes this Class ready to use from this link.

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.

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.