Since libprio is open source, we should be able to get a free Coverity account and the configure travis-ci to run the scans automatically:
https://scan.coverity.com/travis_ci

libprio is failing to build for Linux, although it works for macOS (which is a very similar environment which makes the failure kinda confusing to me)

• multiple definitions of main https://treeherder.mozilla.org/logviewer.html#?job_id=192678977&repo=try&lineNumber=38219 - I think this one is just that we're building files that are including other .c. files that we don't need to, I can probably fix this in the Firefox side (moz.build)
• lots of NSS "undefined references" in https://treeherder.mozilla.org/logviewer.html#?job_id=192717640&repo=try&lineNumber=38958

Currently we have a partial copy of non-exported NSS code in the mpi/ subdir, and require the Travis script to work in lock-step with the NSS version. This is done to try to allow consumers of libprio to build against binary versions of NSS, since this can be really painful especially on Windows.

This doesn't seem worth the headache however, and it makes it look like libprio is quite a bit more code than it is (including a bunch of scary-looking ASM!)

Instead I think we should just download NSS releases from source and build it: https://github.com/nss-dev/nss

Optionally, Prio servers should add Laplace-distributed noise to their shares of the final statistic before publishing them. In this way, the final output of the system can be differentially private w.r.t. to the data of any particular client.

@hsivonen mentioned this in a recent review: https://phabricator.services.mozilla.com/D16267#412614

Seems unfortunate that libprio uses integer types whose size is implementation-defined instead of using the types from <stdint.h> (in this case uint64_t).

@henrycg any reason not to make this change? I think this basically means giving up on C90 support and requiring C99. The only C90 compiler in wide use that I am aware of is MSVC (issue #17) and I am less convinced that this is important given that clang works well on that platform now.

Now that Travis CI is running it'd be pretty easy to add things like test coverage, static analysis tools (clang-tidy and scan-build are OK, there are more), fuzzing, style checking etc.

I know that there is a particular code style already in-place for libprio but I'd very much suggest that some out-of-the-box style using clang-format be used (it comes with a Mozilla style even!) and enforced when PRs are opened. More for the sake of future contributors than as a personal preference (but that too ;)

To use prio as a backend for e.g. federated learning, support for fixed-point encoding would be nice. Since we only have summation of bits, preserving sign bits is not an option so an additive shift should be applied to the encoding.

I started work on this and will do a (draft) PR when it's presentable.

I noticed this doing tryserver (pre-checkin CI) builds:

z:/build/build/src/third_party/prio/prio/client.c(10,10): fatal error: 'strings.h' file not found

• It looks like <string.h> is present on Windows, AFAICT <strings.h> is an BSD fork that didn't make it's way to Windows. Not 100% sure of the lineage here or what's available to C++ vs. C, it looks like <string.h> is available on macOS and Windows for C code at least.
• std::isxdigit doesn't seem to work on Windows but isxdigit does

Rather than just computing sums of 0/1 values, allow computing sums of b-bit ints for b > 1.

Windows isn't supported on Travis-CI, but AppVeyor does and is free for open-source projects: https://github.com/marketplace/appveyor

Firefox CI tests Win64+Clang, but will not catch issues in eventual MSVC support (issue #17). Also Firefox has its own build system so won't test that libprio can be built standalone on Windows (issue #37 or just in general).

Since we're building libprio in Firefox there is OK coverage for basic stuff, but I think it'd make everyone's lives easier if there was some basic CI like Travis or CircleCI etc. that compiled, linted, ran tests, etc. when folks opened PRs and after merges, so it doesn't require someone to remember to do this locally before merging.

We'd catch this on import to Firefox but that could be quite a long lag time :)

I'll have a bit of free time to do this and have done it before so can set it up if you like.

I was just taking a look at browser-test.c and encode-once.js, I took a quick stab at rewriting the latter:

/*
 * Copyright (c) 2018, Henry Corrigan-Gibbs
 * 
 * This Source Code Form is subject to the terms of the Mozilla Public
 * License, v. 2.0. If a copy of the MPL was not distributed with this
 * file, You can obtain one at http://mozilla.org/MPL/2.0/.
 */

ChromeUtils.import('resource://gre/modules/Services.jsm');

let [publicKeyA, publicKeyB, batchID, param1, param2, param3] = arguments;

Services.prefs.setStringPref('prio.publicKeyA', publicKeyA);
Services.prefs.setStringPref('prio.publicKeyB', publicKeyB);

async function test() {
  let params =  {
    'browserIsUserDefault': Boolean(param1),
    'safeModeUsage': Boolean(param2),
    'startupCrashDetected': Boolean(param3)
  };

  let result = await PrioEncoder.encode(batchID, params);
}

test().then(console.log("finished"));

This still needs to return the correct output, but I was doing a quick test run with is and seeing:

Hit MOZ_CRASH(NSS_Shutdown failed) at /Users/rhelmer/src/mozilla-central/xpcom/build/XPCOMInit.cpp:1044

I suspect that this has to do with how NSS gets init'd in the xpcshell environment, as I am seeing no problems when running equivalent code in the browser.

I haven't tried directly with Scons but I suspect it'll fail in the same way:

https://treeherder.mozilla.org/logviewer.html#?job_id=195528704&repo=try&lineNumber=32847

14:45:50 INFO - /builds/worker/workspace/build/src/third_party/prio/prio/client.c:48: error: undefined reference to 'next_power_of_two'
32848 14:45:50 INFO - /builds/worker/workspace/build/src/third_party/prio/prio/config.c:130: error: undefined reference to 'next_power_of_two'
32849 14:45:50 INFO - /builds/worker/workspace/build/src/third_party/prio/prio/server.c:255: error: undefined reference to 'next_power_of_two'
32850 14:45:50 INFO - /builds/worker/workspace/build/src/third_party/prio/prio/server.c:282: error: undefined reference to 'next_power_of_two'

I'll spin up an Android dev environment at some point, this platform is not really a top priority for me at the moment but will be good to have it eventually.

Right now, the .travis.yml file points to a non-permanent version of NSS. Whenever Mozilla releases a new version of NSS, the file name changes and our Travis CI builds all fail. It would be nice to have the tests automatically use the latest version of NSS.

Most Firefox builders use Clang/LLVM nowadays but one of our builders still uses MSVC so this came up:

https://treeherder.mozilla.org/logviewer.html#?job_id=195697225&repo=mozilla-central&lineNumber=6090

10:05:12 INFO - z:/build/build/src/third_party/prio/prio/encrypt.c(80): error C2057: expected constant expression
10:05:12 INFO - z:/build/build/src/third_party/prio/prio/encrypt.c(80): error C2466: cannot allocate an array of constant size 0
10:05:12 INFO - z:/build/build/src/third_party/prio/prio/encrypt.c(80): error C2133: 'key_bytes': unknown size
10:05:12 INFO - z:/build/build/src/third_party/prio/prio/encrypt.c(84): error C2057: expected constant expression
10:05:12 INFO - z:/build/build/src/third_party/prio/prio/encrypt.c(84): error C2466: cannot allocate an array of constant size 0
10:05:12 INFO - z:/build/build/src/third_party/prio/prio/encrypt.c(84): error C2133: 'spki_data': unknown size
10:05:12 INFO - z:/build/build/src/third_party/prio/prio/encrypt.c(281): error C2057: expected constant expression
10:05:12 INFO - z:/build/build/src/third_party/prio/prio/encrypt.c(281): error C2466: cannot allocate an array of constant size 0
10:05:12 INFO - z:/build/build/src/third_party/prio/prio/encrypt.c(281): error C2133: 'aadBuf': unknown size
10:05:12 INFO - z:/build/build/src/third_party/prio/prio/encrypt.c(319): error C2057: expected constant expression
10:05:12 INFO - z:/build/build/src/third_party/prio/prio/encrypt.c(319): error C2466: cannot allocate an array of constant size 0
10:05:12 INFO - z:/build/build/src/third_party/prio/prio/encrypt.c(319): error C2133: 'aad_buf': unknown size

I believe this is because MSVC doesn't support VLAs (variable length arrays), it wants the array size to be specified at compile time:

https://stackoverflow.com/questions/5246900/enabling-vlasvariable-length-arrays-in-ms-visual-c

Travis-CI supports macOS: https://docs.travis-ci.com/user/multi-os/

Should just require some changes to .travis.yml

The README has working instructions for Debian-flavored Linux (Travis-CI uses Ubuntu Trusty), and I've been keeping the macOS instructions up-to-date (we could have Travis-CI check this too FWIW but it hasn't been a priority for me at least :) )

However building on Windows is super painful:

1. there aren't convenient NSS packages AFAIK, and that is a pain to build (it's being worked on)... https://bugzilla.mozilla.org/show_bug.cgi?id=1434943 helps a lot for getting it working w/ MSVC, but I don't think there's a great way to build with clang-cl outside of mozilla-central

Even in the presence of convenient Windows NSS packages, it is sometimes desirable to do debug builds of NSS or otherwise modify the NSS source, and getting this going took the most time.

2. msgpack requires CMake which can be pretty hairy to get going and working with MSVC (I haven't even tried w/ clang yet)

3. libprio requires the latest SCons and Python 2.7 or so, which is doable but can be pretty tricky to get right

We have all of the above building in mozilla-central using our moz.build build system only and Clang for everything, which is nice but really hard to reuse anywhere else.

However, I think we could take a few notes from it:

• I don't think we actually build msgpack on its own, just a few bits of it similar to what standalone libprio does for NSS mpi: https://searchfox.org/mozilla-central/rev/dd965445ec47fbf3cee566eff93b301666bda0e1/third_party/prio/moz.build#33-39
• modern NSS build uses gyp, which apparently moz.build has some support for https://searchfox.org/mozilla-central/rev/dd965445ec47fbf3cee566eff93b301666bda0e1/security/moz.build

I am wondering if we could reduce the problem just to getting Python 2.7 + SCons + Clang installed on Windows, and drive the rest from SCons... those are probably the least painful dependencies involved here :)

I think the process could look like this:

1. install git, python 2.7, clang on Windows (there are installers for these)
2. from Windows command line, pip install scons gyp then scons build

Then SCons would:

• check out NSS/NSPR and build them using gyp, passing along the DEBUG flag
• check out msgpack and just include sources from it similar to how m-c works

libprio could stop having a vendored copy of the NSS mpi files too since it would know where the NSS sources were.

Travis-CI unfortunately does not support Windows and I don't know of any solid plans to do so - I think that https://github.com/marketplace/appveyor is an option however.

It would be nice to rewrite the ptest utility to use googletest:
https://github.com/google/googletest

While trying to plot the relationship between the client input and payload size, I ran into a few issues.

Here are some simplified examples:

from prio import prio

# number of input bits
k = 2047

_, pk = prio.create_keypair()
config = prio.Config(k, pk, pk, b"test")
client = prio.Client(config)
data = bytes([1]*k)
client.encode(data)

This returns two bytestrings of size 49251 and 155 respectively.

When k = 2048:

---------------------------------------------------------------------------
RuntimeError                              Traceback (most recent call last)
<ipython-input-79-44942f1cbd1c> in <module>
      7 client = prio.Client(config)
      8 data = bytes([1]*k)
----> 9 client.encode(data)

~/Work/python-libprio/prio/prio.py in encode(self, data)
    117 
    118     def encode(self, data):
--> 119         return prio.PrioClient_encode(self.config.instance, data)
    120 
    121 

RuntimeError: PrioClient_encode was not succesful.

A different error occurs at k = 4096:

---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
<ipython-input-82-29aeb9b7d227> in <module>
      4 
      5 _, pk = prio.create_keypair()
----> 6 config = prio.Config(k, pk, pk, b"test")
      7 client = prio.Client(config)
      8 data = bytes([1]*k)

~/Work/python-libprio/prio/prio.py in __init__(self, n_fields, server_a, server_b, batch_id)
     33             server_a.instance,
     34             server_b.instance,
---> 35             batch_id)
     36 
     37     def num_data_fields(self):

ValueError: PyCapsule_New called with null pointer

I added basic tracing statements to debug the Python wrapper; both of the errors return this error:

build/prio/client.c:72
build/prio/client.c:111
build/prio/client.c:219
build/prio/client.c:301

It looks like something along these lines may be causing issues:

Is there a documented input size for the encode function?

Running pip install prio results in the following error on Windows: Cannot open include file: 'blapit.h'

Environment: Windows 10; Python 3.10.0; pip 21.2.3; (tried it on multiple windows-pc's). It works on Linux,

The full error:

Collecting prio
  Downloading prio-0.2.tar.gz (207 kB)
     |████████████████████████████████| 207 kB 3.3 MB/s
Using legacy 'setup.py install' for prio, since package 'wheel' is not installed.
Installing collected packages: prio
    Running setup.py install for prio ... error
    ERROR: Command errored out with exit status 1:
     command: 'C:\Users\xxxxx\test\venv\Scripts\python.exe' -u -c 'import io, os, sys, setuptools, tokenize; sys.argv[0] = '"'"'C:\\Users\\xxxxx\\AppData\\Local\\Temp\\pip-install-xl6_jnan\\prio_4b0d94ba5e1c42df93abeac942cbd6b6\\setup.py'"'"'; __file__='"'"'C:\\Users\\xxxxx\\AppData\\Local\\Temp\\pip-install-xl6_jnan\\prio_4b0d94ba5e1c42df93abeac942cbd6b6\\setup.py'"'"';f = getattr(tokenize, '"'"'open'"'"', open)(__file__) if os.path.exists(__file__) else io.StringIO('"'"'from setuptools import setup; setup()'"'"');code = f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' install --record 'C:\Users\xxxxx\AppData\Local\Temp\pip-record-onq_uk0h\install-record.txt' --single-version-externally-managed --compile --install-headers 'C:\Users\xxxxx\test\venv\include\site\python3.10\prio'
         cwd: C:\Users\xxxxx\AppData\Local\Temp\pip-install-xl6_jnan\prio_4b0d94ba5e1c42df93abeac942cbd6b6\
    Complete output (17 lines):
    running install
    running build
    running build_py
    creating build
    creating build\lib.win-amd64-3.10
    creating build\lib.win-amd64-3.10\prio
    copying prio\libprio.py -> build\lib.win-amd64-3.10\prio
    copying prio\prio.py -> build\lib.win-amd64-3.10\prio
    copying prio\__init__.py -> build\lib.win-amd64-3.10\prio
    running build_ext
    building '_libprio' extension
    creating build\temp.win-amd64-3.10
    creating build\temp.win-amd64-3.10\Release
    C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\bin\HostX86\x64\cl.exe /c /nologo /Ox /W3 /GL /DNDEBUG /MD -I/usr/include/nspr -I/usr/include/nss -IC:\Users\xxxxx\test\venv\include -IC:\Python310\include -IC:\Python310\Include -IC:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include -IC:\Program Files (x86)\Windows Kits\NETFXSDK\4.8\include\um -IC:\Program Files (x86)\Windows Kits\10\include\10.0.17763.0\ucrt -IC:\Program Files (x86)\Windows Kits\10\include\10.0.17763.0\shared -IC:\Program Files (x86)\Windows Kits\10\include\10.0.17763.0\um -IC:\Program Files (x86)\Windows Kits\10\include\10.0.17763.0\winrt -IC:\Program Files (x86)\Windows Kits\10\include\10.0.17763.0\cppwinrt /Tclibprio_wrap.c /Fobuild\temp.win-amd64-3.10\Release\libprio_wrap.obj
    libprio_wrap.c
    C:\Users\xxxxxr\AppData\Local\Temp\pip-install-xl6_jnan\prio_4b0d94ba5e1c42df93abeac942cbd6b6\libprio/include/mprio.h(16): fatal error C1083: Cannot open include file: 'blapit.h': No such file or directory
    error: command 'C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\Community\\VC\\Tools\\MSVC\\14.29.30133\\bin\\HostX86\\x64\\cl.exe' failed with exit code 2
    ----------------------------------------
ERROR: Command errored out with exit status 1: 'C:\Users\xxxxx\test\venv\Scripts\python.exe' -u -c 'import io, os, sys, setuptools, tokenize; sys.argv[0] = '"'"'C:\\Users\\xxxxx\\AppData\\Local\\Temp\\pip-install-xl6_jnan\\prio_4b0d94ba5e1c42df93abeac942cbd6b6\\setup.py'"'"'; __file__='"'"'C:\\Users\\xxxxx\\AppData\\Local\\Temp\\pip-install-xl6_jnan\\prio_4b0d94ba5e1c42df93abeac942cbd6b6\\setup.py'"'"';f = getattr(tokenize, '"'"'open'"'"', open)(__file__) if os.path.exists(__file__) else io.StringIO('"'"'from setuptools import setup; setup()'"'"');code = f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' install --record 'C:\Users\xxxxx\AppData\Local\Temp\pip-record-onq_uk0h\install-record.txt' --single-version-externally-managed --compile --install-headers 'C:\Users\xxxxx\test\venv\include\site\python3.10\prio' Check the logs for full command output.

I've spent some time this week debugging issues with Travis CI (some of the github admins at Mozilla needed to do some work), it seems to still not be working... I see builds happening and get emailed about them (since Travis is set up via my account), but it's not working in PRs.

I was talking to a co-worker earlier about the state of GitHub integration for Mozilla's Taskcluster CI, and it sounds like there are quite a few projects using it successfully. I think it'd be pretty easy to switch over.

This would also allow us to use a modern Linux distro, as Travis is stuck on an older Ubuntu we've had to do extra work to make sure there are newish versions of our build dependencies.

Not super urgent at the moment and I hacked around it, but before I forget:

The macOS instructions in the README no longer work, because the latest SConstruct doesn't seem to honor the LDFLAGS to find the shared libs and CPPFLAGS to find the headers.

Should be pretty trivial to fix, I'll get it when I have a free moment (as I mentioned I just hacked the file to hardcode the paths I get from the homebrew installs)

In the appendix to the full Prio paper, we describe an optimization that reduces the server-side computation to O(n), for a data vector of n items, from O(n log n). It would be nice to implement this optimization.

With a bit more work, it may also be possible to get down to O(n) work on the client side. Ask me if you're interested in working on this.

libprio uses locale-dependent character classification and manipulation functions like, isdigit, isxdigit, isupper, islower and toupper.

This is problematic.

First, libprio passes char to these, but these are defined to take int whose value is the value of an unsigned char or EOF. On platforms where char is signed, passing it directly to these functions without casting to unsigned char first results in sign-extension and Undefined Behavior when the high bit of the char is set.

Second, these are locale-dependent, which makes them inappropriate for processing protocol text. Even the ones that aren't locale-dependent by standard are made so by Microsoft.

See:
https://stackoverflow.com/questions/2898228/can-isdigit-legitimately-be-locale-dependent-in-c
https://daniel.haxx.se/blog/2018/01/30/isalnum-is-not-my-friend/
https://daniel.haxx.se/blog/2008/10/15/strcasecmp-in-turkish/

I suggest doing the intended comparisons with char literals. That is, ('0' <= c && c <= '9') in place of isdigit(c).

First seen on Travis, I can reproduce locally by running ptest -v in a loop:

build/ptest/encrypt_test.c:306: mu_check((rv = (PrivateKey_decrypt(pvtkey_imp, decrypt, &plainLen, sizeof(decrypt), output, outputLen))) == SECSuccess) failed, resuming test case
build/ptest/encrypt_test.c:313: mu_check(rv == SECSuccess) failed, resuming test ca

Tests done:
	10 test suite(s) passed, 1 failed, 0 skipped.
	73 test case(s) passed, 1 failed.
	1441815 check(s) passed, 2 failed.

I've reproduced it on master (a898b55) after ~100 tries.

We've found at least one drawback to msgpack so far:
https://bugzilla.mozilla.org/show_bug.cgi?id=1486478

I think we could go with something simpler/smaller since libprio only uses it internally and not on the wire.

One of my colleagues suggested we could potentially use Rust for this, since doing this sort of thing is super easy and can be done in safe rust code, you just derive(Serialize, Deserialize) on your structs for example: https://github.com/mozilla/sccache/blob/master/src/protocol.rs

This could be done as a small library which exposes a C API, however I do worry a bit about whether that might expose us to timing or other side-channel since the codegen for Rust is different than C and (presumably) not as well understood by the crypto community at large.

In any case, we could probably go with something simpler/smaller than msgpack, and maybe not even have to write it :)

The API makes it possible to generate a key pair and to serialize the public key. The private key should also have accompanying functions for serialization to aid with server development.

This seems to be the intended usage of the API:

1. Start server A, export public key
2. Start server B, export public key
3. Create a client instance with public keys from server A & B

The servers currently don't have a way of persisting their private keys across sessions (reboots, etc).

As of January 1 2019, Mozilla requires that all GitHub projects include this CODE_OF_CONDUCT.md file in the project root. The file has two parts:

1. Required Text - All text under the headings Community Participation Guidelines and How to Report, are required, and should not be altered.
2. Optional Text - The Project Specific Etiquette heading provides a space to speak more specifically about ways people can work effectively and inclusively together. Some examples of those can be found on the Firefox Debugger project, and Common Voice. (The optional part is commented out in the raw template file, and will not be visible until you modify and uncomment that part.)

If you have any questions about this file, or Code of Conduct policies and procedures, please see Mozilla-GitHub-Standards or email [email protected].

(Message COC001)

We're opening this issue because your project has used Travis CI within the last 6 months. If you have already migrated off it, you can close and ignore this issue.

Travis CI is ending free builds on public repositories. travis-ci.com stopped providingthem in early November, and travis-ci.org will stop after December 31, 2020. To avoid disruptions to your workflows, you must migrate to another CI service.

