Rivest stresses multiple times that the process he describes is "not encryption" because the cryptographic primitive being used is an authentication one. Theref

Rivest stresses multiple times that the process he describes is "not encryption" because the cryptographic primitive being used is an authentication one. Therefore, he says, his process can be implemented using software that's approved for US export -- this was back when that was a problem, of course. Well, yes, kinda. But: 1. The whole process most certainly is encryption by any reasonable definition, especially if (as he suggests) you do it by authenticating two versions of every bit, only one of which checks out. It's basically an obfuscated version of the following scheme: you take your message, you exclusive-or it with a stream of random-enough bits (the bitstream, or enough information to generate it, is your shared secret key), and then you replace 0 with 01 and 1 with 10. So, as with Rivest's scheme, the ciphertext -- oh, excuse me, the plaintext with added chaff -- is basically an interleaving of the plaintext and its bitwise complement, and you need some secret knowledge to know which bit to use from each pair. 2. Sure, you can implement Rivest's scheme using a cryptographic building block that does something other than encryption. But if you build software that does this then that (see 1 above) is surely encryption software, so (back when Rivest's article was written) you run into the same problems with US export as you were trying to avoid. The Alice/Bob/Charles scenario is bloody clever, though. (And the ability to do this sort of thing, rather than the claim that the process "isn't encryption", is the real point. What Rivest has done is to find a way of decomposing an encryption+decryption process into a small number of parts each of which can somewhat plausibly be claimed not to be for encryption.)