Assembly Chess on Raspberry Pi (without any OS)

July 30th, 2014 No comments

Some time back I came across Assembly Chess on Raspberry Pi (without any OS) and today I managed to get this done and finished.  I am impressed, it is well implemented, and just worked straight out of the box.

At least I found some decent use for an empty iPhone 3GS box – you could fit the Raspberry Pi in there as well.

I had some wonderful moments like when I was playing with LEGO as a kid… thank you Xu, Bora and Gun!


Categories: Fun Tags:

Run your own DDNS updates for your home server

June 27th, 2014 No comments

I managed to run my own nifty DDNS update service for/from my home server. Best is that you have a nameserver running with your own domain on it… I am using $DOMAIN as the main zone here.

Nameserver setup

You can either just have a specific entry like home.$DOMAIN or you can create a specific zone for doing your DDNS updates. I went with the latter, as I might want to put more in it in future. From a security point of view it doesn’t matter, as you can restrict DDNS updates to specific records only, ie. don’t won’t allow access to the whole domain this way. And you grant access with a DDNS shared secret – you won’t do it based on IP addresses, do you?

So I guess creating zones with your BIND server should not be a problem, the crux of the matter is to allow/restrict the DDNS upgrade:

update-policy {
  grant home.$HOME.$DOMAIN. name home.$HOME.$DOMAIN. A;

Important note: I had a problem this way on my very first update, “nsupdate” reported a TSIG error. I then changed to the more common “allow-update” statement, run my script as below, and then it worked. After doing the initial creation of the record this way “grant” also worked.

I also create a specific shared secret for this purpose:

dnssec-keygen -a HMAC-SHA512 -b 512 -n USER home.$HOME.$DOMAIN.

This shared secret needs to go into the relevant “key” section, and we also gonna need the files on that machine doing the DDNS upgrades actually.

Script to do automatic DDNS upgrades


if [ -z "$1" ] ; then
  exit 1

logger -t "Param: $1"

nsupdate -k /etc/ddclient/Khome.$HOME.$DOMAIN.+xxx+yyyyy.private << EOT
update delete home.$HOME.$DOMAIN. A
update add home.$HOME.$DOMAIN. 5 A $IP

Not much to it. I am creating my records with a fairly low TTL, but you can change that if you want. Try it, whether it works when you pass an IP, whether it actually updates the record.

Using ddclient to do the magic




I did not know that you can run multiple DDNS updates within one file, so originally I had one for my OpenDNS update and another one for HE Tunnelbroker (for updating my IPv4 endpoint of my IPv6 tunnel). Now this looks tidier and I am calling the script here as a “postscript” parameter as well.

Categories: Scripting Tags:

Re: Heartbleed Bug: Public urged to reset all passwords

April 10th, 2014 No comments

A friend of mine asked me on that article on BBC whether you should change all your password due to that Heartbleed bug within SSL.

It seems there are a few things floating around, a few misconceptions and misunderstanding about the problem. First of all, when you access – a banking site for example, you usually use TLS (“Transport Layer Security”) or the older version SSL (“Secure Socket Layer”). This means that your data from and to your bank is encrypted in transit. The server where your banking site sits on is decrypting your data first, processes your request, but before the data is sent back out, it is encrypted again. Your browser is doing something similar. Received data gets decrypted first, displayed and when your requests are sent off, before they leave your computer, they are encrypted. This is called transport encryption – there is another way of encryption, but we come back to that later.

This encryption method works that each side has two types of digital keys – one is publicly known, the other is secret, and only the endpoints (ie. the “browser” and the “banking server”) know it, this key does not leave the system. With specifically crafted mathematical algorithms it is possible that one side can encrypt data with the public key of the other side, but only the secret key of the other side can decrypt it again – and vice versa. This is also called “Assymetric Cryptography” or also “Public-Key Cryptography”. If you are interested in this, you can find more on that here.

OpenSSL is providing functions to encrypt and decrypt data and is used mostly on the Linux/Unix side. So this Heartbleed Bug is a particular feature of this protocol, what has been added in the last two years. Unfortuntaly they discovered, that it has a major weakness, in that when you craft a specific request, it gives you back that secret key we spoke about before, so its “heart is bleeding”.

What does this mean?

If a server is vulnerable to this, an adversary can use this to get the secret key. That secret key your data in transit is encrypted with. This is the official statement, but there is a little but more to that, and it is a bit tricky to do anything with those secret keys as well.

That somebody can seriously misuse that hey would need to sit between your browser and your banking site, so that they can gather all the traffic. As they have the secret key of the server and all the encrypted traffic they are in a position to decrypt your data what you sent to the banking site. But the internet was not build in one day, neither encryption and there is a feature within SSL which generates a session-key for each session which encrypts the data even further. The design of this is built on the assumption, that you have an adversary on the wire/you have somebody listening in or generally it doesn’t trust the means of transport (ie. copper or fibre). This feature is called Forward-Secrecy. So to summarize, when the server has implemented and enabled this particular feature within its SSL stack and an adversary having the secret key, they still cannot decrypt your data. Unfortunately we do not live in an ideal world. And also unfortunately this feature Forward-Secrecy is not enabled on all the servers on the internet.

So what needs doing are

  1. All websites/servers need to fix this weakness by patching their systems, applying software upgrades.
  2. They also need to generate a new set of secret and public keys on their server.

What about my password now? Do I need to change it?

Everytime you login to a site, your password travels across this encrypted tunnel. The server receives it, has it in “plain text”, ie. the way you typed it, it should ideally hash it and check it with your stored credentials, which are also hashed. A “hash” is a different representation of your password, what cannot be undone, ie. “converted back”, ie. it is a “one-way function”. Encryption on the other side is both-ways, it can be decrypted again. There is only “brute-force” for converting a hash back to its original form. So a fairly common password hash is unfortunately “286755fad04869ca523320acce0dc6a4″ – please use the search engine of your choice and you can find out which plain-text password that would be. SSL is not involved in storing your password or generally when “data are at rest”.

To bring this to an end, changing your passwords is pointless unless your website has not done due diligency yet, ie. patched the weakness and regenerated a new set of keys.If they also have done their due diligence and used Forward-Secrecy, but are vulnerable there is no need to panic still.

Yes, you should do change your password, but don’t use the same password everywhere. Better to be safe than sorry. Use a local password manager like KeePass or Password Safe, do not use your browser to store passwords and/or websites like LastPass (if you use this, all your passwords could be out there, that’s why it is important to have a local password manager, and not on the internet as a website).

Categories: Security Tags:

When you were young a day seemed like a day…

September 30th, 2013 No comments
When you were very young a day seemed to last a year. 
When you were a teenager a day lasted a week.
When you reached middle age a day was over in an hour.
Now last christmas seems like yesterday.

On the grounds that you only have about two weeks left to
live what are you going to do with them?

— By my ex-colleague John (“not sure exactly as it was in a time management course about 20 years ago (seems like yesterday!)”)

Dedicated to John, my friend and former car mechanic.

Categories: Misc Tags:

GBit connection but only ~12MBytes/s transferrate over SSH?

February 28th, 2013 No comments

I came about that my SSH setup was only able to transfer ~12MBytes/s. After some digging I found out that SSHv2 is by default using “3des” as the cipher.

When I set it specifically with “-c blowfish” to a another secure, but much faster block cipher, I got ~24MBytes/s. If you want you can configure this as the default in your ~/.ssh/ssh_config as

cipher_spec blowfish


Categories: Security Tags: