HashCloak's Blog

hashcloak

By hashcloak

It's been a long time (long time), we shouldn't have left you (left you) Without a dope mixnet to protect you, protect you, protect you, protect you *

After years of hard work, we are finally announcing the first Meson testnet release dubbed Steel Magnet🎉!

Why Steel Magnet? Well, steel magnets are a core component of cyclotrons which are particle accelerators in which meson particles are built. For more details, read this Wikipedia article.

Our first testnet will be simply a local testnet in which users and future node operators alike can experience what it feels like to use Meson. You can also use our wallet demo in order to experience what it's like to send cryptocurrency transactions through Meson!

This testnet will have support for Ethereum, Ethereum testnets and major L2s such as Optimism and Arbitrum. Further, with our wallet demo, you can send your transactions privately using one of Ethereum's most popular privacy tool, Tornado.cash! Due to interest, we are currently in talks to support other blockchains such as Firo and Solana and will be adding support for ZK-Rollups on Ethereum in subsequent testnets!

Testnet Features

This first testnet is meant to test our PKI system , Katzenmint, on a larger scale. Katzenmint is a Tendermint-based PKI system for managing mix nodes building upon the Katzenpost directory authority. This will be the first of many testnets in which we push the limits of Katzenmint.

We will be writing more about our design of Katzenmint and how it differs from other directory authorities in other anonymity systems.

The road ahead

The road to Meson will be long and we want to bring everyone along with us.

Here is a short overview of the road ahead and what other features will be included in subsequent testnets

Internal Audit

At HashCloak, we've been heads down trying to make Katzenmint work and get rid of glaring bugs out of our prototype of Katzenmint. However, since we are building upon the Katzenpost mixnet project, we will be taking the time to take a critical look at the code and seeing where it fails with respect to privacy, anonymity, and code quality. We will be writing more about the process of auditing anonymity networking software, so stay tuned.

Dynamic tuning

Mixnets are really nice in that they scale vertically and horizontally better than most anonymity systems. However, there is no free lunch. When more nodes are added, there are diminishing returns with respect to how large the anonymity sets for messages can be and latency. Add too many mix nodes and you risk the chance of making it easier to de-anonymize messages if there isn't enough traffice. Add too little nodes when traffice increases and then you risk the chance of increasing the latency of messages passing through the mixnet. In both cases, since our use case is blockchain transactions, users risk not only potentially missing out on interesting on-chain opportunities but might also lose some anonymity in the process!

This problem is commonly referred to as dynamic tuning of mix network parameters. In other words, how do we ensure that at a given time, there are enough mix nodes on the network to maximize anonymity while minimizing latency for messages that go through the mixnet? We have been working on this problem for quite a while and will soon enter the prototyping phase for our ideas and then integrate these ideas in a subsequent testnet.

Incentivization

Anonymity networks traditionally have relied on altruistic people running nodes for the greater good of the network. In practice, this has worked out quite well for anonymity networks like Tor. However, running these kinds of nodes is very resource intensive and we should aim to lessen the load on people who decide to participate in a cutting edge anonymity system.

With the advent of alternate funding models facilitated by cryptocurrencies, we will be experimenting with ways (beyond just launching a shitcoin!) in how to ensure that participants in Meson can be compensated!

Running the testnet

In order to run the testnet locally, do the following:

  1. Clone Meson repository $ git clone https://github.com/hashcloak/Meson.git

  2. Checkout to monorepo branch $ git checkout monorepo

  3. Build containers $ python plugin/ops/build_containers.py

  4. Start testnet

$ cd testnet/local
$ docker compose up
  1. Execute ping test
$ cd ping
$ go run main.go -s echo

More details are available at docs.mesonmix.net.

Keeping in touch

If you want to keep in touch with the Meson project, you can follow us on Twitter @MesonMixnet. If you want to follow the developement and research discussions, please join us on Element.

*Reference for this quote: Aaliyah – Try Again

By hashcloak

At HashCloak, we've been leveraging the work done in Katzenpost to build Meson, a mix network for cryptocurrency appplications. We've recently released our first testnet, Steel Magnet, after many years of R&D and debugging. As such, the Meson codebase is relatively small and contains code that we are now intimately familiar with. We figured this would be the best time to start thinking about the security of our anonymous network and prepare for our first internal audit.

In the midst of our research into this, we quickly learned that anonymous networking software doesn't get auditing to the same degree (if at all) as smart contracts or other blockchain enabled software. As such, we have decided to document our efforts in auditing Meson through this multi post blog series. We will be detailing our approach and any resources we develop with the goal of 1) educating others on how anonymous networking should be audited and 2) providing reassurance and transparency to supporters of Meson that at HashCloak, we take the security and privacy of our privacy software very seriously. In this first post, we will be going through our current plans and approach for how we aim to tackle auditing Meson.

The Beginning

As a first step, we started looking into how other well-known anonymity networking software handles audits and external code reviews. We started looking at software that was adjacent to Meson such as Tor, I2P, various VPNs and other mixnet competitors (Nym, Oxen, HOPR, etc). We quickly noticed that mainly only the VPN services had engaged external third parties to audit their software (often times clients, web browser extensions, etc) but the other kinds of privacy adjacent software rarely did this. In the case of Tor, the most famous anonymity networking software of all time, there is a vibrant academic community that seeks to find bugs in both its design and implementation and as such, Tor gets regularly looked at from a diverse set of stakeholders. Even though this doesn't necessarily count as a audit in the traditional sense, this approach has provided very valuable research and it may be possible to find similar bugs in Meson. To a smaller extent, the same can be said of I2P.

