I think this could work: - All javascript would be held in an encrypted strings. This encryption will have taken place on the server.
- The password would evaluate to the Private Key. - If the correct password is entered, the javascript is decrypted and exectuated using eval(). - If the incorrect password is entered, then the javascript cannot be decrypted and the user has no access to the system. > -----Original Message----- > From: Darío Vasconcelos [SMTP:[EMAIL PROTECTED]] > Sent: Thursday, November 29, 2001 10:58 PM > To: Dynapi-Help > Subject: Re[2]: [Dynapi-Help] theoretical javascript question > > Josh, > > I absolutely agree with you. But there's one case where you would want > to encrypt the e-mail with your private key: whenever you want to > "sign" your message, that is, when you want the receiver to > acknowledge that you're the one that sent the e-mail, since nobody > else in the world has your private key but you. > > Actually, I've heard that a double-encryption scheme can be used in > this cases: I can encrypt my text with my private key and then encrypt > it again using your public key. That way, the only one that could read > the message would be you and the only one that could have composed it > would be me (you would decrypt the text first with your private key > and then with my public key). > But this last paragraph wasn't interesting to the discussion. Please > ignore it :-) > > BTW, I visited the URL that James Sloey posted and I must say that it > is very impressive. I guess the secret is that the scheme is > simmetrical, as opposed to RSA, and the password is never included in > the message. But i still can't imagine how to adapt this to > authorization/authentication. > > Regards, > > Dario > > JC> I don't mean to be harsh, but did you read the link that you gave > JC> (http://www.orst.edu/dept/honors/makmur/ ) or were you just feeling > lucky > JC> with google? I don't profess to be a RSA encryption expert by any > means, > JC> but it's quite clear that you encrypt using a known public key, and > decrypt > JC> using the cipher's private key. This is one of the fundamentals of > JC> key-based encryption/decryption. Please keep reading if this isn't > quite > JC> clear. > JC> Here's a encryption/decryption scenario of users sending emails, as I > JC> understand it: > JC> 1) You send an encrypted email to me by using my public key. You also > JC> include your public key for me to encrypt the message when I reply > back to > JC> you. > JC> 2) I receive the message. Noone along the way is able to decipher the > JC> message unless they have my private key. When I want to view the > message, I > JC> use my private key to decrypt it. > JC> 3) When I reply back to you, my mail program encrypts the message > using your > JC> public key provided on your original message. > JC> 4) You receive the email message. Noone along the way is able to > decipher > JC> the message unless they have your private key. When you want to view > my > JC> reply, you use your private key to decrypt it. > JC> 5) and on and on. > > JC> Now this is the idea as I understand it. If I'm way off base, someone > please > JC> set me straight ;) > JC> To relate this idea to using javascript for encryption/decryption, > let's > JC> take a look at a scenario of client-side password validation as Jonah > had > JC> originally specified. Let's make the example simple and say we have a > JC> variable defined in javascript (var passwd = "fdjX3!bc@") that > represents an > JC> encrypted password. The user will be presented a form in which to > enter a > JC> password. The javascript password variable will then be decrypted and > JC> compared to the password the user entered. In order for this > decryption to > JC> occur, the javascript will need the private key that they password was > JC> originally generated with. Hence, the client will need access to the > JC> private key, which indeed makes the key a PRIVATE KEY THAT IS PUBLIC. > JC> Obviously, this is not good. Like I mentioned, there may be > workarounds for > JC> this. But to have a pure client-side validation technique I think > would be > JC> difficult to do. By all means, I hope this is wrong, because it would > be > JC> very cool to see encryption/decryption done "securely" with > javascript. > > JC> --JC > > JC> ----- Original Message ----- > JC> From: "Doug Melvin" <[EMAIL PROTECTED]> > JC> To: "Josh Chu" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; > JC> "Dynapi-Help" <[EMAIL PROTECTED]> > JC> Sent: Thursday, November 29, 2001 4:02 PM > JC> Subject: Re: [Dynapi-Help] theoretical javascript question > > > >> uh, private key? the private key is PRIVATE.. > >> you use the public key to decrypt. > >> > >> Simply put, aside from SSH and SSL, I don't believe you will find a > better > >> solution. > >> Sorry. > >> That is just _my_ opinion tho. > >> :-) > >> ----- Original Message ----- > >> From: "Josh Chu" <[EMAIL PROTECTED]> > >> To: "Doug Melvin" <[EMAIL PROTECTED]>; > >> <[EMAIL PROTECTED]>; "Dynapi-Help" > >> <[EMAIL PROTECTED]> > >> Sent: Thursday, November 29, 2001 4:58 PM > >> Subject: Re: [Dynapi-Help] theoretical javascript question > >> > >> > >> > Again the problem , especially with using key-based encryption > JC> algorithms > >> > like RSA, is that you have to have the public and private keys in > order > JC> to > >> > perform the encryption/decryption. Encryption isn't the problem, > since > >> you > >> > can encrypt the password or field just using the public keys. The > JC> problem > >> > lies when you need to decrypt the cipher, which requires using a > private > >> > key, which is really hard to make private if you have a .js file out > on > >> the > >> > web that contains this key. To make this more clear, if you have a > >> > javascript program that is running on a users browser, then to > decrypt a > >> > cipher, that program will have to read the private key from somewhere > on > >> the > >> > web. Hence, anyone who can run this javascript can also do view the > >> > private key necessary to decrypt the cipher. Obviously this is not > very > >> > secure. I guess one workaround for this would be to store the private > JC> key > >> on > >> > the client (via a cookie -- document.cookie manipulation) and always > >> decrypt > >> > using the private key stored on the client. I've never attempted > this > >> > however, so if you can get a prototype working, that would be very > >> > interesting. > >> > --JC > >> > > >> > > >> > ----- Original Message ----- > >> > From: "Doug Melvin" <[EMAIL PROTECTED]> > >> > To: <[EMAIL PROTECTED]>; "Dynapi-Help" > >> > <[EMAIL PROTECTED]> > >> > Sent: Thursday, November 29, 2001 3:07 PM > >> > Subject: Re: [Dynapi-Help] theoretical javascript question > >> > > >> > > >> > > two words: > >> > > RSA encription. > >> > > http://www.orst.edu/dept/honors/makmur/ > >> > > > >> > > ----- Original Message ----- > >> > > From: "Jonah" <[EMAIL PROTECTED]> > >> > > To: "Dynapi-Help" <[EMAIL PROTECTED]> > >> > > Sent: Thursday, November 29, 2001 2:31 PM > >> > > Subject: [Dynapi-Help] theoretical javascript question > >> > > > >> > > > >> > > > Would it be possible, in theory, to securely validate a password > >> client > >> > > > side? > >> > > > > >> > > > Obviously, simple string matching would not work because the > client > >> > could > >> > > > view the source to find the correct password. > >> > > > > >> > > > But I have this vague notion (my upper level math skills are very > >> > rusty): > >> > > > > >> > > > Parsing the password up into characters perhaps, converting the > JC> chars > >> > > > to numbers, and then passing the numbers into the variables of a > set > >> > > > of non-linear equations that must be solved simulataneously (in > >> > > javascript, > >> > > > a set of functions that must return true simultaneously). I have > no > >> > idea > >> > > > how you could generate the necessary difficult-to-solve set of > >> equations > >> > > > given a particular password, but am curious to know if such an > >> approach > >> > > > is viable even in theory. Anyone have any ideas? > >> > > > > >> > > > Thanks, > >> > > > Jonah > >> > > > > >> > > > > >> > > > _______________________________________________ > >> > > > Dynapi-Help mailing list > >> > > > [EMAIL PROTECTED] > >> > > > https://lists.sourceforge.net/lists/listinfo/dynapi-help > >> > > > >> > > > >> > > _______________________________________________ > >> > > Dynapi-Help mailing list > >> > > [EMAIL PROTECTED] > >> > > https://lists.sourceforge.net/lists/listinfo/dynapi-help > >> > > > >> > >> > > JC> _______________________________________________ > JC> Dynapi-Help mailing list > JC> [EMAIL PROTECTED] > JC> https://lists.sourceforge.net/lists/listinfo/dynapi-help > > > > -- > Best regards, > Darío mailto:[EMAIL PROTECTED] > > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > > _______________________________________________ > Dynapi-Help mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dynapi-help _______________________________________________ Dynapi-Help mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dynapi-help
