Tag Archives: QT

Quickly and easily transfer files over network

You want to copy a file between two computers or Symbian phones, and the usual methods don’t feel that attractive? Network drives, scp and ftp requires configuring a server (that later might be a security risk). USB cables are never available when needed. DropBox and Bluetooth are too slow.

A while ago I described how to copy files with netcat, but that works best on *nix and is not so easy for people who do not like the command line. And, it does not work on mobile phones.

So, I wrote a little program that does what netcat does but is simple to use and has a GUI. And, I wrote it in QT, so it works in Mac OS X, Linux, Windows and Symbian. It is exactly the same on all platforms.

Do you want a simple way to copy files over the network? Download ParrotCopy and give it a try – instructions included:


The Symbian version probably only works on Symbian^3 and has just been tested on Nokia N8. Let me know if you need a binary for an older Symbian device or a Maemo or Harmattan device.

In server mode, the program tries to connect to www.google.com:80, to figure out its own IP. It is simply an ugly hack because I had problems with other methods. You may have problems if internet is not accessible. I will not release 1.0 until this is fixed.

You have to manually name the file you receive, and you can transfer just one file at a time. These are not bugs, but future versions will probably do better. Netcat can be combined with tar, gzip etc. I hope to add at least tar in the future. For now, making a zipfile is a simple way to transfer many files.

Release 0.9.7
Now possible to copy contents of status field and file/folder fields (if you want to paste it into other application).

Simple Encryption Library for QT (improved)

Update 2022-08-12: It turned out that the library (v1.0.0) did not build with QT 5 because of depricated QT APIs. There is now a new version below (v1.0.2) that should work on QT5 (and hopefully QT6). The randomness setting the Initatialization Vector is much improved and at least in theory this was a weak part of v1.0.0. There was also a function “toAscii” that was deprecated and I replaced it with “toLatin1”, so anyone using the command line tool should check that the same passwords work after upgrading to 1.0.2.

A while ago I posted a simple encryption library for QT on this blog. I have now made some improvements and publish a new version. Major improvements are:

  1. Improved performance
  2. Added non patented Serpent Algorithm
    (easy to include and build without RC5)

As before, SimpleQtCryptor should work on all QT platforms without modification. It has no dependencies to anything outside QT and just uses qt datatypes.

Performance – SimpleQtCryptor vs OpenSSL
Since encryption is just overhead to any program using it performance is important. I have tried to optimize SimpleQtCryptor as much as possible, without making the code hard to read or risking portability.

For practical purposes, its performance is comparable to that of OpenSSL. This is on an Athlon II X2 250 3GHz cpu running Ubuntu:

RC5-32/CBC      RC5-64/CBC      RC5-64/CFB      Serpent/CFB     AES-128-CFB
6.5s / 9.0s     3.5s / 6.1s     3.2s / 5.9s     16.4s / 17.6s   5.8s / 7.8s
6.3s / 9.5s     3.5s / 6.1s     3.1s / 5.7s     16.4s / 19.0s   6.0s / 8.3s

Values are presented as user time/real time (including a sync command).
First line is encrypt, second line is decrypt. The data is a 512MB file.

The first 4 columns are SimpleQtCryptor using different algorithms and modes of operation. The last column is 128-bit AES for OpenSSL.

Performance – different machines
For different machines, benchmarks have been made (just algorithm, no streaming or I/O):

                                RC5-32  RC5-64  Serpent 
Athlon II X2 250 3GHz   | enc   4.6s    2.3s    14.6s   
512Mb data, Ubuntu      | dec   4.6s    2.3s    14.8s
Athlon II X2 250 3GHz   | enc   5.8s    3.2s    22.4s
512Mb data, Windows7 64 | dec   5.6s    3.2s    20.6s
Intel Core i5 2.3GHz    | enc   6.9s    3.4s    19.1s
512Mb data, Mac OS X    | dec   6.6s    3.3s    19.2s
Intel Pentium(M) 2.0Ghz | enc   10.9s   47s     35s
512Mb data, Windows7 32 | dec    9.8s   46s     36s
Intel Atom z520 1.33Ghz | enc   20.2s   83s     113s
512Mb data, Windows7 32 | dec   19.2s   84s     130s
PPC G4 866Mhz           | enc   20.4s   62s     85s
512Mb data, Mac OS X    | dec   32.9s   61s     83s
ARM,QNAP TS109 500Mhz   | enc   8.6s    30.4s   58.4s   
64Mb data, Debian       | dec   8.2s    26.4s   92.7s   

