I don't mean to be harsh, but did you read the link that you gave (http://www.orst.edu/dept/honors/makmur/ ) or were you just feeling lucky with google? I don't profess to be a RSA encryption expert by any means, but it's quite clear that you encrypt using a known public key, and decrypt using the cipher's private key. This is one of the fundamentals of key-based encryption/decryption. Please keep reading if this isn't quite clear. Here's a encryption/decryption scenario of users sending emails, as I understand it: 1) You send an encrypted email to me by using my public key. You also include your public key for me to encrypt the message when I reply back to you. 2) I receive the message. Noone along the way is able to decipher the message unless they have my private key. When I want to view the message, I use my private key to decrypt it. 3) When I reply back to you, my mail program encrypts the message using your public key provided on your original message. 4) You receive the email message. Noone along the way is able to decipher the message unless they have your private key. When you want to view my reply, you use your private key to decrypt it. 5) and on and on.
Now this is the idea as I understand it. If I'm way off base, someone please set me straight ;) To relate this idea to using javascript for encryption/decryption, let's take a look at a scenario of client-side password validation as Jonah had originally specified. Let's make the example simple and say we have a variable defined in javascript (var passwd = "fdjX3!bc@") that represents an encrypted password. The user will be presented a form in which to enter a password. The javascript password variable will then be decrypted and compared to the password the user entered. In order for this decryption to occur, the javascript will need the private key that they password was originally generated with. Hence, the client will need access to the private key, which indeed makes the key a PRIVATE KEY THAT IS PUBLIC. Obviously, this is not good. Like I mentioned, there may be workarounds for this. But to have a pure client-side validation technique I think would be difficult to do. By all means, I hope this is wrong, because it would be very cool to see encryption/decryption done "securely" with javascript. --JC ----- Original Message ----- From: "Doug Melvin" <[EMAIL PROTECTED]> To: "Josh Chu" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; "Dynapi-Help" <[EMAIL PROTECTED]> Sent: Thursday, November 29, 2001 4:02 PM 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 algorithms > > like RSA, is that you have to have the public and private keys in order to > > perform the encryption/decryption. Encryption isn't the problem, since > you > > can encrypt the password or field just using the public keys. The 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 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 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 > > > > > _______________________________________________ Dynapi-Help mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dynapi-help
