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
