Re: fast arm9 cipher?



"robertwessel2@xxxxxxxxx" <robertwessel2@xxxxxxxxx> writes:
So any cipher that I use will be too slow.  I'm trying to find the
one that's too slow by the smallest amount.
I agree with Greg - these are then an impossible set of requirements.

I don't think they requirements are impossible, in fact I think they
are completely normal. Saying the cipher is too slow is like saying
your apartment is too small or your salary is too low or that you
don't have enough internet bandwidth at home. It just means that
there's no such thing as "fast enough" and no solution can completely
satisfy your desires, so you so are simply trying to make it as fast
as you can.

What kind of data rate are you talking about? How fast a CPU?

The data rate is whatever I can get through the cipher, preferably 5
MB/sec or better. I believe the cpu is 33 mhz or thereabouts, but I'm
not certain of that.

Conventional C implementations of AES runs less than 1700 clocks/block
(128 bit) on ARM7 and 1400 clocks on ARM9.

That's almost 100 cycles per byte! 10 megabytes would take around 26
seconds, which is basically unusable for this purpose. I think
Salsa20/8 on a fast x86 is around 5 cycles/byte. Anyway, that does
give me an idea of how fast AES is on an ARM, which helps.

10KB/s will take about 1%
of a 100MHz ARM, and anything under 5% increase in response time is
likely to be imperceptible.

The i/o speed is 5-10 MB/sec and the file size is about 10 MB, but the
way the code is presently organized, the I/O is synchronous so the
encryption has to completely finish before transmission starts, which
means the entire encryption time is noticable to the user. It would
help if the operations could be overlapped but 1) this is definitely
not easy and may not be possible; 2) even if accomplished, it still is
a challenge to get the crypto fast enough.

And what is the point of the encryption? How secure does it need to be?

I don't want to describe the application right now, but it's something
pretty cool that I'll announce here if/when I get it to work. As for
security, well, this is sci.crypt and we have standards to maintain
here. But yes, I'm willing to use RC4 or one of the estream ciphers
if it helps.

Thanks.
.



Relevant Pages

  • Re: XOR without repeated key
    ... >>to describe a cipher that was uncrackable he absolutely needs to ... >>Saying that you were babbling is not a personal attack. ...
    (sci.crypt)
  • Re: New lightweight block cipher algorithm
    ... genetic algorithm, then (note that I'm not saying that the OP's ... Not to mention you need a success measurment. ... Find me way to score a possible block cipher ...
    (sci.crypt)