For production use cases, we recommend switching to CircleCI. This service is already widely used within Mozilla. There is a guide to migrating from Travis CI to CircleCI available here.

For non production use cases, we recommend either CircleCI or Github Actions. There is a guide to migrating from Travis CI to Github Actions available here. Github Actions usage within Mozilla is new, and you will have to work with our github administrators to enable specific actions following this process.

If you have any questions, reach out in #github-admin:mozilla.org on matrix.

FYI: The following changes were made to this repository's wiki:

• defacing spam has been removed

• Restricting write access to contributors is strongly encouraged. Please make that change (documentation).

These were made as the result of a recent automated defacement of publically writeable wikis.

The file prio/params.h contains a large precomputed table of roots of unity, which we use to get a modest speedup when computing FFTs. The speedup is not large enough to justify carrying around this huge table and shipping it with the binary—we should just compute this table on the fly as needed.

I wrote a functional Python binding, python-libprio. It uses SWIG for interface definition and has support for a large number of languages. I've found the binding to be useful -- it's been straightforward to use in data analysis tools like pandas.

It looks like SCons has native support for SWIG, so it would fit well in this project. The python binding references this library as a submodule, which can be inverted to be a modular piece of this codebase.

It would be nice to deploy on this on an alpine-python docker image (~60 mb) for testing. Alpine alone is 5mb, but python provides a richer tool-set for testing the entire system. As a security oriented distribution, alpine has up-to-date packages for nss and nspr. The one thing that might need to be tackled as part of a PR is to optionally build the library using musl libc instead of glibc.

Currently we use clang-format 3.9 because in ded8b10 this was the latest version on Ubuntu Trusty, which was what Travis CI stuck us with at the time.

Since 52643ce we've been on Ubuntu Bionic, so we can upgrade to a much newer version (9.0), which is what Homebrew is at right now as well.

We'll need to re-format the code though since one of the reasons we've been stuck in 3.9 is that there were breaking changes after that version.

Re: #100 (comment).

When the state of two servers are merged, the config objects are compared for consistency.

This could be refactored to use a PrioConfig_cmp function that compares the config of the two servers, as well as the other server bits.

Since we're already using clang by default, it would be nice to compile the ptest utility using MemorySanitizer, AddressSanitizer, and UBSanitizer. This way, Travis CI can catch these types of bad behavior during testing.

Some details on how to compile with the sanitizers are here.

• Read in only the right number of roots of unity, per TODO note here:
  

  libprio/prio/config.c

  Line 29 in a95cfdd

  // TODO: Read in only the number of roots of unity we need.

  
  as mentioned in this bug:
  https://bugzilla.mozilla.org/show_bug.cgi?id=1509511#c3
• Store the precomputed Roots array in raw binary format, to reduce the size of the array and the amount of work required to deserialize it. The array is here:
  https://github.com/mozilla/libprio/blob/master/prio/params.h#L32