Monthly Archives: June 2014

Installing Citrix Receiver on Raspberry Pi (Raspbian)

Update 20150222:The new RPi2 has an ARMv7 processor. It should run standard officially supported Citrix Receivers. I have not tested this myself.

It is obviously tempting to try to use a Raspberry Pi as a thin client. Often, that means a Citrix client, that requires Citrix Receiver (a closed source program available from Citrix in binary form only).

The problem
Raspbian is very much a normal Debian system. Citrix Receiver usually works nicely on Debian, and Citrix provides ARM binaries. But that would be too easy.

There are two ARM binaries available from Citrix (Receiver 13.0, the current)

  1. ARMEL – for ARM cpus without floating point support
  2. ARMHF – for ARM cpus with floating point support AND at least ARMv7

The Raspberry Pi is based on an ARMv6 WITH floating point support. This means that the ARMHF binary can never run, since ARMv6 lacks instructions required by ARMv7. But it also means that the ARMEL version can not run on Raspbian (although it could work on a Raspberry Pi with another OS).

There are different strategies to this problem: fixing the OS, or fixing the Citrix client.

RPi Thin Client Project
There is a nice effort called RPi Thin Client Project. The version from 2013-11-28 runs everything in ARMEL (without Hardware Float). The good thing is that it actually runs Citrix Receiver on a Raspberry Pi, and the performance of the Receiver itself is quite decent. However, it is based on Debian Unstable, and as I started updating and installing packages it did not work very well. Also, the RPi is not very fast even with Hard Float working, and without Hard Float everything except the Citrix client is very slow.

I see there is now a new Hard Float release of the RPi Thin Client project (2014-06-10), but as far as I can see it does not include Citrix Receiver (feel free to correct or update me!).

Unofficial Citrix Client
On a blog hosted by Citrix, there is an unofficial Citrix Receiver available for download. Obviously Muhammad Dawood has access to the real Receiver source code and he is allowed to compile it and distribute unofficial binaries. If you follow his instructions (install Raspbian as usual, then install Citrix Receiver with his special setup-script) you will get a Hard Float Citrix Receiver on a normal Raspbian system. Very nice! I am running it and it works very well, and I am much looking forward to an official/supported version.

The setup script modifies /boot/config.txt, mostly to overclock the RPi to maximize performance. My RPi did not accept it and refused to start. The good thing is that you can remove the SD card from the RPi and edit the config file with another computer. I only have ONE active line in my /boot/config.txt:


…and you can probably change/remove that line too. I have an old 1280×1024
LCD display, that I connect via an Apple HDMI->DVI adapter, and a DVI-DVI cable. The display is comes up at correct resolution (although lxrandr can not run).

Other ideas
I was thinking about decompiling/recompiling one of the official ARM binaries. After reading a bit about it I gave up without thinking about trying. It probably violates any license agreement too.

Perhaps it could be possible to run some official binary (ARMEL, ARMHF or even x86) using QEMU user mode. Probably the performance would be completely unacceptable.

On Raspbian pages I read that theoretically it is possible to run ARMEL applications on Raspbian using Linux/Debian multi-arch, but there seems to be some hacks made in Raspbian, and this multi-arch probably practically unrealistic.

I recommend go with the inofficial/unsupported binaries from Citrix for now. Lets hope Citrix embraces this some day.

Simple Integer Factorization and RSA key sizes

I have been playing with RSA lately, you know the encryption protocol where you generate two primes, multiply them, give the product away to be used for encryption by others and keeping the primes for yourself since they are needed for decryption (that was very simplified).

I have read that the largest known number to ever have been factorized was 768 bits long. Such a number looks like this (in hex):


For encryption to be safe for the next decades, keys that are 2048 or 4096 bits long are used. Or even longer.

One feature of RSA is that the output of encryption is never smaller than the size of the key (well, again, very simplified). So, imagine you want to encrypt 4-digit pin codes, one-by-one, using RSA with 1024-bit key, each pin code would be several hundred bytes, instead of just a few characters. For almost obvious reasons, you can not make a stream cipher of RSA or some other smart mode of operation to work around this problem (please let me know if I am wrong). This makes me want to use RSA with a small enough key to be secure enough for my purposes.

My questions

  1. What key sizes are trivial to break?
  2. What sizes require some qualified effort?
  3. How hard is it really to factorize big integers?

I found a tool called Yafu. It appears to be rather competent. It would require years of effort and advanced skills in math to write a better tool. For integers 320 bits and larger, Yafu requires GGNFS – a seriously very complicated piece of software that also hard to compile. Luckily there are nice windows binaries from Jeff Gilchrist. I also downloaded a binary version of Yafu for Windows. The examples below use Cygwin to have access to some Unix tools (bc, tr, openssl).

