Obfuscated TCP
It's now in its 3rd iteration, Obfuscated TCP now has an updated site, mostly working code etc. I need people to go to the site, look at the docs, watch the video, build the code, try stuff out etc. Tell me what works and what doesn't. Email address is at the top of the page. Thanks to all who do, and remember that you don't just have to email if you have problems, positive reports are good too!
Google datacenters
There are different levels of secrets at Google. Almost everything unreleased is “confidential” - which means that we don't talk about it to the outside world. Then there is the “top secret” stuff - stuff that you don't even talk about to other Googlers.
Now, top secret stuff is rare because it's a little poisonous. An environment where lots of things are secret between coworkers isn't a pleasant one. How we cool our data centers was one of those items and I was sworn to secrecy when I was lucky enough to be given a guided tour of our Oregon operations.
But, for whatever reasons, this information is now public! Seriously, this is some of the coolest (no pun intended) stuff that Google does: go read about evaporative cooling.
A Rabin-Williams signature scheme: rwb0fuz1024
I wrote a Rabin-Williams signature scheme [source]:
- Verification speeds 4x RSA (on a Core2 2.33GHz, at least)
- Signatures are half the size of RSA for the same security
- A hash generic attach is provably as hard as factoring
Crit-bit trees
I wrote up djb's implementation of crit-bit trees for strings here [pdf]. Crit-bit trees have several nice properties:
- Fast: only a single string compare per lookup.
- For finite sets (like 32-bit ints) the depth of the tree is bounded by the length of the longest element.
- Simple code - no complex balancing operations
- Supports the usual tree operations: successor, minimum, prefix set etc.
Several groups of Linux kernel papers have been published recently. Here's my pick of them:
First we have the Proceedings of the 2008 Linux Symposium (these are in some order of order, favourite first):
- 'Real Time' vs. 'Real Fast': How to Choose?
- Korset: Automated, Zero False-Alarm Intrusion Detection for the Linux Kernel
- Low Power MPEG4 Player
- I/O Containment
- Bazillions of pages: The future of memory management under Linux
- Linux capabilities: making them work
- Keeping The Linux Kernel Honest (Testing Kernel.org kernels)
Next there's the ACM SIGOPS Operating Systems Review. These papers are about much more experimental developments in the kernel and are thus more fun, even if they are less likely to see the light of day:
- Extending futex for kernel to user notification
- PipesFS: fast Linux I/O in the unix tradition
- Plan 9 authentication in Linux
I've just released two new curve25519 implementations: one in C and one in x86-64 assembly. The latter is 10% faster than djb's implementation.
curve25519 is an elliptic curve, developed by Dan Bernstein, for fast Diffie-Hellman key agreement. DJB's original implementation was written in a language of his own devising called qhasm. The original qhasm source isn't available, only the x86 32-bit assembly output.
Since many x86 systems are now 64-bit, and portability is important, this project provides alternative implementations for other platforms.
| Implementation | Platform | Author | 32-bit speed | 64-bit speed |
| curve25519 | x86 32-bit | djb | 265µs | N/A |
| curve25519-donna-x86-64 | x86 64-bit | agl | N/A | 240µs |
| curve25591-donna | Portable C | agl | 2179µs | 628µs |
(All tests run on a 2.33GHz Intel Core2)
Google has, at last, open sourced Protocol buffers. My, very minor contribution to this is that I wrote the basis for the encoding documentation.
Protocol buffers pretty much hit the sweet spot of complexity and capability. (See XML and ASN.1 for examples of attempts which missed.) I have the beginnings of a protocol buffer compiler for Haskell that I wrote for internal apps. Now that the C/Java/Python versions are out, I should probably clean that up and put it on Hackage. But every coder should consider protocol buffers for their serialisation needs from now on.
Firstly, if you're wondering what happened to all the ObsTCP stuff, it didn't disappear, it just moved to a different blog. Things are still moving as fast as I can push them.
The Black Swan
(ISBN: 1400063515)
This book has some good, if unoriginal, points about the stupidity of much of the modeling done in today's world, esp the world of finance. Sadly, these are hidden in many pages of self-centered rambling and discourse on adventitious topics. If you're thinking of buying this book, get The (Mis)behaviour of Markets by Mandelbrot instead; you'll thank me.
I've added a bunch of Obsfucated TCP stuff to the obstcp project page code.google.com include kernel patches, userland tools, specs and friendly introductions.
Also, I posted it to Reddit. If it doesn't get downvoted into /dev/null in 60 seconds, the comments will probably end up there.
OpenID - not actually spawn of Satan
A blog post aggregating complaints about OpenID has been popping up in different places this morning. If you've read it, you might want a little perspective. I'm not going to deal with each point in turn because there's so many, mostly repeating each other.
Phishing
At login time, the site that you're logging into can end up redirecting you to your OpenID provider. Your provider then tells you to go to their site and enter your login information, then click a button to try again. They don't provide a "link" to their site and they don't ask for your password.
Some early providers might not have followed these basic steps, but all the reasonable ones do.
Yes, it's still possible for users to be confused but, by habit they'll be used to doing to right thing.
XSS and CSRF
XSS problems on the providers site are a big deal. This criticism is reasonable.
CSRF may be a bigger deal because you are more likely to be 'logged in' to the target. However, most users already keep persistent cookies to save logging into these sites. The additional attack surface here is dubious; CSRF issues are a problem with or without OpenID.
DNS poisoning
If your OpenID starts with https://, you should be protected from DNS poisoning attacks and the like by the usual TLS PKI. This isn't perfect, but it's pretty good.
However, the OpenID spec says that plain domain names are normalised by prepending http://. This is a technical problem with the spec and should be fixed. Until then, this is a reasonable criticism but not a fundamental issue.
Privacy
The OpenID provider has a lot of information about your activities. This is little different than, say, your email account and many people are happy with Gmail. Likewise, password recovery on most of the sites which could use OpenID is based on email access, so most people already have a single password that suffices for entry to many sites.
If you don't like the idea of Gmail you can run your own email server. Likewise, you can run your own OpenID provider.
Using the same OpenID on many sites does allow them to link your activities. So does giving these sites your email address for password recovery. So does using the same IP (although to a lesser extent).
Some providers will let you have many OpenIDs linked to the same account for this reason. Joe user probably won't use that feature and probably gives the same email address to all those sites already and so looses nothing.
Trust problems
OpenID is not a trust system. Trust systems may be built on top of identity systems. Likewise, apples are not oranges and complaints about their lack of tangyness are moot.
Usability / Adoption
Somewhat valid points here. It's a big job to get widespread adoption and, at the moment, it's a pretty small crowd that uses OpenID. However, OpenID doesn't need a flag day; it can have incremental deployment.
Availability
Valid points. If your provider goes down you're going to have a bad day.
Conclusion
I don't believe that OpenID should be used to login to your bank account. However, for the myriad of sites that I login to (Google Reader, reddit, ...) it would be nice to just be able to type my OpenID in. It's decently suited to that because I'm fed up with all these accounts.
Older entries can be found in the archives