Encryption with Python

[Kamilche]

I've looked at a few alternatives for encryption with Python, and
didn't come up anything very speedy.

I've written an encryption algorithm in pure Python that can process
22 megs of data a second. I know it's not secure, but it should be
enough to ward off casual hacking. Does someone know of something
speedier?

--Kamilche

[Erik Max Francis]

Kamilche wrote:

I've looked at a few alternatives for encryption with Python, and
didn't come up anything very speedy.

I've written an encryption algorithm in pure Python that can process
22 megs of data a second. I know it's not secure, but it should be
enough to ward off casual hacking. Does someone know of something
speedier?

If you're only concerned with warding off casual hacking, and speed is
your maximal concern, why not just XOR each byte with 0xFF or something
equally brainless?

--
__ Erik Max Francis && ma*@alcyone.com && http://www.alcyone.com/max/
/ \ San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
\__/ Freedom is never voluntarily given by the oppressor.
-- Dr. Martin Luther King, Jr.

[Paul Rubin]

kl*******@home. com (Kamilche) writes:

I've written an encryption algorithm in pure Python that can process
22 megs of data a second. I know it's not secure, but it should be
enough to ward off casual hacking. Does someone know of something
speedier?

Yes, you can just copy the input to the output. That's quite fast,
and it's at least as insecure as your method.

[Peter Hansen]

Kamilche wrote:

I've looked at a few alternatives for encryption with Python, and
didn't come up anything very speedy.

I've written an encryption algorithm in pure Python that can process
22 megs of data a second. I know it's not secure, but it should be
enough to ward off casual hacking. Does someone know of something
speedier?

In addition to Erik and Paul's comments: if you don't specify
what machine you ran your benchmark on, the number "22MB/s" is
completely meaningless...

Besides, what you say is not possible. On my machine,
which is about a P4 2500MHz, scanning an array.array('c' ) with
22MB of data in it, doing nothing but reading each byte and
ignoring it, takes about 8 seconds. So does converting the
array to a list, which is pretty much all C code. Strings
are immutable, so you can't be working with one of them...

Doing anything meaningful with real data, no matter how trivial
the algorithm, would definitely take longer.

-Peter

[Paul Rubin]

Peter Hansen <pe***@engcorp. com> writes:

Besides, what you say is not possible. On my machine,
which is about a P4 2500MHz, scanning an array.array('c' ) with
22MB of data in it, doing nothing but reading each byte and
ignoring it, takes about 8 seconds. So does converting the
array to a list, which is pretty much all C code. Strings
are immutable, so you can't be working with one of them...

Well, you could do 32-bit operations which are maybe 4x faster.
You could maybe get even more speedup using built-in C functions.
For example, you could do rot13 encryption with the string.translat e
method which should be quite fast. FWIW,

http://www.nightsong.com/phr/crypto/p3.py

should be quite secure, and should run at least 1 mbyte/sec on your
p4/2500, maybe quite a bit more.

[Peter Hansen]

Paul Rubin wrote:

Peter Hansen <pe***@engcorp. com> writes:

Besides, what you say is not possible. On my machine,
which is about a P4 2500MHz, scanning an array.array('c' ) with
22MB of data in it, doing nothing but reading each byte and
ignoring it, takes about 8 seconds. So does converting the
array to a list, which is pretty much all C code. Strings
are immutable, so you can't be working with one of them...

Well, you could do 32-bit operations which are maybe 4x faster.
You could maybe get even more speedup using built-in C functions.
For example, you could do rot13 encryption with the string.translat e
method which should be quite fast.

Both are good ideas, but I made an assumption that I was starting
with a simple 22MB string, and the cost of converting that to 32-bit
(presumably using array.array still?) would have to be taken into
account, for fairness. I also assume Kamilche wasn't talking
about using the builtin rot13, since he claimed to have written
this himself...

-Peter

[Larry Bates]

Take a look at pyCrypto. My understanding is that
it provides python wrapper around C crypto functions.
Can't get much faster than that.

http://www.amk.ca/python/code/crypto.html

HTH,
Larry Bates

"Kamilche" <kl*******@home .com> wrote in message
news:88******** *************** ***@posting.goo gle.com...

I've looked at a few alternatives for encryption with Python, and
didn't come up anything very speedy.

I've written an encryption algorithm in pure Python that can process
22 megs of data a second. I know it's not secure, but it should be
enough to ward off casual hacking. Does someone know of something
speedier?

--Kamilche

[Paul Rubin]

Peter Hansen <pe***@engcorp. com> writes:

Both are good ideas, but I made an assumption that I was starting
with a simple 22MB string, and the cost of converting that to 32-bit
(presumably using array.array still?) would have to be taken into
account, for fairness. I also assume Kamilche wasn't talking
about using the builtin rot13, since he claimed to have written
this himself...

There's no special conversion needed, just use array.array('L' , whatever)
instead of array.array('B' , whatever), if I remember right.

[Peter Hansen]

Paul Rubin wrote:

Peter Hansen <pe***@engcorp. com> writes:

the cost of converting that to 32-bit (presumably using array.array still?) ....

There's no special conversion needed, just use array.array('L' , whatever)
instead of array.array('B' , whatever), if I remember right.

Cool! I didn't realize you could initialize effectively any
array object from a string as well as a list. Never too late
to read the docs... :-)

-Peter

[Kamilche]

Peter Hansen <pe***@engcorp. com> wrote in message news:<Td******* *************@p owergate.ca>...

Besides, what you say is not possible. On my machine,
which is about a P4 2500MHz, scanning an array.array('c' ) with
22MB of data in it, doing nothing but reading each byte and
ignoring it, takes about 8 seconds. So does converting the
array to a list, which is pretty much all C code. Strings
are immutable, so you can't be working with one of them...

Doing anything meaningful with real data, no matter how trivial
the algorithm, would definitely take longer.

But I DON'T manipulate the data byte by byte, only the encryption
tables.
Ah, the power of algorithms! ;-)
Take a look at this:

def encrypt(s, offset = 0, _tables = []):
' Encrypt or decrypt a string'
cnt = len(_tables)
if cnt == 0:
# Initialize static variable _tables
# Increase 'cnt' to prevent recurring patterns.
import random
cnt = 10
random.seed(257 )
for i in range(cnt):
marked, table, max = [], [], 256
for j in range(max):
table.append(ch r(j))
marked.append(F alse)
marked[0] = True
marked[255] = True
for j in range(max):
if not marked[j]:
while 1:
c = random.randint( 0, 255)
if marked[c] == False:
table[j], table[c] = table[c], table[j]
marked[c] = True
marked[j] = True
break
_tables.append( ''.join(table))

# Tables initialized - encrypt the data.
return s.translate(_ta bles[offset % cnt])

s = "This is a standard length string to encrypt."
print "\nYou need to specify an offset to avoid patterns."
print "The string is:", s
print "\nEncrypte d with offsets, you get:"
for i in range(5):
print "\t", encrypt(s, i)
print "\nEncrypte d without offsets, you get:"
for i in range(5):
print "\t", encrypt(s)
Most XOR algorithms could benefit from using this technique. There's
never a need to XOR a byte more than once, while building the table.
From then on, it's a simple substitution problem, which the
'translate' function accomplishes quite nicely.