Well, I can't say that it's deliberate, but it's definitely some "interesting" choices. A reasonable Salsa20/20 implementation on a modest processor encrypts o

Well, I can't say that it's deliberate, but it's definitely some "interesting" choices. A reasonable Salsa20/20 implementation on a modest processor encrypts on the order of 400MiB/s [0][1]. So that the author went to the trouble of halving the number of rounds and changing the word-size when there are perfectly good and plenty fast off-the-shelf Salsa implementations strikes me as rather strange. Surely this is not the bottleneck on most employee's machines. And then there's the apparently tiny keyspace used. You could argue that this makes the key more "user-friendly" (!), but just a hex representation of a random 256bit key would seem much more natural, and the poor targets are hardly in a position to complain. [0] https://www.cryptopp.com/benchmarks.html https://www.cryptopp.com/benchmarks.html [1] https://cr.yp.to/snuffle.html https://cr.yp.to/snuffle.html