On Sep 20, 3:57 pm, "Matt McCredie" <[EMAIL PROTECTED]> wrote: > On 9/20/07, Python Maniac <[EMAIL PROTECTED]> wrote: > > > I am new to Python however I would like some feedback from those who > > know more about Python than I do at this time. > > Well, you could save some time by not applying the scramble one line > at a time (that is if you don't mind losing the line endings in the > scrambled version). For that to be effective though, you probably want > to open in binary mode. Also, your scramble can be written using list > comprehension. > > [code] > def scramble(s, key=0x80): > return ''.join([chr(ord(c) ^ key) for c in s]) > > output = scramble(f.read()) > [/code] > > If you use xor (^) as above, you can use the same method for scramble > as descramble (running it again with the same key will descramble) and > you can use an arbitrary key. Though, with 255 combinations, it isn't > very strong encryption. > > If you want stronger encryption you can use the following AESish algorithm: > > [code] > import random > def scramble(s, key): > random.seed(key) > return ''.join([chr(ord(c) ^ random.randint(0,255)) for c in s]) > [/code] > > This allows you to use much larger keys, but with a similar effect. > Still not strong enough to be unbreakable, but much better than the > origional. It is strong enough that someone knowing how you scrambled > it will have trouble unscrambling it even if they don't know the key. > > Matt
So far I like what was said in this reply however my ultimate goal is to allow the scramble method to be more than what is shown above. I considered using XOR however XOR only works for the case shown above where the scramble method simply sets or removes the MSB. What I want to be able to do is set or reset the MSB in addition to performing a series of additional steps without negatively impacting performance for the later cases when the MSB is not the only technique being employed. Hopefully this sheds more light on the goal I have in mind. BTW - My original code is able to scramble a 20 MB file in roughly 40 secs using a Dell E6600 2.4 GHz. When I began writing the code for this problem my best runtime was about 65 secs so I know I was heading in the right direction. I was about to begin the process of using the D Language and pyd to gain better performance but then I thought I might also take this opportunity to learn something about Python before delving into D. Obviously I could simply code the whole process using D but that defeats the purpose for using Python in the first place and so I would tend to limit my low-level coding to the task of scrammbling each line of text. The ironic thing about this exorcise was the fact that the optimization techniques that worked for Python caused the Ruby version I coded to decrease performance. It seems Ruby has some definite ideas about what it feels is optimal that it ain't got much to do with what I would consider to be traditional optimization techniques where Ruby is concerned. For instance, Ruby felt the putc method was less optimal than the write method which makes no sense to me but that's life with Ruby. -- http://mail.python.org/mailman/listinfo/python-list
