On Thu, Jul 30, 2009 at 09:11:42AM -0500, Wayne wrote: > If you're only partially concerned (i.e. don't care about 'real' encryption) > you can use some of the string library encryptions.
Please don't get used to calling these "encryption". They have nothing at all to do with encrypting data. (Well, ROT13 does, I suppose, but not seriously). They are for "encoding" which is simply representing data in a different FORMAT. They do not encrypt data. Yes, people have actually tried "encrypting" passwords sent between browsers and web apps using base64 and suchlike. BIG mistake. You do say that somewhat, but I think using the word "encryption" or implying that these represent a casual level of encryption, is just leading to trouble. These are things a lot of people can decode in their heads. Libraries like the Python Cryptography Toolkit provide real encryption very easily if you need encryption. > Of course any of these methods presume you're just trying to keep the casual > snoop from getting access to your data. Anyone with time/inclination/tools > can go ahead and break most encryptions. In one line of code, you can convert a string to base64 or hex and get a string that would take anyone caring to about 2 seconds to reverse, using tools as simple as most text editors, python itself, or for that matter some network monitoring programs which might pick up that data in flight would just automatically decode that for you. However, in only another line or so of code, you can encrypt your data using AES or Blowfish or whatever, which would require highly specialized tools, extremely expensive equipment, and if you were not either a major government, independently wealthy and very motivated to get that data, it's not going to be broken. -- Steve Willoughby | Using billion-dollar satellites st...@alchemy.com | to hunt for Tupperware. _______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor