A poorman's block encryption algorithm
in [Cryptography]
|
From: Phoenix on 11 Mar 2010 17:11 Oops, I haven't read quit well the 1st post. (integers) I am sorry. But I disagree, with you wend x, b, c are reals in (0,1) x_n+1=FRACTIONAL_PART_OFF(x_n(x_n + b_n)+c) is the same as x_n +1=(x_n(x_n + b_n)+c) MOD 1.0 and not power of 2 modulus arithmetic.
From: Maaartin on 11 Mar 2010 19:03 On Mar 11, 9:46 pm, Phoenix <ribeiroa...(a)gmail.com> wrote: > Maaartin wrote > > >There's a problem with polynomials you was already told about: They > >propagate only towards higher bits (unless you use non-power of two > >modulus which is slow).... > > Slow?? > > Try: > > FRACTIONAL_PART_OFF(x(x+b)+c) This is polynomial non-power of two > modulus, in this case is (MOD 1.0) > > And then tell me about speed. I'm quite sure, I din't expressed it very good. What I meant was something like (x(x+b)+c) % 248005243 which is much slower than (x(x+b)+c) # computed modulo 2**32 Fractional part may be relatively fast, but is surely slower than simple integer operation. Integer division is much slower than integer multiplication on "main stream" microprocessors where the multiplication can be really fast (the latency on AMD64 is 3 cycles and it uses DirectPath for register operands). Moreover, 1.0 = pow(2, 0) is power of two, at least for some people. However, if the OP was asking about floating point cipher, I'd first say that this is a very bad idea since it's hardly portable, especially in "the admittedly rather rare but not totally unrealistic scenario where two partners agree on a secret key for block encryption under the circumstance that one of them has to implement the algorithm from scratch."
From: unruh on 11 Mar 2010 19:18 On 2010-03-11, Phoenix <ribeiroalvo(a)gmail.com> wrote: > Oops, > > I haven't read quit well the 1st post. (integers) > I am sorry. > > But I disagree, with you wend x, b, c are reals in (0,1) Reals are not reals. they are stored as integers, and all routines that manipulate them are integer routines. Your polynomials with reals are just polynomials with intergers. On all modern cpus, the reals are also stored as base 2 integers, so your truncations are mod base 2 operations. > > x_n+1=FRACTIONAL_PART_OFF(x_n(x_n + b_n)+c) is the same as x_n > +1=(x_n(x_n + b_n)+c) MOD 1.0 > > and not power of 2 modulus arithmetic. > Sure they are, because no modern machine stores reals as anything but base 2 numbers. If they were real decimal numbers ( as on the old IBM1620 computers) then you would be doing base 10 integer arithmetic with base 10 power moduli. > > > > > > >
From: Mok-Kong Shen on 12 Mar 2010 11:07 rossum wrote: > If you are prepared to move away from block cyphers to a stream cypher > then RC4 is easily memorisable and programmable from memory. It is > not perfectly secure but is certainly easily memorized. If I don't err, stream ciphers have difficulties in issues of authentication. That's why I considered block encryption. (Note in this respect that the scheme depicted allows large block sizes.) Thanks, M. K. Shen
From: Mok-Kong Shen on 12 Mar 2010 12:24
Maaartin wrote: > There's a problem with polynomials you was already told about: They > propagate only towards higher bits (unless you use non-power of two > modulus which is slow). So you can be sure, that a couple of least > significant bits can be found out easily, no matter how many rounds > you do. Starting from them, higher bit can be found, etc. I already > recomennded a remedy, so use it or find another. Extremely sorry for my poor memory. Could you kindly sketch your remedy once again or provide a pointer? Concerning predictability of congruential PRNGs, I previously suggested to use (pseudo-random) cyclic shift of bits in computer words of the output as a counter- measure. That could also be done in the present context. Thanks, M. K. Shen |