If you need an unguessable random string (for a session cookie or access token, for example), it can be tempting to reach for a random UUID, which looks like this:
This is a 128-bit value formatted as 36 hexadecimal digits separated by hyphens. In Java and most other programming languages, these are very simple to generate:
String id = UUID.randomUUID().toString();
Under the hood this uses a cryptographically secure pseudorandom number generator (CSPRNG), so the IDs generated are pretty unique. However, there are some downsides to using random UUIDs that make them less useful than they first appear. In this note I will describe them and what I suggest using instead.
Continue reading “Moving away from UUIDs”
I’m seeing a large spike in attempted comment spam, so I’ve turned off all commenting for now.
Updated 20th July 2017 to clarify notation for the point of infinity. A previous version used the symbol 0 (zero) rather than O, which may have been confusing.
Updated 28th May 2020: in step 4 of the full validation check, n is the order of the prime sub-group defined by the generator point G, not the order of the curve itself. This is critical for security if you are performing this check because small-order points will satisfy the order of the curve (which is h * n), but not the order of G.
In the wake of the recent critical security vulnerabilities in some JOSE/JWT libraries around ECDH public key validation, a number of implementations scrambled to implement specific validation of public keys to eliminate these attacks. But how do we know whether these checks are sufficient? Is there any guidance on what checks should be performed? The answer is yes, but it can be a bit hard tracking down exactly what validation needs to be done in which cases. For modern elliptic curve schemes like X25519 and Ed25519, there is some debate over whether validation should be performed at all in the basic primitive implementations, as the curve eliminates some of the issues while high-level protocols can be designed to eliminate others. However, for the NIST standard curves used in JOSE, the question is more clear cut: it is absolutely critical that public keys are correctly validated, as evidenced by the linked security alert.
Continue reading “So how *do* you validate (NIST) ECDH public keys?”
I am sometimes asked whether doing a PhD was worth it, given that I left academia and research to become a full-time software developer. My answer is an unequivocal “yes”, despite the fact that my thesis is about as relevant to what I do now as a book on the sex lives of giraffes.
By far the most important skill I learnt during that time was not any particular technical knowledge, but rather a general approach to critical thinking—how to evaluate evidence and make rational choices. In a profession such as software engineering, where we are constantly bombarded with new technologies, products and architectural styles, it is absolutely essential to be able to step back and evaluate the pros and cons to form sensible technology choices. In this post I’ll try and summarise the approach I take to making these decisions.
Continue reading “Critical thinking for software engineers”
A new month a new job. I’m now working as a Java Application Developer for a large software consultancy. I’ll be developing Java EE applications for this job, which will be an interesting experience. I’m keen to really get my hands dirty with what is currently the de facto standard for building large business apps.
My first challenge is to get to grips with the Java Persistence API (JPA), which provides a standardised object-relational mapping (ORM) for Java applications. Basically, it takes a bunch of annotated Java classes and determines how best to map these to a relational database, taking care of foreign key constraints, inheritance, joins, and so forth. On the surface, this is all very good. Current best practice in developing these kinds of apps is to separate out the data model of the domain into a layer of simple Java beans (i.e., objects with properties and little custom behaviour), so something like JPA makes this much easier to knock together than using JDBC directly. (Although, it’s not that hard to use JDBC). Continue reading “Relations ain’t “flat””
A pair of fascinating links from LtU on choosing the right defaults. First, an entertaining TED talk by Dan Ariely, which I highly recommend. Second, a very promising looking IDE concept, CodeBubbles, which certainly seems to be providing some good defaults.
I came across this ridiculous Internet argument today, via xkcd. I find it both amusing, and worrying, the number of people who insist that the plane will not take off. This is a classic example of what philosophers call a thought experiment, and demonstrates only what most thought experiments demonstrate: that our intuitions about even quite simple phenomena are often very wide of the mark. In this case, the intuition is that a vehicle on a treadmill will not move if the treadmill matches the speed of its wheels. While this is true for vehicles (and people) that get their forward thrust from pushing against the ground, an aeroplane certainly doesn’t. The thrust here comes from the propellers or jet turbines that push against the air. These generate an enormous force backwards, which, as per Newton, generates an equal and opposite force pushing the plane forward. If you draw a diagram and label the force arrows (as in school physics lessons), you will see an enormous forward arrow with the only opposing forces being air resistance and a tiny amount of friction from the wheels. It is a basic law of mechanics that when there is a net force acting on an object in a certain direction, then that object will accelerate in that direction. No amount of fast spinning treadmills can reverse the laws of physics. As others mentioned, the wheels will simply spin faster, as they are acted on by forces both from the aeroplane and the treadmill. The wheels decouple the rest of the plane from this treadmill force, and thus the transferred force is negligible. This is, after all, the entire point of having wheels on a plane, and not for instance just having skis.
A pet peeve of mine is the ongoing public misperception that computers are really all about numbers. This is constantly reinforced by the mainstream (and even IT) media. Take, for instance, this quote from a BBC News story today:
The DNS acts as the internet’s address books and helps computers translate the website names people prefer (such as bbc.co.uk) into the numbers computers use (188.8.131.52).
What this quote means to say is “DNS transforms textual domain names (such as bbc.co.uk) into the numeric dotted-form (184.108.40.206) that is used by the Internet Protocol (IP)”. To the actual computer, both of these are just patterns of bits that represent symbols. A numeric interpretation is no more or less convenient for the computer than any other symbolic representation: it’s all just patterns of electrical charge as far as the machine is concerned. The inventors of IP could just as easily have chosen to use a DNS-style address representation. It happens that the sort of symbol shifting that computers do is very good for numerical tasks, and it also happens that we know a lot about how to do things with numbers, and so numbers are useful in a lot of applications of computers. In this case, the numeric form can be compactly represented, and efficiently manipulated. That was an engineering decision, not a fundamental limitation of computers.
My love of computers stems from a fascination with language, logic, and fundamental notions of representation and interpretation. Diving into computing has brought me into contact with all sorts of ideas from philosophy, physics, mathematics, linguistics, psychology, cognitive science, and AI. It saddens me that people miss out on these extraordinarily beautiful ideas because of a persistent belief that its all really about numbers, which puts a lot of people off.
Steven Pinker has an interesting talk on the TED conference website, debunking the idea that we are living in an increasingly violent society. As Pinker shows, over pretty much any timescale you care to look at, violent death rates have been dropped considerably, and we now live in the safest time ever. Fascinating and cheering.