It is fascinating to see how different CPUs perform. A few comments:

  • 32 bit machines suffer more from the 64 bit version of RC5, than the other way around – stay with 32 bit unless you know most clients will be 64 bit
  • Serpent uses a precomputed SBOX table (16kb), and CPUs with little cache (Atom and especially the ARM) underperforms on Serpent
  • The Mac OS X G4 compiler fails to use the assembler right roll used in decryption (but finds left roll for encryption) which makes RC5-32 suffer (but not Serpent, for some reason).
  • See how much slower the program runs on Windows 7 than on Ubuntu (on the Athlon II X2). The Microsoft SDK and Microsoft compiler is used, and I expected it to outperform gcc, not the other way around. I wonder if this applies to 32-bit machines as well, but currently I have no dual boot 32 bit machine available.

As usual, building is easy with QT:

 $ qmake
 $ make

Including in your project
If you want to include the SimpleQtCryptor in your project just copy these three files to your project:

  serpent_sbox.h (not necessary, but improves serpent performance 5-10 times)

You only need to #include simpleqtcryptor.h.

In the beginning of simpleqtcryptor.h there is a #define WITHRC5 that you can remove if you do not want RC5 in your program (for legal reasons).

The README file should tell you most things you need to know to include and use the library.

Bad implementations of encryption algorithms is a very bad idea. I believe my implementation is correct and secure – I can not guarantee it. Implementation details (especially regarding modes of operations) make this library incompatible with other encryption libraries. You can not (expect to) decrypt data with any other implementation, even if they use the same encryption algorithms.

The source code for SimpleQtCryptor is here released under the GPLv3 license. If you need another license for the (not patent encumbered) Serpent part I will try to be flexible.

The implementation of Serpent was originally coded in 2000, before the AES competition was resolved. Later Serpent lost to Rijndael, which became AES. In 2011 this Serpent implementation was ported to QT and optimized.

The implementation of RC5 was made in 2010 because I wanted simple encryption for QT, without being dependent on any non-qt-components. RC5 was chosen (despite it is patent protected) because it is a very simple algorithm to implement.

The command line tool
The library comes with a command line tool. The purposes of the command line tool is:

  • To demonstrate how to use the library in QT code
  • To facilitate self-test functionality – you can run this after building on your machine/OS/qt version to ensure compability with other builds.
  • To be used as a benchmark tool

If you want a simple command line encryption tool I strongly recommend you use OpenSSL instead!

This is how to use command line tool:

  SimpleQtCryptor -t testfile
  SimpleQtCryptor -b e|d rc532|rc564|spt Mb (benchmark Mb)
  SimpleQtCryptor -e OPTIONS
  SimpleQtCryptor -d OPTIONS
  SimpleQtCryptor -h
  -k SecretFile (preferred to -p)
  -p Secret (default = )
  -i IndataFile
  -o OutdataFile
  -rc5    : use native RC5 algorithm (default)
  -rc532  : use 32-bit RC5
  -rc564  : use 64-bit RC5
  -spt    : use Serpent algorithm
  -cbc    : CBC
  -cfb    : CFB (default)
  -n      : no header
  -v      : verbose

Download (latest 1.0.2) (updated 2022-08-12)
Source code: SimpleQtCryptor-1.0.2.tar.xz
I dont really see that I would build the command line tool and distribute binaries for any platform.

Download (old 1.0.0)
Source code: SimpleQtCryptor-1.0.0.tgz
Command line tool for Windows: SimpleQtCryptor-1.0.0-x86.exe, SimpleQtCryptor-1.0.0-x64.exe

At this point I don’t supply any binaries for Linux or Mac OS X, however a Symbian version should show up some day.

Simple encryption library for QT (RC5)

Update:Also check out the new improved library.

A while ago I did some QT programming. I think the QT API is very good and useful. I like things about C++ more than Java, but at the same time QT takes away most of the annoyances with C++. Especially, developing cross-platform GUI applications is very nice with QT.

One thing I missed was a simple encryption library. I mean, there is QCA, but how simple is it to use?

So, I did the forbidden thing, and implemented my own encryption library. Ok – it is for many reasons a very stupid thing to do. But it was fun, I did it anyway, it works, and I will share it with you 😉

Well, I did another forbidden thing; I based my library on RC5 – a very elegant and simple encryption algorithm, protected by patents (at least in the US, where I do not live). Anyway, it is of course allowed to make an open source implementation of RC5.

The downloadable package contains three things: the library, a command line encryption utility using the library, and a little command line “unit test” tool. The files are named as:

  • main.cpp – test utility
  • simpleqtrc5.* – the library
  • simpleqtrc5_test.* – the unit test tool

