Re: Best Encryption for Python Client/Server
Ed Hotchkiss wrote: No worries, I apologize for my outburst. I will check out the viability of using an SSH module, or using pyCrypto or something to encrypt the data. Please don't apologise. It's one of c.l.py's charms that an exchange such as the one you had with Robert Kern results in a perfectly equable exchange of views rather than an escalatory flame war of the fuck off and die nature. Please excuse my language, I've been reading too much Xah Lee lately. Here's my mission: simple P2P class with encryption of whatever type of file is being sent, and authentication via encrypted user name/password. So any type of file or login being sent over the net, any communication between the scripts should be encrypted, regardless of whether it is client/server communication, or file transfer. Robert's suggestion was a good one, as ssh (rather than SSH) is very good at building encrypted tunnels between arbitrary processes. Now that I've finally stated what I want to do (sorry) Is SSH a good option, or just using sockets with pycrypto? Thanks in advance. I think I'd rather use the already-engineered ssh solution, relying as it does on well-thought-out asymmetric encryption. You might want to look at http://www.ssh.com/support/documentation/online/ssh/winhelp/32/Tunneling_Explained.html regards Steve [or possibly http://www.googleityoumoron.com/?go=holden+python] -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.pycon.org -- http://mail.python.org/mailman/listinfo/python-list
Re: Best Encryption for Python Client/Server
Steve Holden [EMAIL PROTECTED] writes: Here's my mission: simple P2P class with encryption of whatever type of file is being sent, and authentication via encrypted user name/password. So any type of file or login being sent over the net, any communication between the scripts should be encrypted, regardless of whether it is client/server communication, or file transfer. Robert's suggestion was a good one, as ssh (rather than SSH) is very good at building encrypted tunnels between arbitrary processes. If you want to use SSL in a similar fashion, try stunnel (http://www.stunnel.org). Frankly I've never understood why ssh even exists, but it's very widespread by now, and works pretty well within its limitations. -- http://mail.python.org/mailman/listinfo/python-list
Re: Best Encryption for Python Client/Server
hah :P awesome, I will be busy this week! -edward On 20 Sep 2005 14:23:10 -0700, Paul Rubin http://phr.cx@nospam.invalid wrote: Steve Holden [EMAIL PROTECTED] writes: Here's my mission: simple P2P class with encryption of whatever type of file is being sent, and authentication via encrypted user name/password. So any type of file or login being sent over the net, any communication between the scripts should be encrypted, regardless of whether it is client/server communication, or file transfer. Robert's suggestion was a good one, as ssh (rather than SSH) is very good at building encrypted tunnels between arbitrary processes. If you want to use SSL in a similar fashion, try stunnel(http://www.stunnel.org).Frankly I've never understood why ssh evenexists, but it's very widespread by now, and works pretty well within its limitations.--http://mail.python.org/mailman/listinfo/python-list-- edward hotchkiss -- http://mail.python.org/mailman/listinfo/python-list
Re: Best Encryption for Python Client/Server
SSH can be used for functionality like this, through tunneling. You can even tunnel interprocess communication through SSH. Its not exceptionally complicated. On Sunday 18 September 2005 13:36, Ed Hotchkiss wrote: Let us say that I am trying to create a very small and simple private network/connection between several scripts on different machines, to communicate instructions/data/files etc. to each other over the net. Is SSL the best method? Any recommendations of something to get started with? Thanks in advance. -- James Stroud UCLA-DOE Institute for Genomics and Proteomics Box 951570 Los Angeles, CA 90095 http://www.jamesstroud.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Best Encryption for Python Client/Server
Is SSL something which needs a script to register (and pay for) a certificate, or is it just another form of encryption ... also - is there a free implementation of OpenSSL for windows, and is openSSL a default application with *NIX? Thanks. On 9/19/05, James Stroud [EMAIL PROTECTED] wrote: SSH can be used for functionality like this, through tunneling. You can eventunnel interprocess communication through SSH. Its not exceptionally complicated.On Sunday 18 September 2005 13:36, Ed Hotchkiss wrote: Let us say that I am trying to create a very small and simple private network/connection between several scripts on different machines, to communicate instructions/data/files etc. to each other over the net. Is SSL the best method? Any recommendations of something to get started with? Thanks in advance.--James StroudUCLA-DOE Institute for Genomics and Proteomics Box 951570Los Angeles, CA 90095http://www.jamesstroud.com/--http://mail.python.org/mailman/listinfo/python-list -- edward hotchkiss -- http://mail.python.org/mailman/listinfo/python-list
Re: Best Encryption for Python Client/Server
Ed Hotchkiss wrote: Is SSL something which needs a script to register (and pay for) a certificate, or is it just another form of encryption ... also - is there a free implementation of OpenSSL for windows, and is openSSL a default application with *NIX? Thanks. It's SS*H*, and you're perfectly capable of using Google to find out most of this information once you get the spelling right. As for the last question (the one least amenable to direct Googling), any reasonably maintained UNIX machine today will be running SSH. It's really the only thing out there for secure remote logins. When you've done the requisite background reading and have a Python question to ask again, then come back and ask more targetted questions. On 9/19/05, *James Stroud* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: SSH can be used for functionality like this, through tunneling. You can even tunnel interprocess communication through SSH. Its not exceptionally complicated. -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter -- http://mail.python.org/mailman/listinfo/python-list
Re: Best Encryption for Python Client/Server
Ed Hotchkiss wrote: I apologize for misreading your H my dear professor. Perhaps you can google:asshole and see if your image is present, I would highly doubt that it is not within the first page of results. I'm sorry that I did not see the message in the thread which recommended SSH rather than SSL. There is no need to be a dick. It was the message you responded to. I only emphasized the H because it seemed that you read the message and missed that James wasn't talking about SSL. The suggestion to look at Google first was intended to be helpful rather than a rebuke. That's why I actually answered the part of the question that I thought wouldn't be easy find with Google. It's reasonably standard to expect people to try to find information (particularly off-topic information) for themselves before coming to the group for help. It's a lot more efficient for you and gets you a much more thorough answer. I apologize for appearing to be a dick. If I wanted to be a dick, I'd have just sent you to http://www.googleityoumoron.com and not answered any part of your question. - Luckily you were never my professor Indeed. As I am a grad student, that would have been most embarassing. And I do *not* recommend Googling asshole without SafeSearch on. *shudder* -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter -- http://mail.python.org/mailman/listinfo/python-list
Re: Best Encryption for Python Client/Server
No worries,I apologize for my outburst. I will check out the viability of using an SSH module, or using pyCrypto or something to encrypt the data. Here's my mission: simple P2P class with encryption of whatever type of file is being sent, and authentication via encrypted user name/password. So any type of file or login being sent over the net,any communication between the scripts should be encrypted, regardless of whether it is client/server communication, or file transfer. Now that I've finally stated what I want to do (sorry) Is SSH a good option, or just using sockets with pycrypto?Thanks in advance. -edward -- http://mail.python.org/mailman/listinfo/python-list
Best Encryption for Python Client/Server
Let us say that I am trying to create a very small and simple private network/connection between several scripts on different machines, to communicate instructions/data/files etc. to each other over the net. Is SSL the best method? Any recommendations of something to get started with? Thanks in advance. -- Edward hotchkiss -- http://mail.python.org/mailman/listinfo/python-list
Best Encryption for Python Client/Server
Let us say that I am trying to create a very small and simple private network/connection between several scripts on different machines, to communicate instructions/data/files etc. to each other over the net. Is SSL the best method? Any recommendations of something to get started with? Thanks in advance. -- edward hotchkiss -- http://mail.python.org/mailman/listinfo/python-list
Re: encryption with python?
I've successfully used this toolkit to implement AES encryption in a recent project. http://www.amk.ca/python/code/crypto -Larry Bates Robert Kern wrote: Ed Hotchkiss wrote: What's the best module for encryption with python, anyone out there using python and encryption together? It depends on what your needs are. What do you need to accomplish? -- http://mail.python.org/mailman/listinfo/python-list
Re: encryption with python?
Robert Kern [EMAIL PROTECTED] writes: http://www.nightsong.com/phr/crypto/p3.py [Ed Hotchkiss wrote:] Awesome. I just started Python today so I'd have no idea ... how good is this encryption compared to PGP? p3.py's functionality is nothing like PGP: it just encrypts character strings with a secret key. It has no public key encryption, no key management, etc. Also, its algorithm is nonstandard since it's designed for fast encryption speed using only the Python standard library, since some applications run in environments where they don't have enough control to use C extensions, yet they still have reasons to want to encrypt stuff. If you're doing a high security application, you need control over your computing environment (enough to be able to run C extensions, etc.) and not just your algorithms, and so you should use a C extensions that follows a standard like AES. You also reduce your legal liability exposure by following standards. Imagine you choose some algorithm and it gets broken and you have to explain to a jury why your software lost megabucks of your clients' money, or whatever. If you chose 3DES or AES, you can say you followed the best advice of both the federal government and the banking industry. If you chose anything else, you're in deep mazola. So even if you somehow calculate that p3.py has .002% chance of getting broken and AES-EAX has .003% chance, the objectively worse choice of AES is still preferable in that kind of application since you could still get unlucky either way. That said, the algorithm in p3.py should be reasonably sound for most typical purposes. Also, its API is extremely simple. It's harder to mess up with it than with a typical crypto library that gives you lower level building blocks. The main cost of that ease of use is that the ciphertext is several dozen bytes longer than the plaintext. That said, it's Paul's own algorithm, so it hasn't been tested and attacked as thoroughly as PGP's algorithms. It relies on the security of the underlying hash. Unfortunately, that hash has been broken recently, although I'm not sure if that break actually affects the security of how it's used in this algorithm. Paul could tell you more. I think that attack (an O(2**63) method for finding free collisions in SHA1) doesn't apply here, since the attacker doesn't have control over the input to the hash function. -- http://mail.python.org/mailman/listinfo/python-list
encryption with python?
What's the best module for encryption with python, anyone out there using python and encryption together?-- edward hotchkiss -- http://mail.python.org/mailman/listinfo/python-list
Re: encryption with python?
Awesome. I just started Python today so I'd have no idea ... how good is this encryption compared to PGP? Any info on using this file? Didn't see any on this guys site ... On 9/16/05, Robert Kern [EMAIL PROTECTED] wrote: Ed Hotchkiss wrote: Gmail was just an example, I just wanted to learn to play with it ... I mean the thrill of seeing a file that MY script encrypted hehe... Again, keep it on the list, not private email, please.Probably the simplest encryption module would be Paul Rubin's p3.py . Itonly requires the standard library. http://www.nightsong.com/phr/crypto/p3.py--Robert Kern[EMAIL PROTECTED]In the fields of hell where the grass grows highAre the graves of dreams allowed to die. -- Richard Harter-- edward hotchkiss -- http://mail.python.org/mailman/listinfo/python-list
Re: encryption with python
Thank you to Mike Meyer, Kirk Sluder, and anyone who made constructive comments and/or corrections to my earlier post about generating student IDs as random numbers. Especially thanks to Marc Rintsch who corrected a stupid coding mistake I made. Serves me right for not testing the code. Kirk pointed out that there is a good usage case for using a one-way encryption function to encrypt a Social Security Number to the student ID: you are prepared to deal with the inevetable, I lost my password/student ID, can you still look up my records? Whether the usefulness of that use outweighs the risks is not something we can decide, but I hope the original poster is considering these issues and not just blindly going for the technical solution. For example, this is one possible way of dealing with students who have lost their student ID: - ask student for their name, d.o.b. and SSN; - search the database for students whose name, d.o.b. and SSN match; - if you have more than one match, there is a serious problem; - otherwise you may consider that the student has proven their own identity to you sufficiently, so you can safely tell them the student ID. No need for a function that calculates the ID from the SSN, with the associated risk that Black Hats will break the algorithm and use the student ID to steal students' SSNs. In effect, this scheme uses the algorithm look it up in a secure database as the one-way function. It is guaranteed to be mathematically secure, although it is vulnerable to bad guys cracking into the database. Thanks also to James Stroud for his amusing extension to the one-time pad algorithm. If you have a need to be able to reconstruct the data, then of course you need some sort of cryptographic function that can encrypt the data and decrypt it. But that begs the question of whether or not you actually do need to be able to reconstruct the data. The point of my post was that you may not need to, in which case a random number is as good as any other ID. James also protested that passwords are security through obscurity, since All they have to do is to get that secret key and all those records are easily readable. Of course this is technically correct, but that's not what security through obscurity means to folks in the security business. The difference between security through obscurity and security through a secret key is profound: if I reverse-engineer your secret algorithm, I can read every record you have. But if I discover the secret key belonging to one person, I can only read that person's messages, not anyone else's. As James says, The point is that *something has to be kept secret* for encryption security to work. Absolutely correct. But now think of the difference between having keys to your door locks, compared to merely keeping the principle of the door handle secret. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: encryption with python
Kirk Job Sluder wrote: Ron Adam [EMAIL PROTECTED] writes: I would think that any n digit random number not already in the data base would work for an id along with a randomly generated password that the student can change if they want. The service provider has full access to the data with their own set of id's and passwords, so in the case of a lost id, they can just look it up using the customers name and/or ssn, or whatever they decide is appropriate. In the case of a lost password, they can reset it and get another randomly generated password. Or am I missing something? Not really. My suggestion is that in many cases, if the data is being used only as a backup password or authentication token, there is no need for that data to be stored in plaintext. For example, with the ubiquitous mother's maiden name * there is frequently no need to actually have Smith, Jones, or Gunderson in the database. bf65d781795bb91ee731d25f9a68a5aeb7172bc7 serves the same purpose. For that matter if the encrypted data is used a the key, then there is no need to store the data period. OH... lets see, we'll just store the password, and give them the data instead. Never mind it's a few thousand characters or more. ;-) Oh, and don't loose your account number BTW. There are other cases where one-way anonymity is better than a table linking people to randomly generated userIDs. I'd rather use cryptographic hashes for research databases than keep a table matching people to random numbers hanging around. But I'm weird that way. Why would you need a table hanging around? Most databases today are relational, so they are made up of lots of linked tables of records and fields. And each user, can have access to some parts without having access to other parts. So couldn't you create a separate account to access, names and id numbers only? Cheers, Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: encryption with python
Steven D'Aprano [EMAIL PROTECTED] writes: On Wed, 07 Sep 2005 14:31:03 -0700, jlocc wrote: Basically I will like to combine a social security number (9 digits) and a birth date (8 digits, could be padded to be 9) and obtain a new 'student number'. It would be better if the original numbers can't be traced back, they will be kept in a database anyways. Hope this is a bit more specific, thanks!!! There are one-way encryption functions where the result can't easily be traced back to the input, but why do you need the input anyway? Well, there is a form of security design that involves one-way encryption of confidential information. You might want to be able to search on SSN, but not have the actual SSN stored in the database. So, you are prepared to deal with the inevetable, I lost my password/student ID, can you still look up my records? Don't think it applies in this case, but might in some other cases. -- Steven. -- Kirk Job-Sluder The square-jawed homunculi of Tommy Hilfinger ads make every day an existential holocaust. --Scary Go Round -- http://mail.python.org/mailman/listinfo/python-list
Re: encryption with python
Paul Rubin http://[EMAIL PROTECTED] writes: Kirk Job Sluder [EMAIL PROTECTED] writes: Well, there is a form of security design that involves one-way encryption of confidential information. You might want to be able to search on SSN, but not have the actual SSN stored in the database. So, you are prepared to deal with the inevetable, I lost my password/student ID, can you still look up my records? The minute you provide a way to do that without secret keys, you have a security hole. Providing any kind of access to data involves creating a security hole. This is the biggest flaw in most discussions of computer security. Too much of it depends on everyone remembering (and using) unique cryptographically strong keys. You have a client on the phone who needs access to information, but has forgotten or lost the 10-digit unique ID and the PIN you gave them two years ago. How do you provide that client with the information he or she needs? This is the kind of dilemma that one-way encryption is designed to make a tiny bit safer. SSNs + some other secret (such as mother's maiden name) is certainly crappy security. However, I don't think we are going to see widespread adoption of anything better in the near future. But even if we go with more secure authentication tokens, there is usually no reason to store the authentication token in plaintext. SSN's are 9 digits which means there are 1 billion of them. If there are 100,000 hashed SSN's in the database, the attacker (since this is clpy) can read them all into a Python dict. S/he then starts generating SSN's at random and hashing them and checking whether those hashes appear in the dict. Doing stuff like iterated hashes to slow the attacker down doesn't help that much: the attacker needs to hash only 10,000 or so SSN's to be likely to hit one that's in the dict. If the attacker can hash all 10**9 SSN's, which isn't all that terribly many, every SSN in the database spills. Of course, an additional step I didn't mention was that in actual practice the SSNs would be hashed with a strong random secret key. But from my point of view, the possibility for dictionary attacks is pretty much unavoidable as long as we are dealing just with memorized tokens. We've been bitching, whining and moaning about the small keyspace and poor quality of what users are willing to memorize for 20 years. We can complain about it for the next 10 which is about how long it will take for any kind of alternative to be adopted. I still think that one-way hashing of authentication secrets is better than plain-text storage. Bottom line: to keep confidential stuff secure, you need actual security. The only way to keep confidential stuff secure is to shred it, burn it, and grind the ashes. I think the fundamental problem is that that most customers don't want actual security. They want to be able to get their information by calling a phone number and saying a few words/phrases they memorized in childhood. Given the current market, it seems to be cheaper to deal with breaks after the fact than to expect more from customers. -- Kirk Job-Sluder The square-jawed homunculi of Tommy Hilfinger ads make every day an existential holocaust. --Scary Go Round -- http://mail.python.org/mailman/listinfo/python-list
Re: encryption with python
Kirk Job Sluder [EMAIL PROTECTED] writes: You have a client on the phone who needs access to information, but has forgotten or lost the 10-digit unique ID and the PIN you gave them two years ago. How do you provide that client with the information he or she needs? This is the kind of dilemma that one-way encryption is designed to make a tiny bit safer. You need secret keys then, and you need to secure them. If you have a secure secret key K, you can store something like HMAC(K, SSN) and that is pretty safe from offline attacks. Of course, an additional step I didn't mention was that in actual practice the SSNs would be hashed with a strong random secret key. But now you have to maintain that secret key and its secrecy, which is not a trivial task. It's not an unsolveable problem but you can't handwave it. We're told there is already a secure database in the picture somewhere, or at least one that unescapeably contains cleartext SSN's, so that's the system that should assign the ID numbers and handle SSN-based queries. I think the fundamental problem is that that most customers don't want actual security. They want to be able to get their information by calling a phone number and saying a few words/phrases they memorized in childhood. A voice exemplar stored at enrollment time plus a question or two like what classes did you take last term could easily give a pretty good clue that the person saying the words/phrases is the legitimate student. Given the current market, it seems to be cheaper to deal with breaks after the fact than to expect more from customers. Customers legitimately want actual security without having to care how hash functions work, just like they want safe transportation without having to care about how jet engine turbopumps work. Air travel is pretty safe because if the airline fails to maintain the turbopumps and a plane goes down, there is hell to pay. There is huge legal and financial incentive for travel vendors (airlines) to not cut corners with airplane safety. But vendors who deploy incompetently designed IT systems full of confidential data resulting in massive privacy breaches face no liability at all. There is no financial incentive for them to do it right, so they instead spend the money on more marketing or on executive massages or whatever, and supply lousy security. THAT is the fundamental problem. -- http://mail.python.org/mailman/listinfo/python-list
Re: encryption with python
Paul Rubin http://[EMAIL PROTECTED] writes: Kirk Job Sluder [EMAIL PROTECTED] writes: We're told there is already a secure database in the picture somewhere, or at least one that unescapeably contains cleartext SSN's, so that's the system that should assign the ID numbers and handle SSN-based queries. Well, IMO just having cleartext SSNs is questionable practice unless you need those SSNs to report to some other agency that takes SSNs. And even so, you might want to limit access to plaintext SSNs to a limited group, and give access to the hashed SSNs as a search key to a different group. I think the fundamental problem is that that most customers don't want actual security. They want to be able to get their information by calling a phone number and saying a few words/phrases they memorized in childhood. A voice exemplar stored at enrollment time plus a question or two like what classes did you take last term could easily give a pretty good clue that the person saying the words/phrases is the legitimate student. In my experience the typical student has trouble remembering what happened last week, much less last term. In addition, universities frequently need to field questions from people who were students years ago. Are voice exemplars at that stage yet? Customers legitimately want actual security without having to care how hash functions work, just like they want safe transportation without having to care about how jet engine turbopumps work. Air travel is pretty safe because if the airline fails to maintain the turbopumps and a plane goes down, there is hell to pay. There is huge legal and financial incentive for travel vendors (airlines) to not cut corners with airplane safety. But vendors who deploy incompetently designed IT systems full of confidential data resulting in massive privacy breaches face no liability at all. I'm more than happy to agree to disagree on this, but I see it differently. In aviation there certainly is a bit of risk-benefit analysis going on in thinking about whether the cost of a given safety is justified given the benefits in risk reduction. Likewise, credit companies are currently making money hand-over-fist. If an identity is compromised, it's cheaper for them to just close the account, refund the money, and do their own fraud investigation after the fact. Meanwhile, for every person who gets stung, there are a hundred wanting convenience. In addition, the losses due to bad cryptographic implementation appear to be trivial compared to the losses due to social engineering. -- Kirk Job-Sluder The square-jawed homunculi of Tommy Hilfinger ads make every day an existential holocaust. --Scary Go Round -- http://mail.python.org/mailman/listinfo/python-list
Re: encryption with python
Kirk Job Sluder wrote: Paul Rubin http://[EMAIL PROTECTED] writes: Kirk Job Sluder [EMAIL PROTECTED] writes: We're told there is already a secure database in the picture somewhere, or at least one that unescapeably contains cleartext SSN's, so that's the system that should assign the ID numbers and handle SSN-based queries. Well, IMO just having cleartext SSNs is questionable practice unless you need those SSNs to report to some other agency that takes SSNs. Colleges generally do have such needs. -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter -- http://mail.python.org/mailman/listinfo/python-list
Re: encryption with python
On Saturday 10 September 2005 14:01, Kirk Job Sluder wrote: Providing any kind of access to data involves creating a security hole. This is the biggest flaw in most discussions of computer security. On 9/9/05 Steven D'Aprano wrote: There are one-way encryption functions where the result can't easily be traced back to the input, but why do you need the input anyway? Here is my quick-and-dirty student ID algorithm: I have invented the perfect security protocol that solves a major problem with the one-time-pad. The problem with most one-time-pad protocols is that you still need to have the pad around, creating a major security hole. I have solved that problem here. It has all of the steps of the usual one-time-pad plus an extra step. 1. Generate a random number the size of your data. 2. XOR your data with it. 3. Destroy the original data. Here is the additional step: 4. Destroy the random number. You can see now that no adversary can resonably reconstruct the plain text. This protocol might be terribly inconvenient, though, because it makes the origina data unaccessible. Oh well, just a necessary byproduct of theoritcally perfect security. I hereby place this algorithm in the public domain. Use it freely. James -- James Stroud UCLA-DOE Institute for Genomics and Proteomics Box 951570 Los Angeles, CA 90095 http://www.jamesstroud.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: encryption with python
Kirk Job Sluder [EMAIL PROTECTED] writes: I'm more than happy to agree to disagree on this, but I see it differently. In aviation there certainly is a bit of risk-benefit analysis going on in thinking about whether the cost of a given safety is justified given the benefits in risk reduction. Likewise, credit companies are currently making money hand-over-fist. If an identity is compromised, it's cheaper for them to just close the account, refund the money, and do their own fraud investigation after the fact. You don't get it. Refunding the money improperly charged on a single card doesn't begin to compensate for the hassle of undoing an identity theft. If airlines worked the way you're suggesting the credit industry should work, and a plane went down, the airline would be off the hook by refunding your estate the price of your ticket. It's only because they face much further-reaching liability than that, that they pay so much attention to safety. -- http://mail.python.org/mailman/listinfo/python-list
Re: encryption with python
Kirk Job Sluder wrote: The only way to keep confidential stuff secure is to shred it, burn it, and grind the ashes. I think the fundamental problem is that that most customers don't want actual security. They want to be able to get their information by calling a phone number and saying a few words/phrases they memorized in childhood. Given the current market, it seems to be cheaper to deal with breaks after the fact than to expect more from customers. Security = Privacy in this context, and most customers do want privacy. But also in this case, you are referring to two party security situations, where the data is shared between a service provider and a service consumer. I would think that any n digit random number not already in the data base would work for an id along with a randomly generated password that the student can change if they want. The service provider has full access to the data with their own set of id's and passwords, so in the case of a lost id, they can just look it up using the customers name and/or ssn, or whatever they decide is appropriate. In the case of a lost password, they can reset it and get another randomly generated password. Or am I missing something? Cheers, Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: encryption with python
In [EMAIL PROTECTED], Steven D'Aprano wrote: last_number_used = 12345 usable_IDs = [] def make_studentID(): global last_number_used global usable_IDs if not usable_IDs: # generate another batch of IDs in random order usable_IDs = range(last_number_used, last_number_used + 1000) - usable_IDs.sort(random.random()) + random.shuffle(usable_IDs) last_number_used += 1000 return usable_IDs.pop() Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: encryption with python
On Saturday 10 September 2005 15:02, Ron Adam wrote: Kirk Job Sluder wrote: I would think that any n digit random number not already in the data base would work for an id along with a randomly generated password that the student can change if they want. The service provider has full access to the data with their own set of id's and passwords, so in the case of a lost id, they can just look it up using the customers name and/or ssn, or whatever they decide is appropriate. In the case of a lost password, they can reset it and get another randomly generated password. Or am I missing something? Yes and no. Yes, you are theoretically correct. No, I don't think you have the OP's original needs in mind (though I am mostly guessing here). The OP was obviously a TA who needed to assign students a number so that they could anonymously check their publicly posted grades and also so that he could do some internal record keeping. But, I'm thinking no one remembers college here anymore. When I was in college (and when I TA'd) security was kind of flimsy. TAs kept all records of SS#s, etc. (etc. includes birthdays here) in a gradebook (or the rich ones kept them on a 5 1/4 floppy). Grades were reported publicly by full SS#s, usually on a centralized cork-board. That was back in the good-ole-days, before financial fraud was euphemised to identity theft. When I TA'd several years later, grades were reported by the last n digits of the SS#. Some very security conscious TAs--or was it just me? I think it was just me--solicited pass phrases from each student and grades were reported based on the student generated pass phrase--and not on SS# or the like. These phrases usually came in the form of Buffs1 or Kitty1979 (the latter possibly revealing some information about a birthday, perhaps?). Some students didn't submit pass phrases, for whatever reason. I think I did the less convenient of the two most reasonable options, which was to withold reporting the grade to the student until they gave me a phrase. The other option was to use a default pass phrase of the last n digits of the SS#. The idea of combining ID information and encrypting it to create another ID is a quantum leap beyond the primitive last n digits of the SS#. Does it beat, in theoretical terms, assigning random numbers? No. And it certainly doesn't beat, in theoretical terms, my improved one-time-pad protocol (see my previous email). I challenge even the most capable cryptographer to beat my improved one-time-pad protocol for security (Oh wait, here it is: 1. Destroy Data.) But it is convenient, especially if you discard the original identifying information and store just the hashes. And as far as collisions go, even if a class of 10,000 gives a 1% chance of collision, who is going to TA a class of 10,000 students. If you can promise that kind of enrolment for any department, much less any single class, there is a job in an Economics department waiting for you out there, my friend. So what would be the alternative to ID information generated IDs? Have a 3xDES encrypted database with the SS# and birthday stored as plain-text? Better keep the encryption protocol secret! Oops. Screwed up already. I figured out the encryption protocol: Encrypt database with 3xDES using a secret key. Dang, security through obscurity. All they have to do is to get that secret key and all those records are easily readable. The point is that *something has to be kept secret* for encryption security to work. Theoretically best would be a passphrase, or a passphrase to a really big key. So, perhaps we could modify the algorithm from a few messages back, in order to address the (assumed) *practical* considerations of the OP's original query: import sha def encrypt(x,y, password): def _dosha(v): return sha.new(str(v)+str(password)).hexdigest() return int(_dosha(_dosha(x)+_dosha(y))[5:13],16) So now what is the criticism? That its still a secret algorithm because the password is secret? James -- James Stroud UCLA-DOE Institute for Genomics and Proteomics Box 951570 Los Angeles, CA 90095 http://www.jamesstroud.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: encryption with python
James Stroud [EMAIL PROTECTED] writes: Yes and no. Yes, you are theoretically correct. No, I don't think you have the OP's original needs in mind (though I am mostly guessing here). The OP was obviously a TA who needed to assign students a number so that they could anonymously check their publicly posted grades and also so that he could do some internal record keeping. If that's all it's about, it's not a big deal. If it's for some central administrative database that's more of a target, more care is warranted. The idea of combining ID information and encrypting it to create The info to be combined was the student's birthdate. Why would the TA have access to either that or the SSN? import sha def encrypt(x,y, password): def _dosha(v): return sha.new(str(v)+str(password)).hexdigest() return int(_dosha(_dosha(x)+_dosha(y))[5:13],16) So now what is the criticism? That its still a secret algorithm because the password is secret? That's sort of reasonable as long as the password really is secret and you don't mind a small chance of two students getting the same ID number once in a while. If the password is something that a TA types into a laptop when entering grades and which goes away after the course ends, it's not such a big deal. If it's a long-term key that has to stay resident in a 24/7 server through the students' entire time at the university and beyond, then the algorithm is the trivial part and keeping the key secret is a specialized problem in its own right. For example, financial institutions use special, tamper resistant hardware modules for the purpose. Could the OP please say what the exact application is? That might get more useful responses if the question still matters. -- http://mail.python.org/mailman/listinfo/python-list
Re: encryption with python
On Saturday 10 September 2005 16:30, Paul Rubin wrote: The info to be combined was the student's birthdate. Why would the TA have access to either that or the SSN? Speaking as a former TA, we had all that and a little more, if I remember correctly. The why aspect is a little beyond me. James -- James Stroud UCLA-DOE Institute for Genomics and Proteomics Box 951570 Los Angeles, CA 90095 http://www.jamesstroud.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: encryption with python
James Stroud wrote: On Saturday 10 September 2005 15:02, Ron Adam wrote: Kirk Job Sluder wrote: I would think that any n digit random number not already in the data base would work for an id along with a randomly generated password that the student can change if they want. The service provider has full access to the data with their own set of id's and passwords, so in the case of a lost id, they can just look it up using the customers name and/or ssn, or whatever they decide is appropriate. In the case of a lost password, they can reset it and get another randomly generated password. Or am I missing something? Yes and no. Yes, you are theoretically correct. No, I don't think you have the OP's original needs in mind (though I am mostly guessing here). The OP was obviously a TA who needed to assign students a number so that they could anonymously check their publicly posted grades and also so that he could do some internal record keeping. But, I'm thinking no one remembers college here anymore. Last semester I took, I was able to check my grades by logging into a web page with my student ID and using a password. The password default was my SSN, we could change it. In any case students have read only access and are not able to change anything. Not a big deal and very little personal information was visible. If any one would have bothered to look they would have simply found out I had very good grades. shrug The point is that *something has to be kept secret* for encryption security to work. Theoretically best would be a passphrase, or a passphrase to a really big key. So, perhaps we could modify the algorithm from a few messages back, in order to address the (assumed) *practical* considerations of the OP's original query: The actual database files should not be directly reachable, except by the appropriate data base administrators, it should send and retrieve information based on the users access rights via a server. Is this a case where each account is encrypted with a different key in addition to the access rights given to each user? Cheers, Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: encryption with python
Paul Rubin http://[EMAIL PROTECTED] writes: Kirk Job Sluder [EMAIL PROTECTED] writes: Likewise, credit companies are currently making money hand-over-fist. If an identity is compromised, it's cheaper for them to just close the account, refund the money, and do their own fraud investigation after the fact. You don't get it. Refunding the money improperly charged on a single card doesn't begin to compensate for the hassle of undoing an identity theft. If airlines worked the way you're suggesting the credit industry should work, and a plane went down, the airline would be off the hook by refunding your estate the price of your ticket. It's only because they face much further-reaching liability than that, that they pay so much attention to safety. Oh, I'm not suggesting the credit industry should work that way. I'm just saying that's the way they will work as long as they can push off the costs for dealing with problems onto interest rates and other fees. -- Kirk Job-Sluder The square-jawed homunculi of Tommy Hilfinger ads make every day an existential holocaust. --Scary Go Round -- http://mail.python.org/mailman/listinfo/python-list
Re: encryption with python
Ron Adam [EMAIL PROTECTED] writes: Kirk Job Sluder wrote: They want to be able to get their information by calling a phone number and saying a few words/phrases they memorized in childhood. Given the current market, it seems to be cheaper to deal with breaks after the fact than to expect more from customers. I would think that any n digit random number not already in the data base would work for an id along with a randomly generated password that the student can change if they want. The service provider has full access to the data with their own set of id's and passwords, so in the case of a lost id, they can just look it up using the customers name and/or ssn, or whatever they decide is appropriate. In the case of a lost password, they can reset it and get another randomly generated password. Or am I missing something? Not really. My suggestion is that in many cases, if the data is being used only as a backup password or authentication token, there is no need for that data to be stored in plaintext. For example, with the ubiquitous mother's maiden name * there is frequently no need to actually have Smith, Jones, or Gunderson in the database. bf65d781795bb91ee731d25f9a68a5aeb7172bc7 serves the same purpose. There are other cases where one-way anonymity is better than a table linking people to randomly generated userIDs. I'd rather use cryptographic hashes for research databases than keep a table matching people to random numbers hanging around. But I'm weird that way. * I think mother's maiden name is a really poor method for backup authentication because for a fair number of people in the U.S., it will be identical to their current surname, and for the rest, it's trivial to discover. Cheers, Ron -- Kirk Job-Sluder The square-jawed homunculi of Tommy Hilfinger ads make every day an existential holocaust. --Scary Go Round -- http://mail.python.org/mailman/listinfo/python-list
Re: encryption with python
On Wed, 07 Sep 2005 15:52:19 -0700, James Stroud wrote: Also, I should note that the sha function will, to the limits of anyone's ability to analyze it, decouple the information from the hash. So, to be careful, you should keep the algorithm to generate the IDs secret. Security by obscurity is very little security at all. If there is any motive at all to reverse-engineer the algorithm, people will reverse engineer the algorithm. Keeping a weak algorithm secret does not make it strong. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: encryption with python
Steven D'Aprano [EMAIL PROTECTED] writes: On Wed, 07 Sep 2005 14:31:03 -0700, jlocc wrote: Basically I will like to combine a social security number (9 digits) and a birth date (8 digits, could be padded to be 9) and obtain a new 'student number'. It would be better if the original numbers can't be traced back, they will be kept in a database anyways. Hope this is a bit more specific, thanks!!! last_number_used = 123 # or some other appropriate value def make_studentID(): global last_number_used last_number_used = last_number_used + 1 return last_number_used For a real application, I'd check the database to see if the number has already been used before returning the number. Also, if you need more than four digits in your IDs, I'd add a checksum to the end so you can detect many typos and avoid much embarrassment. [...] In a real application you would need to store the global variables in a database, otherwise each time you reload the Python script you start generating the same IDs over and over again. For real applications (ignoring your theoretical need to generate the numbers in a random order) I'd not only store the number in the database - I'd let the databae generate it. Most have some form of counter that does exactly what you want without needing to keep track of it and check the database for consistency. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
encryption with python
Hi! I was wondering if someone can recommend a good encryption algorithm written in python. My goal is to combine two different numbers and encrypt them to create a new number that cann't be traced back to the originals. It would be great if there exists a library already written to do this, and if there is, can somebody please point me to it?? Thanks in advance, J -- http://mail.python.org/mailman/listinfo/python-list
Re: encryption with python
Aloha, [EMAIL PROTECTED] wrote: I was wondering if someone can recommend a good encryption algorithm written in python. It would be great if there exists a library already written to do this, and if there is, can somebody please point me to it?? M2Crypto, interface to OpenSSL http://sandbox.rulemaker.net/ngps/m2 Wishing a happy day LOBI -- http://mail.python.org/mailman/listinfo/python-list
Re: encryption with python
In article [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: Hi! I was wondering if someone can recommend a good encryption algorithm written in python. My goal is to combine two different numbers and encrypt them to create a new number that cann't be traced back to the originals. It would be great if there exists a library already written to do this, and if there is, can somebody please point me to it?? I recommend you investigate PyCrypto: http://www.amk.ca/python/code/crypto http://sourceforge.net/projects/pycrypto Cheers, -M -- Michael J. Fromberger | Lecturer, Dept. of Computer Science http://www.dartmouth.edu/~sting/ | Dartmouth College, Hanover, NH, USA -- http://mail.python.org/mailman/listinfo/python-list
Re: encryption with python
My goal is to combine two different numbers and encrypt them to create a new number that cann't be traced back to the originals. Here's one: def encrypt(x, y): Return a number that combines x and y but cannot be traced back to them. return x + y -- http://mail.python.org/mailman/listinfo/python-list
Re: encryption with python
Steve M wrote: My goal is to combine two different numbers and encrypt them to create a new number that cann't be traced back to the originals. Here's one: def encrypt(x, y): Return a number that combines x and y but cannot be traced back to them. return x + y Or you can use sha1 so you can't do basic checks to find out. :) It seems to me like he's trying to do some DH like thing, so yea, he might rather a hash UNTESTED import sha1 def encrypt(x,y): ''' Return a number that combines x and y but cannot be traced back to them. Number returned is in xrange(2**24). ''' def _dosha(v): return sha1.new(str(v)).hexdigest() return int(_dosha(_dosha(x)+_dosha(y))[5:11],16) -- http://mail.python.org/mailman/listinfo/python-list
Re: encryption with python
This is either a very simple or a very open-ended question you have asked. Do you want to be able to recover the original numbers arbitrarily from the combination? What properties do you want the combination to have? Do you want to take the combination and a number and see if the number is in the combination without revealing any other constituent numbers? Do you want to be able to provide any arbitrary number of the combination and recover all or some subset of the constituent numbers (depending on the supplied number)? What do you want to do with the combination and the individual numbers? James On Wednesday 07 September 2005 07:00 am, [EMAIL PROTECTED] wrote: Hi! I was wondering if someone can recommend a good encryption algorithm written in python. My goal is to combine two different numbers and encrypt them to create a new number that cann't be traced back to the originals. It would be great if there exists a library already written to do this, and if there is, can somebody please point me to it?? Thanks in advance, J -- James Stroud UCLA-DOE Institute for Genomics and Proteomics Box 951570 Los Angeles, CA 90095 http://www.jamesstroud.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: encryption with python
Basically I will like to combine a social security number (9 digits) and a birth date (8 digits, could be padded to be 9) and obtain a new 'student number'. It would be better if the original numbers can't be traced back, they will be kept in a database anyways. Hope this is a bit more specific, thanks!!! -- http://mail.python.org/mailman/listinfo/python-list
Re: encryption with python
[EMAIL PROTECTED] writes: Basically I will like to combine a social security number (9 digits) and a birth date (8 digits, could be padded to be 9) and obtain a new 'student number'. It would be better if the original numbers can't be traced back, they will be kept in a database anyways. Hope this is a bit more specific, thanks!!! Why do you want to include the birth date, given that the SSN will already be unique? It won't be a big obstacle to brute forcing the SSN out of a keyless hash, since knowing the student's year of graduation will in most cases be enough to narrow his or her DOB down to a few hundred possibilities. How many digits can the student number have? What happens if two different students get assigned the same number? If you have a secure database where the actual DOB and SSN are held, why not just have it issue a student ID number at the time the DOB/SSN row is added? I'm feeling that you're working in a subtle and tricky area without really knowing what you're doing, and that people's privacy is at risk. Most of the good answers to your question are going to begin with choose a random string K that you're able to keep secret through the entire lifetime of the whole system. The security of your system will rest on being able to keep K secret against determined attackers. You then have a key management problem, which has to be handled through careful procedures and possibly special hardware, not by an algorithm. Please get a copy of the book Security Engineering, by Ross Anderson, to get an idea of what you're getting into. -- http://mail.python.org/mailman/listinfo/python-list
Re: encryption with python
[EMAIL PROTECTED] wrote: Basically I will like to combine a social security number (9 digits) and a birth date (8 digits, could be padded to be 9) and obtain a new 'student number'. It would be better if the original numbers can't be traced back, they will be kept in a database anyways. Hope this is a bit more specific, thanks!!! Why don't you assign an arbitrary ID number to each student that is entirely unrelated to sensitive information (except via the database which is hopefully secure)? -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter -- http://mail.python.org/mailman/listinfo/python-list
Re: encryption with python
On Wednesday 07 September 2005 14:31, [EMAIL PROTECTED] wrote: Basically I will like to combine a social security number (9 digits) and a birth date (8 digits, could be padded to be 9) and obtain a new 'student number'. It would be better if the original numbers can't be traced back, they will be kept in a database anyways. Hope this is a bit more specific, thanks!!! Then your best bet is to take a reasonable number of bits from an sha hash. But you do not need pycrypto for this. The previous answer by ncf is good, but use the standard library and take 9 digits to lessen probability for clashes import sha def encrypt(x,y): def _dosha(v): return sha.new(str(v)).hexdigest() return int(_dosha(_dosha(x)+_dosha(y))[5:13],16) Example: py encrypt(843921299,20050906) 522277004 Each student ID should be unique until you get a really big class. If your class might grow to several million, consider taking more bits of the hash. Also, as long as you remember the function, you can get back the student ID from the birthday and SS, in case they drop out and re-enroll next year. James -- James Stroud UCLA-DOE Institute for Genomics and Proteomics Box 951570 Los Angeles, CA 90095 http://www.jamesstroud.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: encryption with python
Also, I should note that the sha function will, to the limits of anyone's ability to analyze it, decouple the information from the hash. So, to be careful, you should keep the algorithm to generate the IDs secret. The advantage of creating an ID from info in this way is that the ID is (should be) unique and unchanging. The disadvantage is that you have to keep the algorithm secret. Because by knowing it, people could generate IDs from birthdays with only 10**10 calculations (possible 9 digit SS numbers) and match them to the IDs. All they need to do this is to ask someone what their birthday is and try SS#s until they get the corresponding ID. You could keep the algorithm encrypted and decrypt it temporarily to generate a new ID. Or, you could memorize it and type it in at the beginning of the semester and generate the IDs for that semester. You might also have to do this if you loose the IDs somehow. But beware of the rubber hose cryptanalyitic attack. This is where an adversary beats you with a rubber hose then asks you for the ID generation algorithm (or key to the encrypted version). They then check your algorithm against a known birthday-SS#-ID triplet. If you lied, they repeat until they verify your algorithm. This has historically been a very successful attack. James -- James Stroud UCLA-DOE Institute for Genomics and Proteomics Box 951570 Los Angeles, CA 90095 http://www.jamesstroud.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: encryption with python
James Stroud [EMAIL PROTECTED] writes: Then your best bet is to take a reasonable number of bits from an sha hash. But you do not need pycrypto for this. The previous answer by ncf is good, but use the standard library and take 9 digits to lessen probability for clashes import sha def encrypt(x,y): def _dosha(v): return sha.new(str(v)).hexdigest() return int(_dosha(_dosha(x)+_dosha(y))[5:13],16) ... Each student ID should be unique until you get a really big class. If your class might grow to several million, consider taking more bits of the hash. Please don't give advice like this unless you know what you're doing. You're taking 8 hex digits and turning them into an integer. That means you'll probably have a collision after around 65,000 id's, not several million. Probably means 50%. You'll have a significant chance (say more than 1%) of collision after maybe 10,000. Also, if you know the student's graduation year, in most cases there are just a few hundred likely birthdates for that student, so by brute force search you can crunch the output of your function to a fairly small number of DOB/SSN combinations. The only approach that makes sense is for the secure database to assign arbitrary numbers that aren't algorithmically related to any sensitive data. Answers involving encryption will need to use either large ID numbers or secret keys, both of which will cause hassles. -- http://mail.python.org/mailman/listinfo/python-list
Re: encryption with python
Paul Rubin wrote: James Stroud [EMAIL PROTECTED] writes: Then your best bet is to take a reasonable number of bits from an sha hash. But you do not need pycrypto for this. The previous answer by ncf is good, but use the standard library and take 9 digits to lessen probability for clashes import sha def encrypt(x,y): def _dosha(v): return sha.new(str(v)).hexdigest() return int(_dosha(_dosha(x)+_dosha(y))[5:13],16) ... Each student ID should be unique until you get a really big class. If your class might grow to several million, consider taking more bits of the hash. Please don't give advice like this unless you know what you're doing. You're taking 8 hex digits and turning them into an integer. That means you'll probably have a collision after around 65,000 id's, not several million. Probably means 50%. You'll have a significant chance (say more than 1%) of collision after maybe 10,000. Also, if you know the student's graduation year, in most cases there are just a few hundred likely birthdates for that student, so by brute force search you can crunch the output of your function to a fairly small number of DOB/SSN combinations. The only approach that makes sense is for the secure database to assign arbitrary numbers that aren't algorithmically related to any sensitive data. Answers involving encryption will need to use either large ID numbers or secret keys, both of which will cause hassles. This is indubitably true. There's absolutely no excuse for making the primary key a function of the data that record contains, as doing so will assist any cryptanalytical attacks. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Encryption with Python?
Thank you all, James, Dennis, Christos, Paul, Isn't it remarkable that it takes foolishness to earn a little respect. Anyway, even as I write this, my account balance stands unchanged at ... no, come to think of it, the account balance is definitely not a part of the problem. I will volunteer the information, though, that the credit card is a debit card and is good for up to the balance of the account. In addition, I did contemplate a brute force attack. I also contemplated my belief that it takes no more than a few lines of code to keep a teraflop machine busy for a few billion years. So I would not discourage decoding attempts but will state that the game as I understand it does not have any implicit rules. Regards Frederic (I am not the OP. The OP was Blake T. Garretson who never returned, but whose problem I still consider the standard by which I wish my idea to be judged. I never intended to dabble in commercial cryptography.) - Original Message - From: Christos TZOTZIOY Georgiou [EMAIL PROTECTED] Newsgroups: comp.lang.python To: python-list@python.org Sent: Friday, May 27, 2005 11:52 AM Subject: Re: Encryption with Python? On 26 May 2005 14:45:28 -0700, rumours say that Paul Rubin http://[EMAIL PROTECTED] might have written: That's all. I see you took up the challenge and indirectly replied to my last question, and in good spirit I say you earned a little respect from me, at least for standing up to your words. Now I hope no-one gives a try to your data (for your own sake :) I don't think the challenge was really accepted. The algorithm changed between when you issued the challenge, and when the sensitive data went up. A good algorithm doesn't need to change depending on the data. I agree with the poster who said that the strength of either one of the algorithms is irrelevant, if the keyspace is just 32 bits. You are correct; the algorithm changed, and the OP admitted it himself in the post with the encrypted credit card data. However, on a practical level: before posting, I did a quick comparison, and the only effective change to OP's algorithm was a the addition of a `random.shuffle(sequence)', which AFAIU has no practical consequences as to whether his algorithm is unbreakable or not. I could say that hey, you changed the algorithm, and that means your previous declaration of unbreakability wasn't. but honestly I was overwhelmed by the audacity (and foolishness, if these are truly his credit card data) of Frederic. ObSF: DNA; The Restaurant At The End Of The Universe; Marvin the paranoid android faces a gigantic black tank in the H2G2 HQ. -- TZOTZIOY, I speak England very best. Be strict when sending and tolerant when receiving. (from RFC1958) I really should keep that in mind when talking with people, actually... -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Encryption with Python?
On Tue, 24 May 2005 10:16:15 +0200, rumours say that Anthra Norell [EMAIL PROTECTED] might have written: Why whack someone over the head who tries to develop an idea of his own. Such an approach isn't uncommon to earn extra credit in educational settings. I would never whack someone over the head (WSOTH) who tries to develop an idea of his own, and never will (intentionally at least --I myself like reinventing the wheel once in a while just to make sure my synapses still work). However I do WSOTH for I rolled my own for relatively short sequences, like passwords. The key is an integer. To decrypt use the negative encryption key. I consider the encryption unbreakable, as it is indistinguishable from a random sequence. So, to be clear, my reason was your declaring that I consider the encryption unbreakable, as it..., and that is why I actually challenged you to either support the unbreakability of your algorithm by supplying sensitive data for you, or back off and simply say ok guys, my words were a *little* over the top. That's all. I see you took up the challenge and indirectly replied to my last question, and in good spirit I say you earned a little respect from me, at least for standing up to your words. Now I hope no-one gives a try to your data (for your own sake :) -- TZOTZIOY, I speak England very best. Be strict when sending and tolerant when receiving. (from RFC1958) I really should keep that in mind when talking with people, actually... -- http://mail.python.org/mailman/listinfo/python-list
Re: Encryption with Python?
Christos TZOTZIOY Georgiou [EMAIL PROTECTED] writes: That's all. I see you took up the challenge and indirectly replied to my last question, and in good spirit I say you earned a little respect from me, at least for standing up to your words. Now I hope no-one gives a try to your data (for your own sake :) I don't think the challenge was really accepted. The algorithm changed between when you issued the challenge, and when the sensitive data went up. A good algorithm doesn't need to change depending on the data. I agree with the poster who said that the strength of either one of the algorithms is irrelevant, if the keyspace is just 32 bits. -- http://mail.python.org/mailman/listinfo/python-list
Re: Encryption with Python?
by
their knowledge of what an airplane is supposed to be.
We went on talking about creativeness and MacCready's conclusion still
rings in my ears: Our education system encourages us to be critical. This
is a great pity. It reinforces our habit to focus on other people's
weaknesses and failures, when we could learn from observing their
strengths.
Frederic
(Robert Kern could have embarrassed me with a plain-text attack, although
his bounty wouldn't have been my credit card details. I tought about
plain-text attacks and found that in addition to changing the values of
bytes I also needed to shuffle them a little. So I added a few lines,
encoded my credit card details and here it is, program, credit card
details, everything but the key.)
1. The credit card details:
string =
'\x84ue\x8d\xec\x98\x02\xban\t\xc6\xa6\xd2\xcc\xe4O\x11\xd7\xf5\xe7\x9c\xe
d
*\x05\x1e\xb3h\x97V\xf8\x9a%\xec\x14\x03r\xdd\xda\x18\xc0\x9fc\x04J\xefF\
x
cd\xbc\x81\xad\xfe\xb4SV\x1a7[l\x12\xfd\xc9w\xc3u\xf4\x83tK\x1e]{\xf5/\xbfJ
\
x8a\xde\x18\xc2jj\xe8er\x10\x99\x1e\xeb\xa3\x86\xf0f\xb9\x95\xb5\xd8\xaaY\x
0 8\xb8\xcdf.'
2. The decoding program
def cyrep (string, key):
To encrypt use a numeric value as the key. To decrypt use the
negative value of the same number.
import random
CHUNK = 32
def process_sequence (sequence):
s = ''
for i in xrange (len (sequence)):
r = random.randint (0, 255)
s += chr ((ord (sequence [i]) + r * sign) % 256)
return s
def preprocess_sequence (sequence):
random.shuffle (sequence)
return sequence
sign = (key 0) * 2 - 1
random.seed (abs (key * sign))
i = 0
s = ''
if sign 0:
while i len (string):
chunk = random.randint (0, CHUNK)
s_ = preprocess_sequence (list (string [i:i+chunk]))
s += ''.join (process_sequence (s_))
i += len (s_)
else:
while i len (string):
chunk = random.randint (0, CHUNK)
s_ = list (string [i:i+chunk])
l = len (s_)
l_ = range (l)
s__ = l * [None]
o = preprocess_sequence (l_)
s_ = process_sequence (s_)
for ii in l_:
s__ [o[ii]] = s_ [ii]
s += ''.join (s__)
i += l
return s
- Original Message -
From: Christos TZOTZIOY Georgiou [EMAIL PROTECTED]
Newsgroups: comp.lang.python
To: python-list@python.org
Sent: Friday, May 13, 2005 11:06 AM
Subject: Re: Encryption with Python?
On Sat, 7 May 2005 13:51:40 +0200, rumours say that Anthra Norell
[EMAIL PROTECTED] might have written:
Here's the challenge. Prove this breakable
'\x10\x88d\x1d\xba\xa1\xdcK\x05w\x02/s\xa7Q0\xeb8\xb6Gx\xef\xcb\x1e=\xf5\x
7
f
\x9bI\xcb(\x87\xa5\x04\xc1soF\xfd\xc6\xc6\xd9|\x971\xdb\xcdT\tw#\x86a\xdc
\
x
b8P\xfb=n\xda\x80\x9f\x84m\x12\x98\x98\xca=o\x0b\x8e\x08O\xb7\x0b\x04SC\x9
6
\
xc7\xab*\x0b\x996\x06\x86\x83(\x8dQ\x9eG\x8f$\xb2x)\xa9fv\x0c1B\x9b\r\xde\
x
f
fc\x08'
and given that
I rolled my own for relatively short sequences, like passwords. The key
is
an integer. To decrypt use the negative encryption key. I consider the
encryption unbreakable, as it is indistinguishable from a random
sequence.
can we suppose that the encrypted text above are the details of your
credit card (number, name as written on it, expiry date, billing address
and your first dog's name)? Do you trust the 'unbreakability' of your
algorithm that much?
--
TZOTZIOY, I speak England very best.
Be strict when sending and tolerant when receiving. (from RFC1958)
I really should keep that in mind when talking with people, actually...
--
http://mail.python.org/mailman/listinfo/python-list
--
James Stroud
UCLA-DOE Institute for Genomics and Proteomics
Box 951570
Los Angeles, CA 90095
http://www.jamesstroud.com/
--
http://mail.python.org/mailman/listinfo/python-list
Re: Encryption with Python?
Hi, I am a very happy user of http://www.amk.ca/python/code/crypto.html Regards, Philippe Blake T. Garretson wrote: I want to save some sensitive data (passwords, PIN numbers, etc.) to disk in a secure manner in one of my programs. What is the easiest/best way to accomplish strong file encryption in Python? Any modern block cipher will do: AES, Blowfish, etc. I'm not looking for public key stuff; I just want to provide a pass-phrase. I found a few modules out there, but they seem to be all but abandoned. Most seem to have died several years ago. The most promising package is A.M. Kuchling's Python Cryptography Toolkit (http://www.amk.ca/python/code/crypto.html). Is this the defacto Python encryption solution? What does everyone else use? Any other suggestions? The SSLCrypto package (http://www.freenet.org.nz/python/SSLCrypto/) may be a good alternative too, but I am not sure if it is actively maintained. Thanks, Blake -- http://mail.python.org/mailman/listinfo/python-list
Re: Encryption with Python?
On Sat, 7 May 2005 13:51:40 +0200, rumours say that Anthra Norell [EMAIL PROTECTED] might have written: Here's the challenge. Prove this breakable '\x10\x88d\x1d\xba\xa1\xdcK\x05w\x02/s\xa7Q0\xeb8\xb6Gx\xef\xcb\x1e=\xf5\x7f \x9bI\xcb(\x87\xa5\x04\xc1soF\xfd\xc6\xc6\xd9|\x971\xdb\xcdT\tw#\x86a\xdc\x b8P\xfb=n\xda\x80\x9f\x84m\x12\x98\x98\xca=o\x0b\x8e\x08O\xb7\x0b\x04SC\x96\ xc7\xab*\x0b\x996\x06\x86\x83(\x8dQ\x9eG\x8f$\xb2x)\xa9fv\x0c1B\x9b\r\xde\xf fc\x08' and given that I rolled my own for relatively short sequences, like passwords. The key is an integer. To decrypt use the negative encryption key. I consider the encryption unbreakable, as it is indistinguishable from a random sequence. can we suppose that the encrypted text above are the details of your credit card (number, name as written on it, expiry date, billing address and your first dog's name)? Do you trust the 'unbreakability' of your algorithm that much? -- TZOTZIOY, I speak England very best. Be strict when sending and tolerant when receiving. (from RFC1958) I really should keep that in mind when talking with people, actually... -- http://mail.python.org/mailman/listinfo/python-list
Re: Encryption with Python?
Anthra Norell wrote: Thanks a lot for the feedback. This is certainly a great learning experience. It's a fascinating topic too. Without wishing to annoy, I'd be interested in knowing more. I insert questions below. You can google your questions and you will find them out answered in many cryptography FAQs. For a less mathematical, but entertaining treatise on cryptography, read Simon Singh's The Code Book. You will definitely appreciate how the various crypto algorithms through the history of mankind were broken and what is the state of the art in the field. -- http://mail.python.org/mailman/listinfo/python-list
Re: Encryption with Python?
Robert Kern wrote: Peter Hansen wrote: Back to Paul's question then: why use an unreliable and probably-useless-for-all-but-spawning-lengthy-but-educational-threads encryption method when there are relatively reliable and, uh, less discussed and non-edifying, uh... well, you get the picture. ;-) Well, I'd say ARCFOUR has been discussed a hell of a lot more than what this thread ever mustered up. I also submit that implementing ARCFOUR or studying p3.py would be a hell of a lot more educational than posting a lousy algorithm, calling it unbreakable, and responding to criticisms with I don't understand so you must be wrong. Education is a process one must engage in. You don't just step in it. The education to which I was referring was that which _most_ of us just received by reading Paul's and your replies, not from anything in the OP's postings. ;-) -Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: Encryption with Python?
Peter Hansen wrote: Education is a process one must engage in. You don't just step in it. The education to which I was referring was that which _most_ of us just received by reading Paul's and your replies, not from anything in the OP's postings. ;-) Okay, I'll buy that. :-) -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter -- http://mail.python.org/mailman/listinfo/python-list
Re: Encryption with Python?
Original Message - From: Paul Rubin http://phr.cx@NOSPAM.invalid Newsgroups: comp.lang.python To: python-list@python.org Sent: Tuesday, May 10, 2005 12:59 AM Subject: Re: Encryption with Python? .. Since good encryption schemes that don't have significant performance penalties are widely available, why mess with a crap scheme EVER? Why use a solution that might or might not be adequate when you can use one that's definitely ok? .. Why indeed?---Why run a marathon? Why have kids? Why shave? Why play chess? Why sprinkle the lawn? Or as my friend Sergio's favorite line went: Why you jerks cook your own muck when there are so many good restaurants in town? His was definitely the best when it went out of business. Regards Frederic -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Encryption with Python?
Anthra Norell wrote: From: Paul Rubin http://phr.cx@NOSPAM.invalid .. Since good encryption schemes that don't have significant performance penalties are widely available, why mess with a crap scheme EVER? Why use a solution that might or might not be adequate when you can use one that's definitely ok? .. Why indeed?---Why run a marathon? To demonstrate your physical supremacy over your inferiors. Why have kids? Because you forgot to wear protection. Why shave? Your wife insists? Mine does... Why play chess? To demonstrate your intellectual supremacy over your inferiors. Why sprinkle the lawn? Too much beer and there's a line-up to use the john? Or as my friend Sergio's favorite line went: Why you jerks cook your own muck when there are so many good restaurants in town? To demonstrate your culinary supremacy over your inferiors? His was definitely the best when it went out of business. (Hmm... so is my business doing merely well if it's losing money?) Back to Paul's question then: why use an unreliable and probably-useless-for-all-but-spawning-lengthy-but-educational-threads encryption method when there are relatively reliable and, uh, less discussed and non-edifying, uh... well, you get the picture. ;-) -Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: Encryption with Python?
Robert, Thanks a lot for your thorough explanations. - Original Message - From: Robert Kern [EMAIL PROTECTED] To: python-list@python.org Sent: Saturday, May 07, 2005 3:18 PM Subject: Re: Encryption with Python? ( snip ) You do realize that if I have two ciphertexts encrypted with the same key, I can subtract them? Then I have a sequence, that while not immediately readable, is just a straightforward combination of the two plaintexts without any encryption. How do you know the same key was used? I don't necessarily, but if the same key *is* used, I'll know. The differences of the ciphertexts will have distinctly non-random characteristics (well, assuming the plaintexts aren't one-time pads themselves). The non-randomness of the difference is evidence of having guessed the key, right? Why then do I need two samples? If I hack away at a single sample I get a probably more conspicuous non-randomness twice as fast. ( snip ) Additionally, one should not use the Mersenne Twister PRNG, which is what Python uses, as the PRNG for the stream cipher. Given a particular value or series of values, it is possible to determine one's position in the PRNG sequence and can, in essence derive the key. Some techniques can be used to hide actual current state of the PRNG like applying a cryptographic hash to the value from the PRNG. However, it's easier and far better to just use a cryptographically strong PRNG from the start. I don't doubt that, given a series (long enough), the postion can be derived. I doubt, though, that a series is knowable, if another, unknown, series has been added to it. If, however, it is meant to suggest that it is the reversible, direct one-on-one relation between all the characters of a plain text and its encryption that falls short of state-of-the-art technology, I'd have no problem with that. That doesn't mean, however, that an exercise is required to measure up to state-of-the-art standards in order to be taken seriously. I do invent my own solutions for simple problems. This is not a simple problem. I thought the problem was concealing passwords from ones kids or collaborators. You haven't proved your claim that your cipher is unbreakable. Your notion of unbreakable is also flawed; indistinguishable from 'random' sequences is only one part of cryptosystem security. For that matter, you haven't proven that the ciphertexts produced are indistinguishable from random sequences. Note the plural. It's important. I believe that a randomly distributed series utterly obliterates any non-randomness or regularity of a second series, if the two are added. I don't know how to produce a formal proof. It is just a hunch. It's actually more than a hunch. It is a conviction. Not a certainty; a conviction. I'd be delighted to be proved wrong (or right). The fact may be significant that we module overflow back into the range. So, if the distribution of my code is indeed random, it will display no clue about the key and can only be broken with a brute-force attack. This imposes a second requirement, which is that a brute-force attack outtries the patience of a teraflop machine. The function I posted, quite obviously, does not satisfy this second requirement. The function can easily be applied in a manner, though, that takes care of that. A third rquirement I cannot think of. You have a positive obligation to back your claim. I've pointed you to two obvious attacks that can be made against your system and also to resources that you can read to improve your knowledge of the issues. I *don't* have an obligation to spend more of my time meeting your arbitrary challenge. My reluctance to do so is not support for your claim. I am not aiming at a Nobel prize and certainly don't presume to impose on your priorities. So the term 'obligation' seems not very useful here. I claim that my solution satisfies the requirements of the task at hand and challenge anyone to prove the contrary. You can meet the challenge by deciphering the following tiny message, knowing now the encryption method, which in practice would not be known Bull. And irrelevant. Irrelevant okay, if the OP agrees. ( snip ) Best regards, Frederic -- http://mail.python.org/mailman/listinfo/python-list
Re: Encryption with Python?
Anthra Norell [EMAIL PROTECTED] writes: The non-randomness of the difference is evidence of having guessed the key, right? Why then do I need two samples? If I hack away at a single sample I get a probably more conspicuous non-randomness twice as fast. No. Let's say you encrypt two ascii strings with the same key. The high bit of each byte in the plaintext is zero. Therefore if you xor the two ciphertexts together, the high bit of each byte of the result xor'd ciphertexts will be zero. So just check for that and you've immediately spotted the non-randomness. I don't doubt that, given a series (long enough), the postion can be derived. I doubt, though, that a series is knowable, if another, unknown, series has been added to it. You have to assume that the attacker has access to known plaintext-ciphertext pairs. For example, you might not tell someone the password you use now, but what about some old password that you don't use any more? If the attacker knows your old password (maybe because your sysop set it to some default value and had you change it on your first login), and has the encrypted version, there's a known plaintext. I thought the problem was concealing passwords from ones kids or collaborators. Encryption is supposed to conceal data from knowledgable attackers willing to burn significant resources to get at the data. That might or might not describe your friends and collaborators. I believe that a randomly distributed series utterly obliterates any non-randomness or regularity of a second series, if the two are added. This is a meaningless statement since you don't give any definition of randomly distributed series. I don't know how to produce a formal proof. It is just a hunch. It's actually more than a hunch. It is a conviction. Not a certainty; a conviction. I'd be delighted to be proved wrong (or right). If the keystream really can't be distinguished from random, then correct, though there's still issues with key management (you mustn't use the same key twice) and authentication. Generating keystreams that are indistinguishable from random is an extremely tricky subject, there are books and papers written about it, etc. The fact may be significant that we module overflow back into the range. So, if the distribution of my code is indeed random, Your code used the Python built-in PRNG algorithm which is designed to make output with similar statistical properties as actual random numbers, for the purpose of running stuff like simulations. It makes no attempt at all to be secure against attackers trying to figure out whether the output is really random. -- http://mail.python.org/mailman/listinfo/python-list
Re: Encryption with Python?
Paul,
I thank you too for your response. Let me just tell you what goes
through my mind.
- Original Message -
From: Paul Rubin http://phr.cx@NOSPAM.invalid
Newsgroups: comp.lang.python
To: python-list@python.org
Sent: Monday, May 09, 2005 9:45 PM
Subject: Re: Encryption with Python?
Anthra Norell [EMAIL PROTECTED] writes:
The non-randomness of the difference is evidence of having guessed the
key,
right? Why then do I need two samples? If I hack away at a single sample
I
get a probably more conspicuous non-randomness twice as fast.
No. Let's say you encrypt two ascii strings with the same key. The
high bit of each byte in the plaintext is zero. Therefore if you xor
the two ciphertexts together, the high bit of each byte of the result
xor'd ciphertexts will be zero. So just check for that and you've
immediately spotted the non-randomness.
I don't follow. There is no bitwise correlation between a plain-text
character and its encoded equivalent. What's more, there is no detectable
correlation at all. Take a highly ordered plain text, such as a sting of
identical characters, e.g. 'AAA' and sequentially add a
deterministically generated random series (module 256 to keep them within
range), what you get is, quite obviously, a series of numbers that differs
from the added random series in only one respect: all values are shifted by
ord ('A'). The intervals from one byte to the next remain unchanged,
allowance made for the module 256 wrap-around. The intervals remaining
unchanged, the distribution and hence the randomness of the encryption
remains unchanged. Quite obviously, each one of the identical plain-text
characters very likely will be encrypted differently. Repeats would occur,
but they would occur randomly once every 256 times on an average.
I don't doubt that, given a series (long enough), the postion can be
derived. I doubt, though, that a series is knowable, if another,
unknown,
series has been added to it.
You have to assume that the attacker has access to known
plaintext-ciphertext pairs. For example, you might not tell someone
the password you use now, but what about some old password that you
don't use any more? If the attacker knows your old password (maybe
because your sysop set it to some default value and had you change it
on your first login), and has the encrypted version, there's a known
plaintext.
Password management is certainly a problem, but of course is totally
unrelated to the quality of an encryption method.
I thought the problem was concealing passwords from ones kids or
collaborators.
Encryption is supposed to conceal data from knowledgable attackers
willing to burn significant resources to get at the data. That mightof
or might not describe your friends and collaborators.
I agree. Depending on a situation, a solution might or might not be
adequate.
I believe that a randomly distributed series utterly obliterates any
non-randomness or regularity of a second series, if the two are added.
This is a meaningless statement since you don't give any definition of
randomly distributed series.
No, in fact I don't. I am quite confident that the library module 'random'
produces random distributions. As to the distribution of a non-random series
added to a random series, my intuition tells me that it remains random.
I don't know how to produce a formal proof. It is just a hunch. It's
actually more than a hunch. It is a conviction. Not a certainty; a
conviction. I'd be delighted to be proved wrong (or right).
I don't think it would be difficult for a mathematician to prove or disprove
the hypothesis. I did come up with an informal proof. It is a function I
will add at the bottom of this message. You can copy and run it, if you have
the Image package installed.
If the keystream really can't be distinguished from random, then correct,
though there's still issues with key management (you mustn't use the same
key twice) and authentication.
The key is the seed of the random generator.
Generating keystreams that are indistinguishable from random is an
extremely tricky subject, there are books and papers written about it,
etc.
I agree. I wouldn't know how to design a random generator. Fortunately I
don't need to. I can use ready made ones.
The fact may be significant that we module overflow back into the
range. So, if the distribution of my code is indeed random,
Your code used the Python built-in PRNG algorithm which is designed to
make output with similar statistical properties as actual random numbers,
for the purpose of running stuff like simulations. It makes no attempt
at all to be secure against attackers trying to figure out whether the
output is really random.
Try out the following function. You need the Image package.
Regards
Frederic
###
def informal_proof_of_randomness (text_file_name):# File must be longer
than 60K
X
Re: Encryption with Python?
Anthra Norell [EMAIL PROTECTED] writes: I don't follow. There is no bitwise correlation between a plain-text character and its encoded equivalent. What's more, there is no detectable correlation at all. Your question was how could you tell if two ciphertexts were encrypted with the same key. Answer: suppose both plaintext are ascii strings. Then both plaintexts have 0 as the top bit of every byte. So do this: x = ciphertext1 xor ciphertext2 If ciphertext1 and ciphertext2 were encrypted with two different keys, the top bit of x's bytes will be random-looking. If ciphertext1 and ciphertext2 were encrypted with the same key, the top bit of each of x's bytes will be 0. So just check whether the top bit of x is always 0. If it is, then ciphertexts 1 and 2 were probably encrypted with the same key. Password management is certainly a problem, but of course is totally unrelated to the quality of an encryption method. You're ignoring your own question. With a good encryption scheme, finding out an old password doesn't tell you anything about new messages. With your encryption scheme, finding out an old password leaks information about the new one. I agree. Depending on a situation, a solution might or might not be adequate. Since good encryption schemes that don't have significant performance penalties are widely available, why mess with a crap scheme EVER? Why use a solution that might or might not be adequate when you can use one that's definitely ok? No, in fact I don't. I am quite confident that the library module 'random' produces random distributions. The author of the algorithm doesn't agree with you. The documentation is very explicit, it's no good for cryptography, and if you study how it works you can see that it's easily distinguishable from random. I don't think it would be difficult for a mathematician to prove or disprove the hypothesis. It's true of a genuine random keystream, but that's not what we're talking about. We're talking about the output of python's random module, which is not of cryptographic quality. It's fine for statistical simulations in that it doesn't have correlations that are likely to accidentally cause trouble. It's no good for defeating adversaries who are looking for correlations on purpose. Lots of people don't understand the difference. Please see the book Security Engineering by Ross Anderson to get an idea of what you're up against. Generating keystreams that are indistinguishable from random is an extremely tricky subject, there are books and papers written about it, etc. I agree. I wouldn't know how to design a random generator. Fortunately I don't need to. I can use ready made ones. There are good ready ones available, but the one you're proposing to use is not one of them and was not designed to be. Try out the following function. You need the Image package. That doesn't prove a thing. -- http://mail.python.org/mailman/listinfo/python-list
Re: Encryption with Python?
Blake T. Garretson wrote: I want to save some sensitive data (passwords, PIN numbers, etc.) to disk in a secure manner in one of my programs. What is the easiest/best way to accomplish strong file encryption in Python? Any modern block cipher will do: AES, Blowfish, etc. I'm not looking for public key stuff; I just want to provide a pass-phrase. I found a few modules out there, but they seem to be all but abandoned. Most seem to have died several years ago. The most promising package is A.M. Kuchling's Python Cryptography Toolkit (http://www.amk.ca/python/code/crypto.html). Is this the defacto Python encryption solution? What does everyone else use? Any other suggestions? The SSLCrypto package (http://www.freenet.org.nz/python/SSLCrypto/) may be a good alternative too, but I am not sure if it is actively maintained. Thanks, Blake There's a DES implementation at http://home.pacific.net.au/~twhitema/des.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Encryption with Python?
I rolled my own for relatively short sequences, like passwords. The key is an integer. To decrypt use the negative encryption key. I consider the encryption unbreakable, as it is indistinguishable from a random sequence. Frederic ### def crypt (sequence, key): import random sign = (key 0) * 2 - 1 random.seed (abs (key * sign)) s = '' for i in xrange (len (sequence)): r = random.randint (0, 255) s += chr ((ord (sequence [i]) + r * sign) % 256) return s ### If unauthrorized use of the machine is a concern, crypt might not be an appropriate name for the function. To help an intruder understand it, a doc string such as the following one might be useful: def cyrep (sequence, key): Cyclic Redundancy Preprocessor Cyclic redundancy checks often fail to differentiate relatively short sequences that contain sequences of binary zeroes of different length. This preporcessor applies a keyed randomizing filter to improve the capability of the cyclic redundancy algorithm. Use the output of this function as input to a CRC routine. Negative keys cannot be used. If passed they are positivized rather than rejected. ### - Original Message - From: Blake T. Garretson [EMAIL PROTECTED] Newsgroups: comp.lang.python To: python-list@python.org Sent: Thursday, May 05, 2005 10:20 PM Subject: Encryption with Python? I want to save some sensitive data (passwords, PIN numbers, etc.) to disk in a secure manner in one of my programs. What is the easiest/best way to accomplish strong file encryption in Python? Any modern block cipher will do: AES, Blowfish, etc. I'm not looking for public key stuff; I just want to provide a pass-phrase. I found a few modules out there, but they seem to be all but abandoned. Most seem to have died several years ago. The most promising package is A.M. Kuchling's Python Cryptography Toolkit (http://www.amk.ca/python/code/crypto.html). Is this the defacto Python encryption solution? What does everyone else use? Any other suggestions? The SSLCrypto package (http://www.freenet.org.nz/python/SSLCrypto/) may be a good alternative too, but I am not sure if it is actively maintained. Thanks, Blake -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Encryption with Python?
Anthra Norell [EMAIL PROTECTED] writes: I rolled my own for relatively short sequences, like passwords. The key is an integer. To decrypt use the negative encryption key. I consider the encryption unbreakable, as it is indistinguishable from a random sequence. You're using the built-in random module which is designed to provide only statistical randomness and not cryptographic security. It should not be used for encryption. The math paper describing the function is quite clear about that. There is a lot of subtlety to this stuff and it's easy to make mistakes even if you know what you're doing. Even using well-tested block ciphers (various people mentioned DES, AES, and Blowfish modules) it's easy to make mistakes in choosing operation modes, thinking you don't need authentication when you really do, etc., etc. The book Practical Cryptography by Bruce Schneier and Niels Ferguson is worth looking at if you want to see what you're getting yourself into. I hate to come across as plugging my own stuff too much, but http://www.nightsong.com/phr/crypto/p3.py is designed to take care of most of the tricky issues for you while still having a very simple interface, and also be reasonably fast (much faster for large messages than any of the pure Python block cipher modules). Just use p3_encrypt(plain) to encrypt and p3_decrypt(cipher) to decrypt. The main penalty you pay is that the ciphertext is a couple dozen bytes longer than the plaintext. There are cryptographically important reasons for that; don't try to escape it without knowing exactly what's going on. -- http://mail.python.org/mailman/listinfo/python-list
Re: Encryption with Python?
Anthra Norell wrote: I rolled my own for relatively short sequences, like passwords. The key is an integer. To decrypt use the negative encryption key. I consider the encryption unbreakable, as it is indistinguishable from a random sequence. Frederic ### def crypt (sequence, key): import random sign = (key 0) * 2 - 1 random.seed (abs (key * sign)) s = '' for i in xrange (len (sequence)): r = random.randint (0, 255) s += chr ((ord (sequence [i]) + r * sign) % 256) return s The mind boggles. You do realize that if I have two ciphertexts encrypted with the same key, I can subtract them? Then I have a sequence, that while not immediately readable, is just a straightforward combination of the two plaintexts without any encryption. This function is also vulnerable to a chosen-plaintext attack. The underlying PRNG is definitely not suitable for cryptographic applications. The documentation even says so! http://docs.python.org/lib/module-random.html However, being completely deterministic, it is not suitable for all purposes, and is completely unsuitable for cryptographic purposes. Do yourself a favor and don't try to roll your own cryptographic functions. Do everyone else a favor and don't call something unbreakable unless you actually have the domain expertise to make that determination. And do read _Practical Cryptography_. -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter -- http://mail.python.org/mailman/listinfo/python-list
Re: Encryption with Python?
Thanks a lot for the feedback. This is certainly a great learning experience. It's a fascinating topic too. Without wishing to annoy, I'd be interested in knowing more. I insert questions below. - Original Message - From: Robert Kern [EMAIL PROTECTED] To: python-list@python.org Sent: Saturday, May 07, 2005 11:11 AM Subject: Re: Encryption with Python? Anthra Norell wrote: I rolled my own for relatively short sequences, like passwords. The key is an integer. To decrypt use the negative encryption key. I consider the encryption unbreakable, as it is indistinguishable from a random sequence. Frederic ### def crypt (sequence, key): import random sign = (key 0) * 2 - 1 random.seed (abs (key * sign)) s = '' for i in xrange (len (sequence)): r = random.randint (0, 255) s += chr ((ord (sequence [i]) + r * sign) % 256) return s The mind boggles. You do realize that if I have two ciphertexts encrypted with the same key, I can subtract them? Then I have a sequence, that while not immediately readable, is just a straightforward combination of the two plaintexts without any encryption. How do you know the same key was used? What if the messages aren't the same length? How does one reconstruct either or both of two messages from their difference? This function is also vulnerable to a chosen-plaintext attack. The underlying PRNG is definitely not suitable for cryptographic applications. The documentation even says so! What is a plain-text attack? Is it you give me a plain text. I encrypt it using the same keys and hand you the result? Would I comply with the request? http://docs.python.org/lib/module-random.html However, being completely deterministic, it is not suitable for all purposes, and is completely unsuitable for cryptographic purposes. The logic escapes me if it is understood to mean that cryptography, in order to be usable, has to be indeterministic. If, however, it is meant to suggest that it is the reversible, direct one-on-one relation between all the characters of a plain text and its encryption that falls short of state-of-the-art technology, I'd have no problem with that. That doesn't mean, however, that an exercise is required to measure up to state-of-the-art standards in order to be taken seriously. I do invent my own solutions for simple problems. I find it more challenging than stalking other people's solutions how ever superior and typically it also saves me time. It is not my ambition to excel in any field, nor to flaunt my erudition. It is my ambition to satisfy the requirements of a given task. And this, I think, my solution does. I can be wrong and if so, I'd appreciate being proven wrong. I have now received well-meaning advice for which I am grateful. But I haven't been proven wrong. I claim that my solution satisfies the requirements of the task at hand and challenge anyone to prove the contrary. You can meet the challenge by deciphering the following tiny message, knowing now the encryption method, which in practice would not be known and, as it seems, would hardly be suspected by deciphering experts for its amateurishness. Do yourself a favor and don't try to roll your own cryptographic functions. Do everyone else a favor and don't call something unbreakable unless you actually have the domain expertise to make that determination. Here's the challenge. Prove this breakable '\x10\x88d\x1d\xba\xa1\xdcK\x05w\x02/s\xa7Q0\xeb8\xb6Gx\xef\xcb\x1e=\xf5\x7f \x9bI\xcb(\x87\xa5\x04\xc1soF\xfd\xc6\xc6\xd9|\x971\xdb\xcdT\tw#\x86a\xdc\x b8P\xfb=n\xda\x80\x9f\x84m\x12\x98\x98\xca=o\x0b\x8e\x08O\xb7\x0b\x04SC\x96\ xc7\xab*\x0b\x996\x06\x86\x83(\x8dQ\x9eG\x8f$\xb2x)\xa9fv\x0c1B\x9b\r\xde\xf fc\x08' When you give up we may try a plain-text attack. Okay? And do read _Practical Cryptography_. I certainly will. -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Encryption with Python?
What machine did you say that was, again? Jim -- http://mail.python.org/mailman/listinfo/python-list
Re: Encryption with Python?
Anthra Norell [EMAIL PROTECTED] writes: Thanks a lot for the feedback. This is certainly a great learning experience. It's a fascinating topic too. Without wishing to annoy, I'd be interested in knowing more. I insert questions below. There is a lot of information about the issues on the net. Before asking questions, isn't it better to make some research? For example, your last question is perfectly answered here: http://www.faqs.org/faqs/cryptography-faq/part02/ 2.3. How do I present a new encryption scheme in sci.crypt? ``I just came up with this neat method of encryption. Here's some ciphertext: FHDSIJOYW^[EMAIL PROTECTED] Is it strong?'' Without a doubt questions like this are the most annoying traffic on sci.crypt. ... I'd suggest you to start your education here before you invent yet another simple solutions for a complex problem: http://www.faqs.org/faqs/cryptography-faq/part01/ HTH. -- Sergei. -- http://mail.python.org/mailman/listinfo/python-list
Re: Encryption with Python?
Anthra Norell wrote: Thanks a lot for the feedback. This is certainly a great learning experience. It's a fascinating topic too. Without wishing to annoy, I'd be interested in knowing more. I insert questions below. - Original Message - From: Robert Kern [EMAIL PROTECTED] To: python-list@python.org Sent: Saturday, May 07, 2005 11:11 AM Subject: Re: Encryption with Python? Anthra Norell wrote: I rolled my own for relatively short sequences, like passwords. The key is an integer. To decrypt use the negative encryption key. I consider the encryption unbreakable, as it is indistinguishable from a random sequence. Frederic ### def crypt (sequence, key): import random sign = (key 0) * 2 - 1 random.seed (abs (key * sign)) s = '' for i in xrange (len (sequence)): r = random.randint (0, 255) s += chr ((ord (sequence [i]) + r * sign) % 256) return s The mind boggles. You do realize that if I have two ciphertexts encrypted with the same key, I can subtract them? Then I have a sequence, that while not immediately readable, is just a straightforward combination of the two plaintexts without any encryption. How do you know the same key was used? I don't necessarily, but if the same key *is* used, I'll know. The differences of the ciphertexts will have distinctly non-random characteristics (well, assuming the plaintexts aren't one-time pads themselves). What if the messages aren't the same length? Then I just look at the common portion. How does one reconstruct either or both of two messages from their difference? Analyzing patterns, frequencies, and also using prior knowledge I may know or guess about the contents. This is only slightly worse (for the attacker) than tackling a straight substitution cipher. This function is also vulnerable to a chosen-plaintext attack. The underlying PRNG is definitely not suitable for cryptographic applications. The documentation even says so! What is a plain-text attack? Chosen-plaintext, please. Is it you give me a plain text. I encrypt it using the same keys and hand you the result? More or less. Would I comply with the request? Depending on how your cryptosystem is deployed, you may not have a choice. A cryptosystem ought to be resistent to chosen-plaintext attacks regardless of how you intend to deploy it. http://docs.python.org/lib/module-random.html However, being completely deterministic, it is not suitable for all purposes, and is completely unsuitable for cryptographic purposes. The logic escapes me if it is understood to mean that cryptography, in order to be usable, has to be indeterministic. The two characteristics completely deterministic and unsuitable for cryptographic purposes are only mildly related. One *definitely* wouldn't use any PRNG to generate keying material. You should rely on physical sources of randomness. Most modern OSes have some way to access reliable entropy from your machine. Unices usually have this as /dev/random. But that's a separate issue. Additionally, one should not use the Mersenne Twister PRNG, which is what Python uses, as the PRNG for the stream cipher. Given a particular value or series of values, it is possible to determine one's position in the PRNG sequence and can, in essence derive the key. Some techniques can be used to hide actual current state of the PRNG like applying a cryptographic hash to the value from the PRNG. However, it's easier and far better to just use a cryptographically strong PRNG from the start. If, however, it is meant to suggest that it is the reversible, direct one-on-one relation between all the characters of a plain text and its encryption that falls short of state-of-the-art technology, I'd have no problem with that. That doesn't mean, however, that an exercise is required to measure up to state-of-the-art standards in order to be taken seriously. I do invent my own solutions for simple problems. This is not a simple problem. But fortunately, there *is* a relatively simple answer. Besides Paul Rubin's p3.py (which to my limited ability to determine is probably best-of-breed for the limits imposed upon it), there is a very simply-coded stream cipher that *is* cryptographically strong if the appropriate details are observed. It's called RC4 (or ARCFOUR). A reasonably good cryptosystem built around that cipher is called Ciphersaber-2. http://ciphersaber.gurus.com/cryptanalysis.html There are dozens of implementations floating around, but it's ridiculously easy to code up by yourself. I find it more challenging than stalking other people's solutions how ever superior and typically it also saves me time. It is not my ambition to excel in any field, nor to flaunt my erudition. It is my ambition to satisfy the requirements of a given task. And this, I think, my solution does. I can be wrong and if so, I'd appreciate being proven wrong. I have now received well-meaning advice
Re: Encryption with Python?
I use http://www.amk.ca/python/code/crypto.html Regards, Philippe Blake T. Garretson wrote: I want to save some sensitive data (passwords, PIN numbers, etc.) to disk in a secure manner in one of my programs. What is the easiest/best way to accomplish strong file encryption in Python? Any modern block cipher will do: AES, Blowfish, etc. I'm not looking for public key stuff; I just want to provide a pass-phrase. I found a few modules out there, but they seem to be all but abandoned. Most seem to have died several years ago. The most promising package is A.M. Kuchling's Python Cryptography Toolkit (http://www.amk.ca/python/code/crypto.html). Is this the defacto Python encryption solution? What does everyone else use? Any other suggestions? The SSLCrypto package (http://www.freenet.org.nz/python/SSLCrypto/) may be a good alternative too, but I am not sure if it is actively maintained. Thanks, Blake -- http://mail.python.org/mailman/listinfo/python-list
Re: Encryption with Python?
PS: remmember that single DES has been brocken. If you're also interested in signature, this is an interesting article (a big upsate if true) http://it.slashdot.org/article.pl?sid=05/02/16/0146218tid=93 Regards, Philippe Philippe C. Martin wrote: I use http://www.amk.ca/python/code/crypto.html Regards, Philippe Blake T. Garretson wrote: I want to save some sensitive data (passwords, PIN numbers, etc.) to disk in a secure manner in one of my programs. What is the easiest/best way to accomplish strong file encryption in Python? Any modern block cipher will do: AES, Blowfish, etc. I'm not looking for public key stuff; I just want to provide a pass-phrase. I found a few modules out there, but they seem to be all but abandoned. Most seem to have died several years ago. The most promising package is A.M. Kuchling's Python Cryptography Toolkit (http://www.amk.ca/python/code/crypto.html). Is this the defacto Python encryption solution? What does everyone else use? Any other suggestions? The SSLCrypto package (http://www.freenet.org.nz/python/SSLCrypto/) may be a good alternative too, but I am not sure if it is actively maintained. Thanks, Blake -- http://mail.python.org/mailman/listinfo/python-list
Re: Encryption with Python?
Blake T. Garretson wrote: I want to save some sensitive data (passwords, PIN numbers, etc.) to disk in a secure manner in one of my programs. What is the easiest/best way to accomplish strong file encryption in Python? Any modern block cipher will do: AES, Blowfish, etc. I'm not looking for public key stuff; I just want to provide a pass-phrase. There's a pure python Blowish implementation at: http://bofh.concordia.ca/blowfish.py (It looks like you'll have to divide your data in 8 byte blocks yourself, and pad the last block) -- http://mail.python.org/mailman/listinfo/python-list
Encryption with Python?
I want to save some sensitive data (passwords, PIN numbers, etc.) to disk in a secure manner in one of my programs. What is the easiest/best way to accomplish strong file encryption in Python? Any modern block cipher will do: AES, Blowfish, etc. I'm not looking for public key stuff; I just want to provide a pass-phrase. I found a few modules out there, but they seem to be all but abandoned. Most seem to have died several years ago. The most promising package is A.M. Kuchling's Python Cryptography Toolkit (http://www.amk.ca/python/code/crypto.html). Is this the defacto Python encryption solution? What does everyone else use? Any other suggestions? The SSLCrypto package (http://www.freenet.org.nz/python/SSLCrypto/) may be a good alternative too, but I am not sure if it is actively maintained. Thanks, Blake -- http://mail.python.org/mailman/listinfo/python-list
Re: Encryption with Python?
Bill Gates us MD5. Hah! Sorry. :-) Blake T. Garretson wrote: I want to save some sensitive data (passwords, PIN numbers, etc.) to disk in a secure manner in one of my programs. What is the easiest/best way to accomplish strong file encryption in Python? Any modern block cipher will do: AES, Blowfish, etc. I'm not looking for public key stuff; I just want to provide a pass-phrase. I found a few modules out there, but they seem to be all but abandoned. Most seem to have died several years ago. The most promising package is A.M. Kuchling's Python Cryptography Toolkit (http://www.amk.ca/python/code/crypto.html). Is this the defacto Python encryption solution? What does everyone else use? Any other suggestions? The SSLCrypto package (http://www.freenet.org.nz/python/SSLCrypto/) may be a good alternative too, but I am not sure if it is actively maintained. Thanks, Blake -- http://mail.python.org/mailman/listinfo/python-list
Re: Encryption with Python?
Blake T. Garretson [EMAIL PROTECTED] writes: I want to save some sensitive data (passwords, PIN numbers, etc.) to disk in a secure manner in one of my programs. What is the easiest/best way to accomplish strong file encryption in Python? Any modern block cipher will do: AES, Blowfish, etc. I'm not looking for public key stuff; I just want to provide a pass-phrase. http://www.nightsong.com/phr/crypto/p3.py It uses SHA1 in OFB mode and is fairly fast for a pure Python function. I found a few modules out there, but they seem to be all but abandoned. Most seem to have died several years ago. The most promising package is A.M. Kuchling's Python Cryptography Toolkit (http://www.amk.ca/python/code/crypto.html). Nice toolkit, more flexible and powerful than p3.py, but also more complicated. -- http://mail.python.org/mailman/listinfo/python-list
Re: Encryption with Python?
Blake T. Garretson wrote: I found a few modules out there, but they seem to be all but abandoned. Most seem to have died several years ago. a lack of recent releases can also mean that they just work... Is this the defacto Python encryption solution? What does everyone else use? Any other suggestions? http://sandbox.rulemaker.net/ngps/m2/ is actively maintained, as far as I can tell. you might also be able to find some useful stuff inside: http://trevp.net/tlslite/ (see the utils package for a pure-python AES implementation) /F -- http://mail.python.org/mailman/listinfo/python-list
Re: Encryption with Python?
In article [EMAIL PROTECTED], Paul Rubin wrote: Blake T. Garretson [EMAIL PROTECTED] writes: I found a few modules out there, but they seem to be all but abandoned. Most seem to have died several years ago. The most promising package is A.M. Kuchling's Python Cryptography Toolkit (http://www.amk.ca/python/code/crypto.html). Nice toolkit, more flexible and powerful than p3.py, but also more complicated. There's also http://www.freenet.org.nz/ezPyCrypto/ , built on top of PyCrypto -Steve -- http://mail.python.org/mailman/listinfo/python-list
