The previous post on Stateless Session Logout in OpenAM 13 has proved to be quite popular in terms of this blog. While it went into some detail about the technology and the problems that need to be solved in a production system, it was a bit short on actual figures to illustrate the gains. In this post we will rectify that with some theoretical numbers on memory usage and some measurements from early performance testing.
Diffie-Hellman key agreement (DH) is a way for two parties to agree on a symmetric secret key without explicitly communicating that secret key. As such, it provides a way for the parties to negotiate a shared AES cipher key or HMAC shared secret over a potentially insecure channel. It does not by itself provide authentication, however, so it is vulnerable to man-in-the-middle attacks without additional measures. There are several ways to provide these additional measures (e.g. signing the ephemeral public keys using a CA-issued certificate, or using a protocol like OTR), but we will not discuss them here, or go into the details of how the key agreement works. Java provides support out-of-the-box for both original discrete log DH and elliptic curve (ECDH) key agreement protocols, although the latter may not be supported on all JREs. ECDH should be preferred for any new applications as it provides significantly improved security for reasonable key sizes.
As is often the case in Java, the use of these classes can be a bit convoluted. Here we demonstrate simple Java code for ECDH key agreement on the command line. We only demonstrate ephemeral key agreement, in which the two parties generate unique public/private key pairs at the start of the protocol and throw them away once the shared secret has been negotiated. This can form the basis for perfect forward secrecy.
WARNING: the code here is not a complete security protocol and should be used for reference on the Java API only.
One of the headline new features in OpenAM 13 is support for Stateless Sessions, which allow for essentially unlimited horizontal scalability of your session infrastructure. This is achieved by moving session state out of the data store and placing it directly on the client as a signed and encrypted JWT. Any server in the cluster can then handle any request to validate a session token locally by simply validating the signature on the JWT and checking that the token has not yet expired (using the expiry timestamp baked into the token itself). Stateless sessions are not in themselves a new concept, and there are a handful of implementations out there. You may be thinking “Great! Where do I sign?”, but there has been an Achilles’ heel with stateless that has held it back from being truly production-ready — how to handle logout. The general advice is that stateless logout is very hard or impossible. Well, we’re not afraid of a bit of hard work at Forgerock, so we decided to solve that problem. In this post I’ll tell you how we did it.
The GCHQ Christmas card puzzle has had us all scratching our heads at Forgerock Engineering in Bristol this week (well, that and trying to get OpenAM 13 ready, on which more to come soon). Some colleagues have solved the first part by hand. As a lazy programmer though, this seems like such a waste of energy. What if I ever want to solve another such puzzle?! So I decided to solve the puzzle automatically, and constraint programming seemed like the obvious approach as the puzzle is effectively a set of constraints over the shading of a grid. Warning: spoilers ahead if you’ve not solved the first stage already. Continue reading “Solving the GCHQ Christmas puzzle (part 1) with Constraint Programming”
There’s been a lot of discussion of the potential dangers of Artificial Intelligence (AI) recently, as an existential threat to humanity. I think this overplays the risks, but also rather over-estimates how close we are to such an outcome. Some modest recent advances in pattern recognition are little more than baby steps along a path whose end we cannot even clearly define. More importantly though, I think there are two much more likely outcomes of any emergence of general “human-level” AI that pose significant ethical questions:
- Rather than enslaving us, we create genuinely sentient AI and enslave it. This seems a far more likely scenario to me, given humanity’s record so far. Can an AI be “human-level” and yet treated as sub-human?
- Near human-level AI creates immense economic value, while demolishing the market for human labour. Our current efforts (in the UK at least) at dismantling the welfare state and racing to the bottom on corporation tax start to look a little short-sighted from this perspective.
This blog post is a re-posting of my recent answer on StackOverflow regarding ThreadLocal objects and supposed PermGen memory leaks. Essentially, despite what Tomcat may say, ThreadLocal usage in a container is not always a memory leak. Repost of my answer below the line:
Every now and then I discover a new class in the Java standard library that I’ve not needed to use before. Today, that class was CopyOnWriteArrayList (or rather the CopyOnWriteArraySet wrapper). This is a good choice when implementing a set of subscribers in an observer pattern, as typically the set of subscribers doesn’t change very often but we iterate through the set regularly to broadcast events. The COW implementations are optimised for exactly this case, as the iterator only hits a volatile read rather than needing a lock.
Being curious, I decided to have a look at the implementation of this class to verify that it behaved as I expected from the docs. Sure enough, everything is as I would expect. However, something did stick out immediately as a bit odd. Continue reading “The curious case of transient final locks and CopyOnWriteArrayList”