As always with QT, building is very easy:

  $ qmake
  $ make

I used QT 4.5 and QT 4.6. Perhaps you are fine with older versions as well.

I suggest you have a look in the main.cpp-file, or simpleqtrc5.h for examples, instructions and documentation.

The library of course uses QT datatypes, so you can use it very naturally from any QT code. The core is implemented in somewhat optimized C code, that only uses QT datatypes, so it should be 100% portable. There are no non-QT dependencies.

I have implemented both a 32 bit version and a 64 bit version of the algorithm. Of course, both versions work on any CPU, and you chose algorithm at runtime. 32 bit algorithm is faster on 32 bit cpu, and 64 bit algorithm is faster on 64 bit cpu. Maybe this is the only 64-bit implementation of RC5?

Performance is reasonable, as you can see in this example (Ubuntu 11.04, x64):

$ time md5sum 100Mb.bin
28a8c7a11327880877f21c78b7222273  100Mb.bin

real	0m0.238s
user	0m0.220s
sys	0m0.010s

$ time openssl enc -e -aes-128-cbc -k p4ssw0rd -in 100Mb.bin -out 100Mb.aes.enc

real	0m0.580s
user	0m0.510s
sys	0m0.060s

$ time openssl enc -d -aes-128-cbc -k p4ssw0rd -in 100Mb.aes.enc -out 100Mb.aes.dec

real	0m0.619s
user	0m0.460s
sys	0m0.150s

$ md5sum 100Mb.aes.dec
28a8c7a11327880877f21c78b7222273  100Mb.aes.dec

$ time ./SimpleQtRC5 -e -p p4ssw0rd -i 100Mb.bin -o 100Mb.rc5.enc

real	0m1.678s
user	0m1.540s
sys	0m0.120s

$ time ./SimpleQtRC5 -d -p p4ssw0rd -i 100Mb.rc5.enc -o 100Mb.rc5.dec

real	0m2.064s
user	0m1.970s
sys	0m0.090s

$ md5sum 100Mb.rc5.dec 
28a8c7a11327880877f21c78b7222273  100Mb.rc5.dec

$ ls -l 100Mb.*
-rw-r--r-- 1 freke freke 104857600 2011-05-04 19:16 100Mb.aes.dec
-rw-r--r-- 1 freke freke 104857632 2011-05-04 19:15 100Mb.aes.enc
-rw-r--r-- 1 freke freke 104857600 2011-05-04 19:10 100Mb.bin
-rw-r--r-- 1 freke freke 104857600 2011-05-04 19:19 100Mb.rc5.dec
-rw-r--r-- 1 freke freke 104857634 2011-05-04 19:19 100Mb.rc5.enc

Above you can see:

  1. Calculating md5 sum of 100Mb-file
  2. Encrypting using openssl/aes-128 in 0.6s
  3. Decrypting using openssl/aes-128 in 0.6s
  4. Calculating md5sum to confirm that decryption recovered original file
  5. Encrypting using QT/RC5 in 1.7s
  6. Decrypting using QT/RC5 in 2.1s
  7. Calculating md5sum to confirm that decryption recovered original file
  8. Listing 100Mb files

The test program is quite simple to use:

$ ./SimpleQtRC5 
SimpleRC5 (v0.0)
  SimpleRC5 -t testfile
  SimpleRC5 -e OPTIONS
  SimpleRC5 -d OPTIONS
  SimpleRC5 -h
  -k SecretFile (preferred to -p)
  -p Secret (default = )
  -i IndataFile
  -o OutdataFile
  -w32    : use 32-bit words
  -w64    : use 64-bit words
  -w      : use native CPU words (default)
  -cbc    : CBC
  -cfb    : CFB (default)
  -n      : no header
  -v      : verbose

The only thing to explain is that without the header, the program can not itself figure out what options to use to decrypt (32/64 bit or cbc/cfb). The header does not reveal anything at all.

!! Please download the new and improved library !!

You can download the source: SimpleQtRC5-0.1.tgz.

If you have any questions, suggestions or complaints just let me know! I really believe the library is stable and secure, and simple to use! I might document it better if anyone cares about it.

Building QT framework on Mac and Windows

When building programs with QT that you want do distribute to your friends, I found it preferable to compile the QT library myself.

On Mac OS X this was nice, because I could choose architecture combination for my binaries exactly as I wanted (PPC only, or PPC32 + x64, for example).

On Windows it was nice because I could download the latest Windows Platform SDK (which is free!) and build QT with it. That way, I could create both x86 and x64 Windows binaries that could be distributed along with no other files whatsoever.