Generating a Prime product and factorizing it
There is a very nice JavaScript project for RSA. Set the bit size to whatever you want (I use 128 in this example), click generate, and obtain “Modulus”:

Modulus (hex): 81653c1536c42501a815431dac804899

Convert to upper case using tr:

$ echo 81653c1536c42501a815431dac804899 | tr '[:lower:]' '[:upper:]'

Then use bc to convert to decimal:

$ bc -q

Finally, factorize using yafu:

$ echo "factor(171996052064283111843964589052488861849)" | ./yafu-x64.exe

06/14/14 13:24:28 v1.34.5 @ TOR, System/Build Info:
Using GMP-ECM 6.3, Powered by GMP 5.1.1
detected         Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz
detected L1 = 32768 bytes, L2 = 6291456 bytes, CL = 64 bytes
measured cpu frequency ~= 3108.870930
using 20 random witnesses for Rabin-Miller PRP checks

======= Welcome to YAFU (Yet Another Factoring Utility) =======
=======                      =======
=======     Type help at any time, or quit to quit      =======
cached 78498 primes. pmax = 999983

fac: factoring 171996052064283111843964589052488861849
fac: using pretesting plan: normal
fac: no tune info: using qs/gnfs crossover of 95 digits
div: primes less than 10000
fmt: 1000000 iterations
rho: x^2 + 3, starting 1000 iterations on C39
rho: x^2 + 2, starting 1000 iterations on C39
rho: x^2 + 1, starting 1000 iterations on C39
pm1: starting B1 = 150K, B2 = gmp-ecm default on C39
ecm: 30/30 curves on C39, B1=2K, B2=gmp-ecm default

starting SIQS on c39: 171996052064283111843964589052488861849

==== sieving in progress (1 thread):     624 relations needed ====
====           Press ctrl-c to abort and save state           ====
546 rels found: 293 full + 253 from 2026 partial, (41408.50 rels/sec)

SIQS elapsed time = 0.0740 seconds.
Total factoring time = 0.2690 seconds

***factors found***

P20 = 14624642445740394983
P20 = 11760701343804754303

ans = 1

Now I wrote a little bash script that does everything:



rm -f key.*
rm -f *.log
rm siqs.dat


openssl genrsa -out key.pem $INTSIZE
openssl rsa -in key.pem -noout -modulus | cut -f 2 -d '=' > key.hex
echo "ibase=16 ; $( cat key.hex )" | bc > key.dec
echo "factor($( cat key.dec ))" | ./yafu-x64.exe -threads 4

I am using yafu with default settings – very hard to imagine I can do anything better than the yafu author. For 320 bits and above, the GGNFS library is required. Performance for different sizes of integers to factorize (using the QuadCore Intel i5-2400 from the output above):

Bits Time Notes
128 0.28s
160 0.33s
192 1.86s
224 8.02s
256 52.6s
288 265s
320 3649s ~30Mb Temp files
352 9291s
384 27261s ~660Mb Temp files
512 73 days

Well, this means that a normal Windows desktop computer can break 512 bit RSA within days or weeks. Below 512 bits, brute force is not much of a challenge, and using 256-bit RSA for encrypting short messages is (unfortunately, since it was what I ultimately wanted to explore) just ridiculous.

As keys get larger, more temp disk space is required, somewhere between 512-768 bits it gets seriously complex (I claim this, as a 768 bit integer is the largest to have been known to ever been factorized into two primes). You can read about General Number Field Sieves to get some background.

Not everyone is capable of extracting the Modulus integer from en encrypted file or network stream, installing Yafu, waiting for a little while and then use the two obtained primes to actually generate a fake certificate or actually decrypt anything. So, if you want to encrypt data to prevent your boss or your wife from reading it, you can probably use any key size you like – or why not use an encrypted zip file or an encrypted MS Word file?

If you have a skilled and motivated enemy, who are willing to put some effort into breaking your encryption, I would not use anything close to 512 bits. I assume the police, or FRA (in Sweden) or NSA can break 512 bit RSA within hours or faster when they need to.

I am not giving any sources for any of my claims here. I am not an expert in factorizing large-prime-products, and I am certainly not an expert in Quantum Computers. But as I understand it; 1024 bits should be fine, but perhaps in 10-20 years using even larger keys may make sense, and I don’t expect to see Quantum computers practically breaking real RSA keys in the next 50 years.

It is fascinating that a 128-bit AES key is completely beyond hope to brute force for any power on earth, while 128-bit RSA keys are worthless.

I now wonder, are there other asymmetric ciphers that are secure with significantly shorter keys than RSA?