However, for the other projects, there have been no publicly published audits regarding the actual client and server software underpinning their networks. When there are audit reports available, it was mainly regarding the smart contract functionality needed for payments and other node management functionality (scalability, credentials, etc). We quickly realized that we will need to develop our own checklists of what to look out for and read more deeply into bugs that have affected previous networks in order to better adapt them to Meson and see how they might translate.

Since everyone on the Meson team at HashCloak has experience auditing software, we already had the skills needed to predict what areas would need more scrutiny and how to conduct research for security-related topics. This would be the first time we would need to develop our own set of resources without relying on the shoulders of giants. So, we set out to gather as much info as we can on anything adjacent to the security of anonymous networking software. We gathered audit reports of VPN clients, CVEs affecting various networks, academic papers, etc. We are still in the process of combing through all of these resources that we gathered. Over the course of this blog post series, we will be detailing our findings and hopefully these findings helps other projects better secure their networks as well.

Our current progress

So far in our process, we have compiled a list of basic things that we should check for no matter what. This minimal list will most likely be a mainstay for every single audit we do for Meson and any anonymous networking code that comes our way as part of our consulting business. You can find our current checklist here.

We will do a quick walkthrough of the checklist. Note that this list is ever evolving and we will be updating it as we learn more about auditing anonymous networking software.

Check and Update Dependencies

Dependencies are often a way in which vulnerabilities creep into a codebase. For every single dependency that we have, we will analyze to see if it needs to be updated or even if we can implement it ourselves and integrate it into the codebase. If we simply need to update it, we will ensure that any code that breaks as a result is confined to a staging branch. If we realize that it may be better for us to fork it or reimplement the functionality, we will take into account the extra time we need for our roadmap.

Set up a fuzzing harness

Fuzzing is a testing technique in which one's code is given arbitrary inputs in order to cause unexpected behavior in the code. The goal is to find areas of the code that hasn't been sufficiently hardened. This will most likely be an ongoing tasks as the codebase gets larger. Once we have a larger scale testnet, we will be using the testnet data to form our corpus to build our fuzzer with.

Check logs for info leaks

Logs are a common source of information leakage in security sensitive applications. These are usually the result of developers adding log messages in order to ease the debugging process but forget to omit them for production releases.

Ensure that installation doesn't escalate privileges

This item mainly relates to when users download a program with Meson embedded such as a cryptocurrency wallet. During the installation process, any executables that contain Meson should be only modifiable by privileged users on that machine. Otherwise, a normal user might have the ability to overwrite executables and escalate privileges.

Check for time of check and time of use bugs

Time of check and time of use bugs are a category of race condition bugs that hard to protect against in large scale distributed systems. The race condition occurs when there is a time gap between when a condition is checked and then that condition is leveraged to execute some code.

Check input and output sanitization

The inputs and outputs of certain operations need to be processed before they are used throughout the codebase. Otherwise, it might be result in intentionally malformed inputs or ouputs being able to trigger undefined behavior within a program. Further, sensitive data can be contained within inputs/outputs and these should be removed accordingly.

Check that Prometheus and Grafana ports are not easily accessible to an attacker

We make heavy use of Prometheus and Grafana for instrumentation and providing Meson node operators with as much information as possible about the state of their nodes. Prometheus and Grafana expose ports in order for the node operator to query data and display it as they see fit. We see this as a potential avenue for information leaks and unauthorized access. As such, we need to ensure that we are not introducing any problems into the Meson codebase by relying on these tools.

Check for the usual cryptography bugs

As Meson is a fork of Katzenpost and Katzenpost relies on many cryptographic protocols for various aspects of its designs, cryptographic implementation bugs can easily creep in. This category of bugs is very familiar to us as we find these bugs through our consulting engagements.

Check container configurations

For easily deploying Meson nodes, we provide docker containers for prospective node operators to use. As with using Prometheus and Grafana, we have similar concerns with potential information leaks and unauthorized access to containers.

Check for signature validation

Signature validation is a common area in which bugs creep into such codebases, that we felt that it warranted its own bulletpoint as opposed to being put together with cryptographic implementation bugs or time of check and time of use bugs. Signatures are used throughout Meson to provide authentication, integrity and confidentiality. As such, signatures need to be validated in order to minimize the risk that any of these properties are broken.

Once we have more items and have added more details, we will most likely create a separate community Github repository with this information so that other teams can check their code against this checklist.

Conclusion

That's the end of our first post in this series as we aim to build a good security foundation for Meson. Stay tuned for the next post! If you have any feedback about anything relating to auditing anonymous networking software, please let us know on Github by commenting on our issue , our Element Community or Tweet at us @MesonMixnet!

By hashcloak

StoffelMPC Mascot

After months of trying to grokk MPC VMs as implemented in MP-SPDZ and SCALE-MAMBA, we are finally ready to publicly announce StoffelMPC!

StoffelMPC aims to be a framework for building MPC as a sidechain applications in order to enable blockchain developers to build more expressive, confidential applications.

StoffelMPC is still very much a work in progress and the repo is quite empty (all the work is in branches though if you wish to ponder engineering design decisions). However, we will now be working more in public as we have figured out one of the harder aspects of the system, virtual machines designed for MPC computation.

Over the next few weeks, we will be going deep into the design of how it all comes together and some potential important applications for the blockchain space.

If you are interested in learning more, you can follow us on Twitter, and watch our github repo. If you are interested in potentially building applications using the framework, then you can fill out our developer survey.

We are also hiring for a junior research engineer to help us build StoffelMPC. Here is the job posting.

Special Thanks to the folks at the Decentralized Systems Lab for working on this problem for years and without their work, we would not be able to pursue this work