Archive for the ‘Networking & Security’ Category

Some people seem to be obsessed by long keys for cryptographic purposes. While it does increase the strength of the key, it also decreases the performance. Beyond a certain point, adding extra bits just isn’t worth it. Bruce Schneier did the calculations in his book Applied Cryptography, I added the conversion to SI units: (I’m quoting without permission, under the “review/criticism” and “research/study” exceptions. If the copyright owner does not agree, please contact me.)

One of the consequences of the second law of thermodynamics is that a certain amount of energy is necessary to represent information. To record a single bit by changing the state of a system requires an amount of energy no less than kT, where T is the absolute temperature of the system and k is the Boltzman constant. (Stick with me; the physics lesson is almost over.)

Given that k = 1.38×10-16 erg/°Kelvin [1.38 × 10−23 J/K], and that the ambient temperature of the universe is 3.2°Kelvin, an ideal computer running at 3.2°K would consume 4.4×10-16 ergs [4.41 × 10−23 J] every time it set or cleared a bit. To run a computer any colder than the cosmic background radiation would require extra energy to run a heat pump.

Now, the annual energy output of our sun is about 1.21×1041 ergs [1.21 × 1034 J]. This is enough to power about 2.7×1056 single bit changes on our ideal computer; enough state changes to put a 187-bit counter through all its values. If we built a Dyson sphere around the sun and captured all its energy for 32 years, without any loss, we could power a computer to count up to 2192. Of course, it wouldn’t have the energy left over to perform any useful calculations with this counter.

But that’s just one star, and a measly one at that. A typical supernova releases something like 1051 ergs [1044 J]. (About a hundred times as much energy would be released in the form of neutrinos, but let them go for now.) If all of this energy could be channeled into a single orgy of computation, a 219-bit counter could be cycled through all of its states.

These numbers have nothing to do with the technology of the devices; they are the maximums that thermodynamics will allow. And they strongly imply that brute-force attacks against 256-bit keys will be infeasible until computers are built from something other than matter and occupy something other than space.

The calculations are slightly off; however, it does give a very good indication how far bruteforcing can go, ever.

When you cycle through all possibilities by incrementing the counter, the number of bit changes is higher. To count up to N, you need N flips of bit 0 (the least significant bit); N/2 flips of bit 1; N/4 flips of bit 2; … Some clever mathematicians proved that 1+1/2+1/4+1/8+… = 2, so you need 2N bitflips in total. A 187bit counter hence requires 2 * (2^187-1) bitflips, roughly 3.9E56.

By iterating in a smart way, you can reduce the number of flips to half of that. Calculating this smart way may however require more energy than you’re saving…

Sometimes, you want to manually alter the caching behaviour of linux. Making sure all data is committed to disk can be done by the sync command. If you want to flush the caches for reads as well, you need to go deeper into the system.

echo 3 > /proc/sys/vm/drop_caches

Writing 1 only clears the pagecache; 2 clears the dentries and inodes; 3 clears all.

There has been a lot of fud lately about the privacy of your browser-history. JavaScript can detect which URL’s you have visited and act accordingly. This can range from a useful script to only show the social networks you actually use, or a site that lists your history. However, nothing is stopping the JavaScript to “call home” with this information.

I too was a bit worried about this potential privacy breach. Obviously there are several solutions and workarounds:

  • Systematically clear your browser history
  • Use a sort of private browsing mode
  • For Firefox: Disable layout.css.visited_links_enabled in about:config. This completely disables visited-links, so you won’t be able to see which sites you’ve visited
  • For ancient Firefox 2.0: SafeHistory extension

I use CAcert.org for most of my X.509 certificates (aka SSL-certificates). It has some very important advantages and disadvantages: being free and being non-default in most systems. Usually it’s not much of a hassle to import the root certificate into a browser, OS or mail client. On Android however, things seemed a little more complex.

CAcert.org does provide some detailed instructions , but they needed some tweaking to work on my MacOSX system. Simply following the instructions got me this helpful error:

keytool error: java.lang.ClassNotFoundException: org.bouncycastle.jce.provider.BouncyCastleProvider

Continue reading ‘Installing an additional X.509 root certificate on Android’ »

TBF or Token Bucket Filter is a tool from the linux kernel. It can be inserted as a “queueing discipline” for an Ethernet device. TBF is usually employed to limit the bandwidth.

I tried to configure TBF on my Ubuntu 9.10 VMware box, but I got disappointing results: I only got around 100kbps, no matter what I configured. I tried the same setup on a physical server, with the same results.

Continue reading ‘How to get TBF back to work’ »

SSH is a wonderful tool. It allows you to run commands on a remote host, either manually, or from scripts. Obviously, since it’s a remote connection, you must authenticate yourself to the remote host. There are several ways of doing this.

When using SSH in a script, most pages tell you to use public keys. While this is an excellent idea, it’s sometimes just not possible due to policy. This Expect script fakes a regular username-password login

#!/usr/bin/expect -f

set target [lindex $argv 0]
set password [lindex $argv 1]
set command [lindex $argv 2]

spawn ssh $target $command

match_max 100000
# Look for passwod prompt
expect “*?assword:*”
# Send password aka $password
send — “$password\r”
# send blank line (\r) to make sure we get back to gui
send — “\r”
expect eof

This script can be run like this:

./ssh-passwd.ex root@192.0.2.1 password “ls /root”

I just read this message by Mark Andrews on the BIND mailing list. It explains the possible issues with DNSSEC and over-protective firewalls, giving test-commands to verify your setup. This post is also interesting for regular DNS traffic, since a firewall doesn’t know the difference.

Continue reading ‘DNS(SEC) – Firewall issues’ »

DNSSEC, short for DNS security, provides a security extension to the all important DNS system. A nice intro can be found on wikipedia. This is a part of a series on DNSSEC:

  1. The RRSIG record
  2. The NSEC and NSEC3 record
  3. The DNSKEY and DS record
  4. Implementation

Time to put things together and setup a simple DNSSEC secured zone using BIND. Instead of providing a walkthrough, I’m just going to refer to the DNSSEC HOWTO (local mirror of the PDF version) of NLnetLabs. It provides a very thorough explanation of the whole DNSSEC concept, including copy-paste examples to try out. Also, it goes more into practical details such as key rollover, the benefits of using two keys (a Zone Signing Key, or ZSK, and a Key Signing Key, KSK).

Continue reading ‘DNSSEC – Implementation’ »

DNSSEC, short for DNS security, provides a security extension to the all important DNS system. A nice intro can be found on wikipedia. This is a part of a series on DNSSEC:

  1. The RRSIG record
  2. The NSEC and NSEC3 record
  3. The DNSKEY and DS record
  4. Implementation

To verify the digital signatures inside the RRSIG records, the client needs to have access to the corresponding public key. What better mechanism than DNS itself could be used to convey this information to the clients? Public keys are stored in DNSKEY records inside the zone. To facilitate key rollovers, new keys are added ahead of time, while old keys remain in the zone until all entries have expired in the caches. Continue reading ‘DNSSEC – The DNSKEY and DS record’ »

DNSSEC, short for DNS security, provides a security extension to the all important DNS system. A nice intro can be found on wikipedia. This is a part of a series on DNSSEC:

  1. The RRSIG record
  2. The NSEC and NSEC3 record
  3. The DNSKEY and DS record
  4. Implementation

While the RRSIG record allows you to verify the authenticity of returned records, there is still a gap remaining. What if the requested name does not exist? Since the DNS server replies with an empty answer section, there is nothing to sign. That’s where NSEC (or its brother NSEC3) comes into play. An NSEC record (Next SECure) states the range of names that do not exist. By signing this NSEC record by a corresponding RRSIG record, one can prove that a domainname does in fact not exist.

Continue reading ‘DNSSEC – the NSEC and NSEC3 record’ »