0

Security is irrelevant in my use case. However, a low collision probability is a requirement. By low I mean something comparable to the odds of MD5(textA + keyB) = MD5(textC + keyD) for different texts and keys. Text and key have, say, 16 bytes. The sign + here means concatenation.

I have been using AES for this task, but it is 100x slower than MD5 in my tests shown below. Of course MD5 is irreversible, so I can't use it.

One important point is that it should also be non-commutative, i.e. encrypt(textA, keyB) != encrypt(keyB, textA) otherwise I guess I could just use the XOR bit-wise operation.

Any Python library or code implementing the algorithm is welcome.

AES vs MD5 comparison on Intel i7 8th notebook:

In [287]: %timeit aes(n, n)                                                                                                                                                                   
9.07 µs ± 7.95 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)

In [288]: %timeit md5(n)                                                                                                                                                                      
153 ns ± 0.237 ns per loop (mean ± std. dev. of 7 runs, 10000000 loops each)
dawid
  • 663
  • 6
  • 12
  • It seems very unlikely that AES would run a hundred times slower than MD5. Modern Intel processors have AES encryption functions built in, and can process gigabytes per second. Anyway, if security isn't an issue, why not just use XOR the plaintext with bytes obtained from the output of a PRNG (like [Xorshift](https://en.wikipedia.org/wiki/Xorshift), for example). To decrypt, perform the encryption step again with the same key (i.e. initial seed). – r3mainer Apr 20 '20 at 10:18
  • 60x slower in my use case (see edit). I am using XOR+shift now (to be non-commutative). My doubt is which is the fastest way to put the last bit of the last byte at the begining of the first byte. – dawid Apr 20 '20 at 16:19
  • On my rather old iMac, I can encrypt a 16-byte plaintext with AES in about 800 ns. I suspect you're calling `AES.new()` at every iteration, which is unnecessary and will slow things down a lot. As for Xorshift implementations, I suggest you look around for existing Python code. There's no need to fiddle with separate byte values; Python supports multi-byte integers out of the box. – r3mainer Apr 20 '20 at 22:25
  • I guess I cannot avoid calling new() since key and text change every time. – dawid Apr 21 '20 at 00:34

0 Answers0