HashCloak's Blog

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

Written by Yahsin Huang

An update about HashCloak team research projects as well as development progress over the past month.

This post marks the first of HashCloak update posts. We will share some of the projects we have been working on, highlight our recent client work, as well as announce some of the research grants we received this past month.

Meson mixnet project

Github repo: https://github.com/hashcloak/Meson

Meson mixnet project is one of the main internal projects we have been focusing on over the past year. Our goal is to build a multi-chain mix network focused on bringing network-level privacy to cryptocurrency transactions. It's based on the Katzenpost software project, which is a series of software libraries for building mixnets.

It currently supports Binance Chain and Ethereum (and its derivatives!). It has received funding from the Binance X Fellowship and the Ethereum Foundation.

For the past year or so, we have been working on mix network R&D which has mainly focused on designing a new mix network PKI called Katzenmint. The implementation of Katzenmint is ongoing and you can follow its development on Github. In addition to the implementation, we will also be publishing a paper draft of the Katzenmint PKI design. In the coming months, we will be launching a more public facing but limited testnet launch for Meson, along with more of our mixnet R&D coming to fruition. Stay Tuned!

HoneyBadgerSwap project

Github repo: https://github.com/initc3/HoneyBadgerMPC

HoneyBadgerSwap is an AMM-based dark pool built using MPC. The goal of the project is to demonstrate the paradigm of using MPC as a sidechain for building more expressive confidential applications on Ethereum. The work was done in conjunction with the Decentralized Systems Lab at UIUC under the leadership of PhD Student Yun Qi Li. Stay tuned for a more formal paper along with more interesting applications of this paradigm!

SoK paper on Universal SNARKs

In order to provide newcomers to the world of SNARKs, for the past year, we have been writing an SoK on universal SNARK constructions, lead by Karl Yu. We will be posting a draft on eprint in the coming months.

PIR library

We have been focusing on developing an ecosystem for using and programming private information retrieval protocols (PIR). The goal is to usher into the world easy to use and scalable PIR implementations that hopefully other developers can use for their applications.

For us, we will be using PIR for several of our current future projects such as Meson and privacy-preserving light clients. Stay tuned for a separate announcement about this!

Grant announcements

We have received two grants this past year for our privacy research. The first, given by Flashbots, was given for our ongoing work on providing mempool privacy and developing alternatives for using SGX in flashbots. The second, given by the Interchain foundation, was given for our work on integrating IT-PIR protocols into Tendermint for our Katzenmint PKI.

Audit reports for clients

Conducted a security audit on Hakka Finance products' smart contracts, as well as a mathematical analysis on the formulas in the Hakka Finance's iGain whitepaper. Ping Chen, the founder of Hakka Finance, expressed his appreciation for our work in a tweet.

The audit report is publicly viewable on Github: https://github.com/hakkafinance/audit-reports/blob/main/Hakka%20Finance%20Urban%20Giggle%20Audit.pdf

Community

On April 14, Er-Cheng Tang, our Taiwan-based research engineer, gave a 20-minute talk on challenges in Internet anonymity at a Taipei Ethereum event. Watch the recorded presentation on YouTube.

On May 20, research engineer Er-Cheng gave a 30-minute talk, entitled “Interactive Oracle Proof of Proximity for Reed-Solomon Code,” discussing FRI protocol and its proof (Fast Reed-Solomon Interactive Oracle Proofs of Proximity) to an audience at Papers We Love Taipei group's first online event. Event link: https://www.meetup.com/Papers-We-Love-Taipei-Taiwan/events/277916656/

Written by HashCloak Inc

Note that this article was originally posted the now defunct original HashCloak blog on November 15, 2019. Many things have changed since this was written and we will be updating you all soon!

One of the Achille's heels of Ethereum is its lack of privacy guarantees, both on-chain and at the network layer. Although the former has been addressed by a few well-known projects, very little has been focused on the latter. Being able to provide censorship and metadata-resistant network privacy is important for protecting Ethereum users' privacy. This lack of network layer privacy doesn't only affect Ethereum, it affects ALL Ethereum-based chains i.e. forks of Ethereum. In order to address this, we are announcing Meson, a mix network for all Ethereum-based networks.

What is a Mix Network?

A mix network (mixnet for short) is a kind of anonymous communication network that aims to be resistant to traffic analysis and censorship. They are designed to be resistant against a global passive adversary (think 3 letter agencies in your country of choice). A mixnet consists of a series of cryptographic relays that remove unlinkability of sender to receiver of messages through layered encryption and cryptographic shuffling techniques. This means that mixnets provide anonymity for modern, realistic threats. Mixnets were first introduced by David Chaum in 1981 and has inspired the design of many anonymous communication protocols used today.

Meson is built upon the Katzenpost mix network. Katzenpost is a project funded by the EU's Horizon R&D programme. Its development is led by a team of anonymous communications experts. It uses many recently designed constructs such as the Sphinx packet format and uses elements from well-known protocols for its design such as the Loopix Anonymity System and Tor. For an introduction to the Katzenpost mixnet, this video by David Stainton provides a great overview of the system and its tradeoffs.

In particular, providers will run multiple instances of the Meson plugin, configured for as many Ethereum-based chains it wants i.e. for multiple chain IDs. Clients can compose a SPHINX packet that contains a raw Ethereum transaction as its payload. This packet gets sent to the mixnet, to one of the providers running the Meson plugin. The providers then relay this transaction to the Ethereum mainnet (or one of its derived chains). This act removes a user's network interactions with its on-chain interactions. A great compliment to the recent advances to on-chain privacy on Ethereum!

If you want to learn more about mix networks and anonymous communication protocols in general, this talk by Claudia Diaz is a great introduction.

Why a Mix Network? Can't you just use Tor?

Short answer: Yes, you can but ... probably shouldn't! It's complicated! Long answer: Tor is a well-known low-latency anonymous communication network that makes use of onion routing for masking traffic. To access Tor, users usually download the Tor browser and browse the Internet through that. There are 3 main reasons that we'll go into why Tor isn't a good idea for cryptocurrency transactions: its scaling problems, its threat model and the fact that using Tor in non-recommended ways can do more harm than good.

First, scaling in Tor is actually an important issue. Although it has improved tremendously in the past few years, it's still a problem for regular users. One of the main reasons for this is that Tor uses source routing to route messages through its network. This means that at the start of communication, the initiator has to choose the full path to which traffic gets sent. The use of source routing actually makes Tor resistant to failure of routers. However, it does mean that initiators need a complete view of the network at any given time. This translates to users having to periodically download a bunch of router specific information such as the full list of routers, their public keys, etc.

Second, Tor's threat model doesn't handle global passive adversaries. For many users, this may not be of concern. But, as recent news shows, global passive adversaries have been able to figure out a bunch about Tor users' activities through metadata leakage. So, this kind of threat is no longer mythical but indeed realistic.

Lastly, the best way to use and access Tor is through its bundled browser. If you do everything right and given that you have a reasonable threat model, accessing Tor through the Tor browser is pretty safe. The Tor team has done a great job at making Tor usable and accessible through its browser. However, once one leaves this nice sandbox, it's very easy to mess up and undo all this hard work. There have been efforts to make torifying applications easier such as Torsocks, it's still pretty easy to mess this up. One of the main goals of Meson is to make it easy to integrate network-level anonymity in a developer's mixer or wallet app. Having to learn the intricacies of the Tor network increases the burden on the developers. Although, it is noted that one should have a decent understanding on these networks anyway! Moreover, it has been shown that using Tor for cryptocurrency transactions can be bad for the network. Even though that paper specifically talks about Bitcoin, the lessons can apply to many other networks.

Roadmap

Meson is a work-in-progress. The first step towards making Meson a reality is a long-lived testnet. This will help us find what configurations we need for a production ready mixnet and help the Katzenpost team with the development of their software. Other things in our roadmap include: – Different language bindings: Many of the most popular wallets and mixers are written in languages aimed for web and mobile development. If we want Meson to be adopted by all wallets, wallet developers need to be able to plug it into their codebases with ease. – Coordination between various communities that use Ethereum's codebase so that there are multiple providers running the Meson plugin aimed at various chain IDs. – Helping the Katzenpost team with maintenance of the Katzenpost software. – Continuous funding through a payment network (or other decentralized mechanisms) – Contribute to mixnet!

Special thanks to David Staiton for taking the time to help us through Katzenpost and Goncalo Pestana for the helpful discussions and PR reviews!