7

Assuming a bit string is deemed cryptographically secure, e.g. PRNG using AES in counter mode, can we equally assume any permutation of said bit string is also cryptographically secure?

In a more practical sense, using a PRNG with AES in counter mode again (for instance), assume it turns out that AES can be more efficiently computed by permutating the input data and rearranging the implementation of the algorithm accordingly. Does the resulting pseudorandom bit string need to be permutated back to the correct order or can I use it directly as a cryptographically secure bitstring? (this is from a purely theoretical pov.)

PS: I used AES as an example, it could be any secure block cipher.

PS2: sorry about the sloppy use of technical terms, but I hope you will understand what I mean.

Thomas
  • 7,478
  • 1
  • 31
  • 44
  • 2
    Any permutation ... is cryptographically secure? NO. A specific permutation is cryptographically secure? Possibly so, but careful evaluation needs to be done. – Dilip Sarwate Mar 12 '12 at 01:03

1 Answers1

9

Yes, an additional bit permutation of pseudo-random data from a secure Pseudo-Random Number Generator is secure, subject to the condition that this bit permutation is independent of the key material of the PRNG and of any data derived from that (including the pseudo-random data).

An argument is that if this permutation is public, the adversary can do/undo it at negligible cost and is back to the original problem of breaking the PRNG (with no usable information, given the sated condition); if this permutation is secret, its addition can only be an additional complexity for the attacker (given the stated condition). That could be formalized.

If the stated condition is not met, a counterexample can often be found. For example, if the permutation is chosen from the output of the original PRNG so as to put all the 0 bits first, then the output is weak. Same if the permutation is part of the key of a cipher, with the cipher ending in that permutation, and the cipher transformed into a PRNG by using counter mode.

fgrieu
  • 140,762
  • 12
  • 307
  • 587
  • 3
    Thanks for the help, I am using a public (constant) permutation to perform some optimizations. For instance, interleaving the input to a Threefish cipher allows the cipher to be completely vectorized, and if I'm using it as a PRNG it means I don't need to spend time reversing the permutation at the end. Thanks! – Thomas Mar 12 '12 at 07:44
  • 1
    FWIW, turns out it can be done with the same amount of permutations while implicitly restoring the correct order at the end anyway. It was a headache combining the different permutation vectors though. And I am not doing that for the 512 and 1024 versions! – Thomas Apr 07 '12 at 14:36
  • +1, but a question: if the run time can be consistently affected like @Thomas describes, could this open side-channel timing attacks that the original implementation is safe from? – orip Aug 27 '12 at 20:06
  • @orip: most implementations of bit permutations (be it in software or hardwired) have no timing dependency on the value of the data bits permuted. Therefore adding a final permutation after something without timing dependency should leave it without timing dependency. The same should hold in practice for REMOVING a final permutation, whenever there exist a simple architecture-independent proof that the original algorithm exhibits no data-dependent timing. – fgrieu Aug 28 '12 at 07:23
  • @fgrieu I was interested in Thomas's experience of affecting (in his case, accelerating) Threefish's performance. Could this expose a timing attack not on the permutation, but on the cipher itself? – orip Aug 28 '12 at 08:47
  • @orip: That's what my previous comment tries to answer. In short: NO, removing a permutation on input or output does not create a timing dependency where there was (cleanly) demonstrably none. – fgrieu Aug 28 '12 at 18:27