Poorly documented - Githubissues

Hello! Thank you for your interest in Dust. It is nice to hear that you love the project. This was my PhD dissertation from 2015 and is no longer actively maintained. However, we are actively developing several projects related to Pluggable Transports. Please check out some of our actively maintained projects and see if they meet your needs:

Shapeshifter Dispatcher Shapeshifter Transports

While Dust is no longer maintained, many of the ideas have been improved upon in our new transport, Replicant. It is available in the Shapeshifter Transports library.

I would like to answer your question about model generation. The model generator code and documentation is in the modelgen directory. If you are interested in generating Dust models, this is the place to start.

I would also like to clarify some misinformation you have about Dust, some of which is presented in this evaluation document you linked.

We submitted a pull request to merge Dust into obfs4proxy (owned by the Tor Project) and it was not merged. We were told at the time that this was because one of our dependency libraries (used for logging) was not available as a Debian package and that we would need to provide a package for this library. We did not pursue this and our pull request was never merged by the maintainer of obfs4proxy. At no time were we told by the Tor Project that our pull request was not merged due to vulnerabilities in Dust. The issue about packaging is mentioned in section 3.3 of the linked evaluation.

The so-called "dead parrot attack" is not an actual attack in the usual sense. It is a theoretical argument that mimicry of existing protocols is never 100% foolproof against analysis by experts. Please read the original paper for more insight on this argument. This argument applies equally to all transports that mimic existing protocols. Dust models are flexible and can either mimic existing protocols or not. If you believe in the dead parrot argument, then you should simply not use a model which mimics an existing protocol. Having this optional capability does not weaken Dust compared to other transports as it simply has a wider range of capabilities than "looks like nothing" transports.

It is incorrect to say that Dust is vulnerable to active probing. It uses a cryptographic protocol which is never similar to ntor, the protocol used by obfs4 and which Dust is compared to in the linked evaluation. What the review states is that Dust, when configured to mimic an existing protocol, may be vulnerable to "dead parrot attacks" deployed in an active probing methodology. This is simply restating the dead parrot argument in a different way. So as above, if you believe in the dead parrot argument, simply use a different Dust configuration.

I would like to make a further point about threat modeling. Dust was developed using a specific threat model developed in my dissertation. The dead parrot argument is not part of that threat model as it is a theoretical argument and my dissertation was based on an empirical methodology. You should always choose a transport which matches your threat model, which likely varies depending on where you are trying to deploy the software. If you are concerned with the dead parrot argument and active probing attacks, then I would recommend the shadow transport, which is a Pluggable Transport wrapper around the Shadowsocks protocol. As it does not mimic existing protocols, the dead parrot argument does not apply. It also has basic protection against active probing. The shadow transport is available in both Shapeshifter Transports and Shapeshifter Dispatcher.

I wish you the best of luck in finding the right transport for your needs!

blanu / Dust

Poorly documented #22