Re: OODL: Voting cgi - Problem
At 11:02 AM +1000 on 5/15/99, Adrian Sutton wrote: Anthony: Improper output from the CGI. Possible screwed up headers. These functions turn out to return under 1K of text though whereas the others are all over 1K. Could this be a problem? Anthony: I doubt it. Ever used telnet? (BTW: Since you say it is the problem, I'm betting it indicates a larger problem... a bug somewhere) I can send you the stack though. I'll look at it.
Re: OODL: Voting cgi - Problem
At 11:39 AM +1000 on 5/24/99, Adrian Sutton wrote: DeRobertis: Well, I guess you'll have to come up with a new password now. Adrian: It was only a randomly generated one anyway. DeRobertis: But _proving_ mathematicians wrong is so much fun! Adrian: Unless you happen to be the mathematician. :) Adrian: After reading up on RSA and other cryptography methods even more (I must have read over 1000 pages on cryptography so far and still don't fully understand it.) I'm beginning to get the impression that we cannot securely encrypt passwords while having the source code freely available. Read some more. You'll find that security by secrecy of algorithm is not secure. One reason is that no such thing exists once the stack is distributable: I can open it in BBEdit. If it's an xThing, I can disassemble it. real security depends on a near non-rersable algorithm. Adrian: I say this because 1) We need to use numbers larger than HC can deal with (100 digits or more) and That's why we should go to C++. Even an xThing would work. I'd suggest an algorithm like this: Each of us generates two 2048-bit numbers. That's not hard at all. Call them "a" and "b". Each of us sends the product of a and b (call that "ab") to the server. Each of us stores a and b. Whenever one needs to authenticate, he would send an a and a b to the server. The server multiplies and then compares. The only way to crack ab is to factor a 4096-bit value. And that is not possible to the best of anyone's knowledge with today's computers. We could get away with a and b being far less than 2048 bits, btw. 2) we need to add a few random numbers to the start or the end of the encrypted password so that encrypting the same text doesn't give the same answer unless you know how many digits to ignore (which everyone would because the source code is public). Hence we need a new way to determine if a vote should be counted. A) Any reasonably competant programmer could guess-and-check at ignored digits. B) We don't need ignored digits. See above. Adrian: I would tend to look towards some kind of email verification that is sent to the member who supposedly voted alerting them that they have voted (if it wasn't them we can do something about it), but we also need some kind of identification scheme before this message is sent. Otherwise we could be swamped with emails when we haven't voted and have to keep going back and changing things. Perhaps a password system like we have now, but somehow preventing access to the password file to be downloaded or viewed. We should certainly have email confirmation. I doubt we will very much need it with the system above, though. The source code can be gotten at http://www.erols.com/derobert/break.sit.bin If you want to use new numbers, you'll have to edit tab.pl. You'll then have to run "perl tab.pl tab.cp" Adrian: I've got it and I will try some other numbers, for now though I just get the message "MPW does not recognise the command perl" or something to that effect. I'd guess this means I need to find perl add-ons for MPW or adjust a global variable in MPW somewhere. Yep. You need to get the perl tool. Alternativly, you could use HyperCard to generate tab.cp. tab.cp is basicly a list of: (i+32)^e MOD k where i is the item number, ranging from 0 to (256-32). The perl code is some fancy work to "distribute" the modulous over the exponent. This avoids having to work with really large numbers.
Re: OODL: Voting cgi - Problem
DeRobertis: Well, I guess you'll have to come up with a new password now. Adrian: It was only a randomly generated one anyway. DeRobertis: But _proving_ mathematicians wrong is so much fun! Adrian: Unless you happen to be the mathematician. :) Adrian: After reading up on RSA and other cryptography methods even more (I must have read over 1000 pages on cryptography so far and still don't fully understand it.) I'm beginning to get the impression that we cannot securely encrypt passwords while having the source code freely available. Adrian: I say this because 1) We need to use numbers larger than HC can deal with (100 digits or more) and 2) we need to add a few random numbers to the start or the end of the encrypted password so that encrypting the same text doesn't give the same answer unless you know how many digits to ignore (which everyone would because the source code is public). Hence we need a new way to determine if a vote should be counted. Adrian: I would tend to look towards some kind of email verification that is sent to the member who supposedly voted alerting them that they have voted (if it wasn't them we can do something about it), but we also need some kind of identification scheme before this message is sent. Otherwise we could be swamped with emails when we haven't voted and have to keep going back and changing things. Perhaps a password system like we have now, but somehow preventing access to the password file to be downloaded or viewed. The source code can be gotten at http://www.erols.com/derobert/break.sit.bin If you want to use new numbers, you'll have to edit tab.pl. You'll then have to run "perl tab.pl tab.cp" Adrian: I've got it and I will try some other numbers, for now though I just get the message "MPW does not recognise the command perl" or something to that effect. I'd guess this means I need to find perl add-ons for MPW or adjust a global variable in MPW somewhere.
Re: OODL: Voting cgi - Problem
Anthony: Improper output from the CGI. Alain : Clarify what you mean by "improper". Are you getting the all-too-frequent "Document Contains No Data" message ? Anthony: Possibly screwed up headers. Alain : Depends on what protocol and software that you are using. For instance, CGI programs coded with HC do not have to generate the HTTP headers. WebSTAR takes care of all of that. Unless you configure your CGI as a PRE-processor and prefix its name with "nph-" -- note: "nph" stands for "non-parsed header". In this latter case, you do indeed have to generate a valid HTTP header. Adrian : These functions turn out to return under 1K of text though whereas the others are all over 1K. Could this be a problem? Anthony: I doubt it. Alain : I have had some difficulties when the returned response weighed more than 30K. Probably has something to do with TextEdit limit that limits our HC scripts to 30K, eh ! Anthony: Ever used telnet? Alain : You might want to try "DataComet for Telnet". It is a scriptable Telnet application that, among other things, allows one to remote control other servers. _ Do You Yahoo!? Free instant messaging and more at http://messenger.yahoo.com
Re: OODL: Voting cgi - Problem
Adrian: I have finished the voting cgi (except for properly handling non-ascii chars and without some features I'll add later) ... Alain : Good progress. Adrian : ... however when using Quid Pro Quo and Netscape Communicator 4.51, a couple of the pages give "The document contains no data errors" in Netscape. They work fine in Internet Explorer. Has anyone experienced this before? What causes it? Alain : Internet browsers are notoriously dissimilar. Some HTML features that are supported by Netscape are not supported by Explorer, and vice-versa. Anthony: Improper output from the CGI. Possible screwed up headers. Adrian : I'm not sure how this could happen, the CGI is written in HyperCard and all I/O is handled from the AppleEvents handler which calls functions to create the HTML and return it. Alain : That's how I used to do it. It should work like a charm. Adrian : It works for all but two functions. These functions turn out to return under 1K of text though whereas the others are all over 1K. Could this be a problem? Alain : I doubt that it has anything to do with SIZE. Adrian : How do I fix it? Alain : Send me your stack, Adrian. Anthony: Give me a URL and I'll try and see what's wrong. You'll need to telnet into the server on port 80, send your own HTTP request, and then look at the output. Alain : There are other ways of testing CGI programs. Adrian : I can't give you an URL that you can access as it is on an internal server only. I can send you the stack though. Alain : OK, send me the stack. Your CGI will sooner or later be run from here in any case. _ Do You Yahoo!? Free instant messaging and more at http://messenger.yahoo.com
Re: OODL: Voting cgi - Problem
Adrian: I have conducted some more tests on the Voting cgi (that I should have thought of before posting sorry), and have discovered that the problem is the small size of the pages being returned. When I make the pages longer (greater than 1k) it works perfectly. Adrian: I am still looking for an XFCN to decode URL encoding. DeRobertis gave me one that will encode for HTML and it works well now thanks.
Re: OODL: Voting cgi - Problem
Adrian: I have finished the voting cgi (except for properly handling non-ascii characters and without some features I'll add later), however when using Quid Pro Quo and Netscape Communicator 4.51, a couple of the pages give "The document contains no data errors" in Netscape. They work fine in Internet Explorer. Has anyone experienced this before? Anthony: Yes. Adrian: What causes it? Anthony: Improper output from the CGI. Possible screwed up headers. I'm not sure how this could happen, the CGI is written in HyperCard and all input and output is handled from the AppleEvents handler which calls functions to create the HTML and return it. It works for all but two functions. These functions turn out to return under 1K of text though whereas the others are all over 1K. Could this be a problem? How do I fix it? Anthony: Give me a URL and I'll try and see what's wrong. You'll need to telnet into the server on port 80, send your own HTTP request, and then look at the output. I can't give you an URL that you can access as it is on an internal server only. I can send you the stack though.
