Re: Simple transform for improving PN ossification prevention

[Christian Huitema <[e-mail]>]

I am not sure that I understand well the limitations of the shuffle
scheme. I am concerned that it smells like encryption, but can be
trivially broken, and if it is broken we will get ossification.

In my spare time, I have been thinking of similar schemes, but they
start with a big assumption: assume that we can encrypt short numbers.
That is, assume for example that we have a reasonable 32 bit encryption
code. I understand that the current such codes are a bit limited, and
that IPCrypt in particular may not be safe, but bear with me please
because of two reasons:

1) With 32 bit numbers, the number of permutations of a set of 2^32
values is much larger than 2**256. It is thus plausible that we can
design a symmetric encryption scheme keyed with a 256 bit or 128 bit key.

2) Designing encryption schemes is hard, but I assume that
cryptographers can come with plausible schemes if we ask them,
especially if we do not insist too much on performance. For example,
given a 32 bit permutation, repeat in a loop "XOR with 32-bit word index
I mod N of Key, then apply permutation" enough times and you get a
pretty reasonable scheme. (IPCrypt had just 3 passes of the loop and a
final XOR; that seemed a bit optimistic; more passes would be harder to
crack; my vote would be for at least 8; it would be more than twice
slower but who really cares?)

The big issue is that the same sequence of PN would repeat after 2*32
packets, but there is an obvious fix to that: rekey after at most 2**31
packets. Bingo, we get people to actually implement key rotation...

The other downside is that packets would be encoded on 4 bytes all the
time. But that might be an OK price for those who really want hardware
acceleration.

-- Christian Huitema