For the inner parts of a cipher (before you get into "modes"), it is guaranteed. A cipher's transformation has to be reversible, otherwise you can't decrypt. I

For the inner parts of a cipher (before you get into "modes"), it is guaranteed. A cipher's transformation has to be reversible, otherwise you can't decrypt. If different inputs produce the same output, then it's not reversible. Block cipher modes like CTR, CBC, etc, are built by combining this basic, reversible building block--a permutation--with additional state. The modes provide additional features, but they necessarily require additional state so that transformations are reversible. Stream ciphers, like RC4, have implicit state, such that to decrypt you have to iterate the function from the beginning state. Modern stream ciphers are built more like CTR-mode block ciphers. You can build reversible transformations from non-reversible functions, such as a one-way hash function, using methods like the Feistel construction (https://en.wikipedia.org/wiki/Feistel_cipher https://en.wikipedia.org/wiki/Feistel_cipher), which was the traditional method for building block ciphers. For my DNS library I used a simple, 16-bit Feistel "cipher" to generate non-repeating QIDs.[1] Most DNS libraries shuffle a 65536-element array (e.g. using a Knuth shuffle), or keep a 65536-bit set to filter values generated by a PRNG. I preferred the cipher approach because the only state necessary was a single integer "key" for each DNS query context, which may need to send a small number of packets to resolve a record. Plus I got to try out a new technique. [1] Non-repeating until you've cycled through all 2^16 values. But even a cryptographically secure permutation becomes increasingly easier to guess the more values you can observe. And of course if you can observe the whole series then you can always guess with 100% accuracy successive values--it just cycles again. For my DNS library I got to generate a new key for every context, which resulted in a new permutation. But for system PIDs it's self-defeating to use a new key to produce a new permutation; the whole point was to avoid having to deal with potential collisions. That's why operating systems like OpenBSD don't bother with this technique for generating random PIDs or ephemeral port numbers.