Blargh

If you split up code into different libraries you can get a diamond dependency problem. That is you have two parts of your code that depend on different incompatible versions of the same library. Normally you shouldn't get in this situation. Only someone who hates their users makes a non backwards compatible change to a library ABI. You don't hate your users, do you? (just kidding about hating your users.) Disclaimer I thought I'd dive into this problem as a weekend project. Don't rely on this article as a source of truth, but please correct me where I'm wrong. I'm not an expert in creating shared libraries, and it's much harder that it would first appear. The existence of libtool proves that. Example project described can be found here . Multiple versions of the same library The lovely land of modern Unix will allow you to have multiple versions of the same library installed at th...

As you remember from long ago hashes are O(1) best case, but can be O(n) if you get hash collisions. And if you're adding n new entries that means O(n^2) . I thought I'd take a look at the hash_set/hash_map GNU C++ extension. In /usr/include/c++/4.4.3/backward/hash_fun.h : 1 2 3 4 5 6 7 8 inline size_t __stl_hash_string ( const char * __s ) { unsigned long __h = 0 ; for ( ; * __s ; ++ __s ) __h = 5 * __h + * __s ; return size_t ( __h ); } Test program that loads some strings: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 #include<time.h> #include<iostream> #include<hash_set> double getclock () { struct timespec ts ; clock_gettime ( CLOCK_MONOTONIC , & ts ); return ts . tv_sec + ts . tv_nsec / 1e9 ; } _GLIBCXX_BEGIN_NAMESPACE ( __gnu_cxx ) template <> struct hash < :: std :: string ...

As you can plainly see from this graph, my TPM chip can do approximately 1.4 SSL handshakes per second. A handshake takes about 0.7 seconds of TPM time, so when two clients are connecting the average connect time is 1.4 seconds. This means probably not useful on server side, but should be good for some client side applications. To replicate the test, start a server: openssl s_server -keyform engine -engine tpm -accept 12345 -cert foo.crt -key foo.key -tls1 -CAfile foo.crt -verify 1 -status And then connect 100 times: for n in $(seq 100); do time openssl s_client -tls1 -connect localhost:12345 /dev/null 2>/dev/null;done 2> timelog Then just look at the "real" time in the timelog. (if in doubt, use bash. zsh gave me some crap in the log) Example GNUPlot: plot [1:] [0:2] '2' using (2/$1) w l title '2 clients','1' using (1/$1) w l title '1 client'

This is a short howto on setting up TPM-backed SSL. This means that the secret key belonging to an SSL cert is protected by the TPM and cannot be copied off of the machine or otherwise inspected. Meaning even if you get hacked the attackers cannot impersonate you, if you manage to kick them off or just shut down the server. The secret key is safe. It has never been outside the TPM and never will be. This can be used for both client and server certs. Prerequisites A TPM chip. Duh. May need to be turned on in the BIOS. Could be called "security chip" or something. If you don't have a TPM chip but still want to follow along (maybe add TPM support to some program) then you can install a TPM emulator. See links at the end on how to install a TPM emulator. A working CA that will sign your CSR. I will assume you're running your own CA, but you can send the CSR to someone else to sign if you want...

When connecting to a possibly hostile network I want to tunnel all traffic from my browser to some proxy I have set up on the Internet. The obvious way to do this is with a proxy. The problem with that is that the traffic from the browser to the proxy is not encrypted. Even when you browse to secure SSL sites some traffic is being sent in the clear, such as the host name. That's not so bad, but I want to hide my HTTP traffic too. Turns out that at least Chrome does support using SSL between the browser and the proxy , but you can't configure it directly. You have to use Proxy Auto Configuration to point to an HTTPS host:port. Running OpenVPN is out in this case since I want it to work with everything, including Android and ChromeOS… and Windows (without installing "stuff"). Not that I've tried it with Windows yet, but it should work. For added fun I wanted to authenticate to the proxy us...

The short version of the problem and solution I will describe is that while TCP gets up to speed fairly fast, and "fast enough" for many uses, it doesn't accelerate fast enough for short-lived connections such as web page requests. If I have 10Mbps connection and the server has 10Mbps to spare, why doesn't a 17kB web page transfer at 10Mbps from first to last byte? (that is, when excluding TCP handshake, HTTP request and server side page rendering) This is pretty Linux-focused, but I'll add pointers for other OSs if I see them. Short version This will get a bit basic for some people, so here's the short version. Make sure you measure the effect of changing these settings. Don't just increase them and think "more is better". On receiver side (requires kernel version 2.6.33 or newer (and a fairly new iproute package. iproute2-ss100519 works). Use your default route instead of "x.x.x.x"): i...

Yubico and their products are awesome. That pretty much sums up this blog post but I'm going to go on anyway. If you're thinking of introducing two-factor authentication to your company, or you're using something that's fundamentally broken (like RSA SecureID) you simply must at least take Yubikeys into consideration. When I say that SecureID (and others) are fundamentally broken what I mean is that when (not if, as recent history has shown) RSA (the company) is broken into YOUR security is now compromised. When I first used SecureID and found out that you as a customer aren't in control of your own keys my first thought was "well that's just stupid". Why are you giving the keys to the kingdom to someone else? Enter Yubikeys. They just beat SecureID in every way (almost). Benefits: Open specification. You can set your own keys (secrets) and don't have to show them to a third party who...