Recent research in 2013 found that protocol morphing is not enough to prevent protocol fingerprinting in practice, only in theory (well , it might be possible in practice, but it is so hard they claim it is pretty much impossible). Keep in mind that this is looking at the technique and attack from a higher level, in which only the protocol used is being attempted to be obfuscated or identified. In some traffic morphing schemes they go to a lower level than this, and try to obfuscate the entire traffic stream (using a cookie cutter template of actual observed traffic, and forcing the new stream into that mold, ie: "This is what traffic from Google looked like, let's make this new traffic stream look exactly like it") instead of the protocol (ie: "This is what the skype protocol looks like, let's try to make our protocol look like this"), and the attackers try to identify the fingerprint of actual specific content (ie: he loaded Google over Tor!) rather than a protocol (He used Tor to load something!). The Parrot Is Dead: Observing Unobservable Network Traffic Of course once you consider bidirectional fingerprinting it becomes more of a challenge. Not only would your entry node need to make the traffic going to you look exactly like traffic from Google, but you would need to make traffic coming from you look exactly like traffic going to Google. It is interesting research for sure, at all levels, and for attacks and defenses, but again it isn't the route I would go. There is no debate in regards to interpacket timing uniformity fixing the problem of interpacket timing watermarks, and no debate in regards to packet/message size uniformity preventing message fingerprinting, so might as well go right to that instead of trying to implement much more complex systems, that in some cases are on uncertain grounding. Also most of the quotes I have given so far are about using these techniques for different reasons. One reason to morph traffic is to hide that it is related to a certain anonymizer, so for example you would morph Tor traffic to make it look like Skype traffic. Another reason to morph traffic is to prevent content fingerprinting attacks, so for example you would make SR traffic look like Google traffic. None of the papers I have read so far mention watermarking attacks directly, but website fingerprinting attacks are close enough to watermarking attacks that I think it is safe to assume morphing traffic would indeed help prevent them (as one of the papers I linked to shows that this is effective to protect from fingerprinting/classifier attacks). Again, interesting stuff, not something I want to spend too many brain cycles on. These problems (watermarking attacks and fingerprinting attacks anyway, not protocol obfuscation that is a current area of research) have all been solved with a simple technique: make everything uniform. If we wanted to have low latency with higher protection than Tor, we might be forced to look into these techniques more. But my goal is not to make a better Tor (which would still probably be broken by strong attackers anyway, since once we fix all of the remaining things that can be fixed we will still be left with all the things that cannot be), my goal is to make a good mixnet (which would stand a chance at preventing strong attackers). I am willing to have high latency in return for being able to use effective techniques to prevent these remaining attacks on systems like Tor, and I would rather spend my brain cycles thinking of ways to prevent the remaining attacks on mix networks that don't already have perfect solutions.