Last time we had a model that spelled out what we wanted from a secure key hierarchy. This time I’ll spell out a concrete hierarchy that satisfies the properties of the model. There was one change I made based on a review from Kaoru Kohashigawa: all keys must now be somewhere or be owned by a person Continue reading →

Setting up key hierarchies with the proper access rights can be a little tricky because reasoning through the implications of access and storage can get a little convoluted. Some questions I had when I was trying to do this at work was how do I set things up so that people can have the access they need without jumping through too many hoops and how many hoops do I need for non-trivial security properties? Also, which keys need to encrypt which other keys and where/how can they be stored without sacrificing security? Continue reading →

The puzzle is about 5 couples. We’re going to single out one of the couples and call them Alice and Bob. The names don’t really matter so replace them with whatever names you think are appropriate. The puzzle is about shaking hands. Instead of spelling it out I’ll just present the Alloy model and call out the assumptions in the puzzle as they come up. Continue reading →

I probably should have done this first since it is an earlier exercise in the book. Continue reading →

While learning Alloy this was one of the exercises in the book I was reading. It’s kinda weird to combine “acyclic” and “undirected” for graphs but there is a way to formalize the intuition about what it means for an undirected graph to be acyclic. Continue reading →

While tinkering with a few things at work I stumbled on a combination of tools and ideas that make for a pretty decent tiered backup strategy for appendable workloads using a combination of hot, warm, and cold storage. Continue reading →