web

Cryptographically secure random numbers in Elm

2016-03-04T02:06:58+02:00

Elm comes with a nice purely-functional random number generator in the standard library. In fact, it’s a port of the Haskell’s System.Random.

Not only this random number generator implementation is deterministic (that is, given the same initial seed it will produce the same random sequence), it is also strictly purely-functional (just like everything in Elm, actually).

generate : Generator a -> Seed -> (a, Seed)

Above is the signature of the generate function that you use to produce random values. It takes a generator (Generator a) and a seed (Seed), and returns a randomly generated value (a) and the new Seed. And if you want to generate another random value, you need to use this new Seed in the next call to generate – if not, you’ll get back the same number that you got the first time.

So generate’s type signature explicitly tells us that the random value generation is completely defined by the seed that we supply it. This means that, if we have the initial Seed, we can get the whole sequence of random values.

Can this kind of generator be suitable for security-sensitive applications?

Secure random numbers

Probably not.

Deterministic random generation is great when you want to reproduce the application’s behavior consistently, for example in automated tests. Such generators can, of course, be useful in many other scenarios. For example, in deterministic models in game development, procedural content generation, etc.

But for security-related applications it is completely opposite: you definitely don’t want anyone to be able to figure out your randomly generated private key. If we wanted to generate random values for cryptographic purpose, we definitely wouldn’t want the random generator to be so explicitly predictable.

The perfect generator

Surprisingly, the core Elm library doesn’t come with such a random value generator.

So we’re going to try to bring it to Elm. To start simple, let’s limit to generating Ints – the rest we then can easily derive later.

Suppose our ideal random value generating function would have the following signature:

getRandomInt : () -> Int

According to this type signature, we don’t want to give the generation function any context at all, and we want a random Int in return. As the function doesn’t take a seed or other random generation algorithm parameters as an argument means that the function caller is not in control of the random value generation anymore – perfect.

So how does one implement such a function? Well, turns out it is impossible to do in a purely-functional way. Think about it, how would you make a random number every time if all you are given is a ()? Even returning just different number on each call is impossible:

getRandomInt : () -> Int
getRandomInt () = ... -- what?

Mathematically speaking, the function’s image can not have more elements than it’s domain, by definition. Domain, in our case, is the () type, which is inhabited by exactly one value (or element). This means that such kind of function can only return the same value every time.

Breaking the math

So mathematically, we can not make a perfect random number generator. So what? This is not a maths class, this is hacking!

Given that modern browsers already provide a cryptographically secure random number generator implementation, the window.crypto.getRandomValues function, we will only need to provide Elm bindings for it!

Writing Elm bindings for raw JavaScript code is not complicated. In our case, it would look like this:

// boilerplate
Elm.Native.SecureRandom = {};
Elm.Native.SecureRandom.make = function(localRuntime) {
  localRuntime.Native = localRuntime.Native || {};
  localRuntime.Native.SecureRandom = localRuntime.Native.SecureRandom || {};
  if (localRuntime.Native.SecureRandom.values) {
    return localRuntime.Native.SecureRandom.values;
  }

  // actual code
  var crypto = window.crypto;

  return localRuntime.Native.SecureRandom.values = {
    getRandomInt: function () {
      // generate a singleton array of unsigned 32-bit ints and return
      // that single value.
      return crypto.getRandomValues(new Uint32Array(1))[0];
    }
  };
};

And the Elm module:

module SecureRandom where

import Native.SecureRandom

getRandomInt : () -> Int
getRandomInt = Native.SecureRandom.getRandomInt

Side effects

Okay, this should work, right?

Wrong.

It will run, but will work largely not the way one might expect. The problem is that this isn’t a pure function anymore: the math is broken, and it will not return the same value given the same input (hello, random number generation?), by causing a side effect of changing the random generator’s internal state.

Now if you consider this type signature again, you might see that it doesn’t really make any sense in a purely-functional programming language: it will have to either return the same value every time (because how can a function’s value vary if it can’t get any variation in it’s input?), thus not being random at all, or completely abandon purity (that’s what we did with our JavaScript bindings).

Being impure might not seem like a big deal, but there are practical implications to this. As referential transparency is now broken for your impure (or effectful) function, you can not make a lot of assumptions about your code by just looking at it. The state that the function depends on (to provide the side effects) is now removed from the function’s type signature. You now will need to mentally manipulate this state every time the function is called in order to determine the call’s result. And as this state may change on every call, you now can not tell the result of your program until you actually execute it.

The compiler is now misguided too: since it assumes that all functions are pure, it may decide to reorder, inline or substitute function calls for optimizations. As an effectful function’s result now really depends on some hidden state (of which the compiler is not aware!), these optimizations may result in an absolutely unpredictable and most certainly incorrect program behavior.