However, building QT takes a long time. And if you are unlucky or too ambitious with your configure switches, it might not build at all. So, here are simply a few working configurations:

Mac OS 10.5, PPC, XCode 3.1.3, QT 4.5.3

# qt_conf_carbon-ppc_x86.sh
./configure -release -no-qt3support -nomake examples -nomake demos -arch ppc -arch x86 -platform macx-g++42 -sdk /Developer/SDKs/MacOSX10.5.sdk/ -prefix /Users/zo0ok/qt_dev/4.5.3-carbon-ppc_x86

# qt_conf_cocoa-ppc.sh
./configure -release -no-qt3support -nomake examples -nomake demos -arch ppc -cocoa -platform macx-g++42 -sdk /Developer/SDKs/MacOSX10.5.sdk/ -prefix /Users/zo0ok/qt_dev/4.5.3-cocoa-ppc

# qt_conf_cocoa-ppc_x64.sh
./configure -release -no-qt3support -nomake examples -nomake demos -arch ppc -arch x86_64 -cocoa -platform macx-g++42 -sdk /Developer/SDKs/MacOSX10.5.sdk/ -prefix /Users/zo0ok/qt_dev/4.5.3-cocoa-ppc_x64

# qt_conf_static-ppc.sh
./configure -static -release -arch ppc -sdk /Developer/SDKs/MacOSX10.5.sdk/ -no-framework -prefix /Users/zo0ok/qt_dev/4.5.3-static-ppc

# qt_conf_static-ppc_x86.sh
./configure -static -release -nomake examples -nomake demos -arch ppc -arch x86 -platform macx-g++42  -sdk /Developer/SDKs/MacOSX10.5.sdk/ -no-framework -prefix /Users/zo0ok/qt_dev/4.5.3-static-ppc_x86

Please refer to the QT documentation to understand the advantages of carbon vs cocoa. Note that all those configurations are made on (and for) a PPC target. You might just want x64 if you build for modern Macs.

Mac OS 10.6, x64, XCode 3.2.6, QT 4.7.3

$ ./configure -release -no-qt3support -nomake examples -nomake demos -arch x86_64 -cocoa -platform macx-g++42 -sdk /Developer/SDKs/MacOSX10.5.sdk/ -prefix /Users/zo0ok/qt_dev/4.7.3-cocoa-x64

For some reason I got linking error an hour into the building process when using the MacOSX10.6 sdk. But those of you who are cutting edge dont use 10.6 and 3.2.6 anyways.

Windows SDK 7.0, x64 OS, QT 4.6.1
If you install the (free) Windows SDK 7.0 you get all compilers and make tools you need (you can use Visual Studio C++ Express, but it does (did) not build for x64.

Now, in the Windows world, compiling for different target cpus is quite simple (but a bit confusing). When you build QT the build happens in two steps. In the first step (configure) some tools are compiled (qmake, and more). That qmake will be used to build the rest of qt in the second step.

If you “cross compile” on Windows you will first use x86 MS tools to build x64 QT tools. In the second step (nmake) x86 and x64 tools will end up being mixed and you get problems (linking problems if I remember correctly. So, the easiest way to get it right is to not cross compile but:

  1. Build x64 QT using native x64 Microsoft tools
  2. Build x86 QT using native x86 Microsoft tools

This is easy, on an x64 version of Windows, as it runs x86 programs just fine. I really have to put a screenshot here, because there is no other way to explain this Microsoft mess:

The executables you see (cl, the C compiler, for example) are the x86 tools generating x86 binaries. You use those tools if you invoke vcvars32.bat. But then there are four folders containing the same tools for different other combinations:

Tools bat-file Description
amd64 vcvars64.bat Create x64 on x64 (USE)
x86_amd64 vcvarsx86_amd64.bat Create x64 on x86 (avoid)

Dont even bother with the irrelevant ia64 stuff. When you have a shell with environment from the correct vcvars file, this is how to build QT (exactly the same for both versions):

> configure.exe -static -release -no-qt3support -platform win32-msvc2008
> nmake sub-src sub-tools

Note: on Windows it was best to build qt “in place” (no -prefix used). So, I suggest you install the qt source to two different folder: c:\qt-x86 and c:\qt-x64. When you are done you can make your own copies of the vcvars-files and add qt\bin-folder to the path.

On Windows it is clever to add to your .pro-file:

CONFIG += embed_manifest_exe

That way, the exe file is the only thing you need to distribute (well, people might need the right c/c++ runtimes installed).

Your friends running Linux can compile from source 🙂