Taming side effects in Elm

As we established that our getRandomInt function will have side effects, we now should use the power of the language’s type system and encode this fact in the function’s type. We will also need to use a proper implementation.

One way to accomplish this in Elm is using the Task x a type. It is widely used to do things like HTTP requests, local storage access, reading cookies, etc. All of these operations have side effects, as they either depend on or modify some global environment.

A Task x a value means that some, possibly effectful, action (task) will be performed at some point in time, and a successful result of its execution will be an a value while a failure result will be encoded with an x value. It is not that dissimilar from the .NET’s Task<T> class and Haskell’s IO a.

So our updated function signature should now look like this:

getRandomInt : () -> Task never Int

We know that we want to do an effectful computation – generate a random value of type Int. We’re keeping it simple for now, by saying that our computation can never fail – that’s what the never type variable means in our case.

(The name never doesn’t actually matter, it’s only important that it is a free type variable and our function’s return value of type Task x Int can be used with any x, depending on the context.)

But how do we know that this kind of function will not have any (unwanted) side effects? We know this by inspecting the possibilities that Elm gives us to operate on Task x a values:

You can not get the resulting value out of a Task immediately, thus causing the side effect to happen arbitrarily
You do not control when the Task is actually executed – the Elm runtime does this for you, and you should trust it

You are fundamentally limited to just two things you can do to Tasks:

You only can wait for the Task to complete, and then perform another Task:
```
andThen : Task x a -> (a -> Task x b) -> Task x b
```
And you also can create a Task that will bear no side effects, and will just instantly resolve as completed and either return a particular value or fail with an error value:
```
succeed : a -> Task x a
```
```
fail : x -> Task x a
```

It turns out that this is enough to do all kinds of things when constructing simple or complicated task workflows. In fact, the Task x a type forms a monad.

But there is no way to explicitly run a task in Elm – you run tasks by connecting them to a port. Here, the Elm runtime protects us from using tasks in an incorrect way by completely monopolizing the way they are executed.

Native tasks

Okay, let’s now fix our code to generate random numbers inside a Task. Here’s how our JavaScript code should look like:

// boilerplate
Elm.Native.SecureRandom = {};
Elm.Native.SecureRandom.make = function(localRuntime) {
  localRuntime.Native = localRuntime.Native || {};
  localRuntime.Native.SecureRandom = localRuntime.Native.SecureRandom || {};
  if (localRuntime.Native.SecureRandom.values) {
    return localRuntime.Native.SecureRandom.values;
  }

  var crypto = window.crypto;

  // the Task module
  var Task = Elm.Native.Task.make(localRuntime);

  return localRuntime.Native.SecureRandom.values = {
    getRandomInt: function () {
      // create the Task
      return Task.asyncFunction(function (callback) {
        // notify that our Task has completed with some result
        callback(
          // wrap the random int into a succeeding Task
          Task.succeed(
            // generate a random int
            crypto.getRandomValues(new Uint32Array(1))[0]));
      });
    }
  };
};

We create the Task by calling the Task.asyncFunction function and giving it our worker function that will be called when it’s time to execute the task. Our function will be given a callback, which we should call when the Task is complete, and we are ready to return the resulting value.

Elm code:

module SecureRandom where

import Native.SecureRandom

getRandomInt : () -> Task never Int
getRandomInt = Native.SecureRandom.getRandomInt

As you can see, only the type signature has changed in the Elm module.

Conclusion

I’ve used this approach to accomplish secure random password generation in Elm. (I know, I already did this twice!)

I’ve put these Elm bindings together into a library, which you can find here on GitHub. There is a simple example of how you can use it in practice, but you can also check out the source code of my password generation app. Hope you will find it helpful.

As for side effect management in purely-functional languages, it may look a bit daunting in the beginning, but it definitely pays off in the long run.

Hello, js_of_ocaml

2015-04-20T03:06:58+03:00

Recently I finally got myself to try writing some OCaml. Of course, I never make it easy for myself, so I tried out js_of_ocaml at the same time.

I wanted to improve my password generation tool to generate passwords on the client side, as server-side password generation with security improvement pretense is just clown-worthy.

TL;DR

It all worked out – js_of_ocaml is pretty cool, but I wouldn’t say I’d rush to use it in a production system right away. Of course I have little to no OCaml and js_of_ocaml experience, so perhaps with some more time invested it gets a lot better.

The end result can be seen here: password generation app (CLICK). The source code is on GitHub.

OCaml, js_of_ocaml

OCaml is a general purpose programming language with strong bias towards statically-typed functional programming. It descends from the ML family of languages and has been around for a rather long time now. Some of the cool features of this language are:

first-class parametrizable modules, which are often compared to Haskell’s typeclasses, but are in fact more powerful in a way that they can be parametrized not only by type, but by value. (see OCaml Functors)
sophisticated object system with support for structural typing
powerful type system with support for GADTs and dependent types to some extent.

js_of_ocaml is an OCaml bytecode compiler that outputs JavaScript. It’s been developed since at least 2010 and the project seems to be getting a fair amount of activity.

Since js_of_ocaml compiles OCaml bytecode, it therefore does not limit the language to some subset – it is a full-on OCaml compiler to JavaScript.

Performance

It’s hard to assess performance in my use case since I don’t do any heavy computation and don’t rely on low latency, but let’s look at Chrome dev tools profiler’s data.

Disclaimer: I’m not trying to pretend this is a legit analysis of JavaScript code generated by js_of_ocaml. I’m pretty sure it is the way it is only because I made it so.

The program itself is rather simple. The password generation is done in a series of steps:

parse the password template, creating a password template definition structure
for each item in the passowrd template, run a corresponding random token generation function
concatenate the results into a single string

Memory

According to memory profiler, each password generation run allocates about 20Mb of heap memory. From the chart it looks like most of the allocated objects, by volume, are strings. This looks like a pretty bad result.

Memory allocation chart for a single password generation run.

My guess about this is the inefficient string manipulation code:

let rec explode : string -> char list = function
  | "" -> []
  | s ->
    (String.get s 0) ::
    explode (String.sub s 1 ((String.length s) - 1))

let rec implode : char list -> string = function
  | [] -> ""
  | x :: xs -> (Char.escaped x) ^ (implode xs)

let filter p s =
  (* ugh *)
  explode s |> List.filter p |> implode

OCaml’s standard library doesn’t really have a lot of string processing functions. In fact, the string processing support in standard OCaml is rather lacking, if not abysmal, considering it’s 2015 and there’s no Unicode support.

I just went the simplest route and think that efficiency of this implementation is horrible. I even used that filter function in one place.

CPU

Each generation takes about 50-100ms to complete, including ~1-3 garbage collections, on a 2.3GHz i7. Honestly, this is a pretty bad result as well. I would blame it all on the inefficient string processing again.

Flame graph of a single password generation run.

It doesn’t seem to help that almost half of the time is spent doing garbage collection.

Generated code size

In my case, js_of_ocaml produced around 60kb of minified JavaScript, which I’d say is not bad at all, especially compared to other compilers that have a JavaScript backend. They will often drag the whole runtime into the output, compiling a helloworld-like program to over 1Mb of JavaScript code (looking at you, GHCJS).

Ergonomics

At this minimal level of sophistication my experience with OCaml + js_of_ocaml has been good enough – it works.

There are some pain points though.

Standard OCaml library

String processing support is modest: not a lot of string utility functions, no support for Unicode in the standard library. There also doesn’t seem to be a lot of math functions in the standard library. I suppose there’s everything you need is in the popular libraries like Batteries.

JavaScript interop

Interoperation with JavaScript could be more intuitive/documented. I think it also could be made somewhat easier to do.

Calling OCaml functions from JavaScript:

var generate = function (dict, tpl) {
  // call into js_of_ocaml code
  return window.pwdGen.generate(tpl)(dict);
}

Exposing OCaml code to JavaScript:

let m = Js.Unsafe.obj [| |] in
Js.Unsafe.global##pwdGen <- m;

let js_generate tpl_string dict =
(* ... *)
in

m##generate <- Js.wrap_callback js_generate;

Returning JavaScript objects from OCaml:

(* ... *)
| Error e ->
  let r = Js.Unsafe.obj [| |] in
  r##error <- Js.string ("Could not parse template: " ^ e);
  r
(* ... *)

Opam

Often, the language’s build system or the package manager can give a lot of grief to beginners. I liked my first opam experience though. I found the compiler switching feature very cool, although I only had to use it once so I could get js_of_ocaml to work.

Another password generation tool

2013-12-19T02:06:58+02:00

Motivation

The Windows 2008 R2 on our build server has been reminding me to change the password for quite some time now. Since I can remember I’ve been mostly using relatively short (8-10 characters) randomly generated passwords. While it is not too hard (although takes time) to remember one of those, there’s a much better way to generate a password, as was illustrated in this comic.

Of course, I didn’t want to directly follow that suggestion, so I came up with my own requirements for a perfect password (and perfect password generator) and figured it’s time for me to finally do the thing I wanted to do for a long time now: to become one of the many who’ve created an xkcd-style password generator.

Development

It’s been over a year since I’ve created this gist:

Python 2.7.2 (default, Jun 12 2011, 15:08:59) [MSC v.1500 32 bit (Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> import random
>>> random.seed()
>>> import nltk
>>> from nltk.corpus import wordnet as wn

>>> nouns, verbs, adjectives, adverbs = [list(wn.all_synsets(pos=POS)) for POS in [wn.NOUN, wn.VERB, wn.ADJ, wn.ADV]]

>>> def gen_phrase(*pattern): return [random.choice(i) for i in pattern]
>>> def phrase_to_string(phrase): return ' '.join(s.lemmas[0].name for s in phrase)
>>> def gen_password(): return phrase_to_string(gen_phrase(adverbs, adjectives, adjectives, nouns))

>>> gen_password()
'decidedly Noachian autoplastic bag_lady'
>>> gen_password()
'ad_val faithful regimented accordance'
>>> gen_password()
'familiarly votive empty Gadiformes'
>>> gen_password()
'universally surmountable wiry field_mouse'
>>> gen_password()
'deadpan bilingual grandiose oxygen_deficit'
>>> gen_password()
'flip-flap heterozygous unenlightened solitaire'
>>> gen_password()
'only piquant apart Massawa'
>>> gen_password()
'continuously forty-two coarse-haired Israel'
>>> gen_password()
'actually trigger-happy tactful cobia'
>>>

This gist is basically the essence of what I wanted to achieve: generate passwords by given template.

Here, I used nltk (which is a natural language processing toolkit for Python), which, among other things, gives you access to a dozen of structured corpora and dictionaries and whatnot. I used it to pick a random word that is a specific part of speech. As the WordNet dictionary was the better-structured one, and with permissive license, I’ve decided to use that.

Now, how do I make a webapp out of it, so I can access it from anywhere? I’ve decided that I should finally give Google App Engine a try. Overall, registering an application, downloading the example code, deploying and seeing it running on the appengine server took about 5 minutes, which I think is pretty impressive.

Using nltk and WordNet directly on the appengine seemed overkill, so I didn’t do that. Instead, I’ve flattened the dictionary and all the metadata to a much simpler structure using the following code:

import nltk
from nltk.corpus import wordnet
print 'DICTIONARY =', repr(
    { pos: [lemma.name
        for synset in wordnet.all_synsets(pos=getattr(wordnet, pos))
        for lemma in synset.lemmas]
        for pos in ['NOUN', 'VERB', 'ADJ', 'ADV'] })

As a result, I get a Python dictionary with entries for the parts of speech (nouns, verbs, adjectives and adverbs). Each entry of this dictionary contains a list of words that are of that particular part of speech. The dictionary isn’t stored in any kind of database, but instead is imported into the main.py. The source code for the generated dictionary is a massive 2.8Mb .py file.

By storing the dictionary in a Python file I also simplified the deployment a lot, as the download for WordNet dictionary is a separate step which I wasn’t sure could be automated. I also think this way it actually makes the web app to load faster, as parsing a huge source file is probably faster than querying WordNet via nltk.

Result

Couple hours of work, and voila – the app is ready and you can access it here. I realize that the writing is goofy, but my excuse is that I just had to fill all that space that this Twitter Bootstrap example template had.

One cool feature my generator has that I haven’t seen anywhere else is that the user can set the template from which the password will be generated. For example, the default template is <adj><noun><00>, which means that it will concatenate a random adjective, a noun and a two digit number to create a password. Like this: distributionaldisplaycase83. So far the templating capabilities are limited, but I will probably work on expanding them in future.

Of course, in the spirit of all modern things, I’ve also made the API to the generator available here. The available parameters are template (default is <adj><noun><00>) and count (default is 5). For example, a GET request to https://sparemaranta.appspot.com/api/1/generate?template=<adv>-<adj>-<noun>.<000>&count=3 yielded this for me:

{
  "passwords": [
    "bad-ineligible-staripomoea.837", 
    "astern-shortened-conflictofinterest.857", 
    "unscientifically-indurate-cithern.760"
  ], 
  "template": "<adv>-<adj>-<noun>.<000>"
}

The successful reply will be a JSON object with two properties: passwords, which will contain a list of generated passwords, and template, which will just echo the received template, for debugging purposes.

Only after I was done, I’ve found out that there’s already a generator like that: see here (and it’s even been covered at lifehacker). Interestingly, while it’s been over two years, googling for a password generator will still yield the usual mash-some-random-chars-together-style generators on the first page.

It is questionable whether the safety of an online password generator is good enough, even though the data is pumped over a secure connection, but I think it is at least good enough for me. I might make the generator offline, but for now this project has served it’s both purposes – create something useful and have some fun.

Source code