I know that there's really no good way to do this

You are right. Use HTTPS. Nothing that happens client side like Javascript is, or can ever really be secure. Well I suppose you could implement a public/private key protocol in Javascript but then....you would have SSL only much less well sorted and inevitably very slow.

There are only really 3 scenarios:

1. You are serious about it so you use HTTPS
2. You believe that anyone who specifically targets your traffic will know enough to sniff your traffic but won't have enough smarts to use the javascript decryption routine you intend sending to every client. Uh huh.
3. You believe that people randomly sniff HTTP traffic, scan for keywords and therefore some trivially reversible encryption offers protection.

Do yourself a favour. Use HTTPS.

"You believe that anyone who specifically targets your traffic will know enough to sniff your traffic but won't have enough smarts to use the javascript decryption routine you intend sending to every client. Uh huh."

You're making a poor assumption: that a) the routine is all that's needed to encrypt/decrypt (eg, no seeds/keys) and that b) the key is transmitted.

We don't know what the network situation is, he hasn't told us. As an example, RSA keypairs (server's public, client's private) might be included on an install CD. Then any correspondance using the javascript routine is fine; they can sniff away, and assuming high enough keysizes, well chosen keys, and a lack of quantum computers at hand, the traffic would be safe.

Also, a pet peeve: "You are serious about it so you use HTTPS." HTTPS by itself isn't enough. IE, for example, by default ships with 40-bit encryption. So one can make SSL connections that really aren't strong at all.

Lastly: "You believe that people randomly sniff HTTP traffic, scan for keywords and therefore some trivially reversible encryption offers protection." I don't know... last I heard, that's what Carnivore was supposed to do... so while I don't, for example, encrypt my connection to perlmonks, I certainly do to anything I believe is sensitive. Would AT&T route intranet traffic, unencrypted, through Bell's servers? Hardly! So again, we have the case of "we don't know how it's going to be deployed, and can't answer this." Heck, if I was Bell, and I knew that one of the servers I controlled was on a path between, say, a work-at-home AT&T employee and her office, I'd keyword-parse every byte sent out for "strategic" in a split second.

and I intend on telling the people who will be using this to only run it over a secure connection, but I'm realistic

It mean https

Usually you decide whether your stuff is accessable over http ot only over https.

update
ok then, let's ask Cap'n Steve: will you be able to enforce ssl / https?

pelagic

If you don't control the server (i.e. you're distributing the program) it might be a bad idea to give your users a fake sense of security when they should just upgrade to SSL instead. This is all assuming the security is actually needed, ofcourse.

Just to clarify: this is mostly a game of chance. Assuming you can find a javascript/perl based encryption that's theoretically just as secure as SSL, it has probably not been tested and fixed as well as say, the SSL implementations in Mozilla and Apache. As a side problem, a javascript implementation will not run as fast as native SSL encryption (it might be fast enough, though).

Just my €0.02
Joost

Use the https protocol. It is transparent in practice and uses real encryption.

• javascript
  • Javascript::MD5
  • Javascript::SHA1

md5 and sha-1 are hashing algorithms (unrecoverable), not cryptographic algorithms (decryptable). They produce a small digest which would be very difficult or improbable to reproduce with different content. You can't get your original data back. They're useful for verifying data in two places is the same data, including in crypto situations, but they aren't a protection for the data.

--
[ e d @ h a l l e y . c c ]

Yes, md5 and sha-1 are hashing algorithms :)(thanks)

Anyway, my point is use the CPAN. CPAN has implementation of many cryptographics algorithms. I picked one (rijndael) and googled for rijndael javascript and and found a javascript implementation.

Anyway, if I were the op, I would configure my server to not allow HTTP access to that program (only HTTPS).

MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"

I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).

** The third rule of perl club is a statement of fact: pod is sexy.

You might want to consider CGI::EncryptForm. You don't even need Javascript to make it work, just Perl.

Note that CGI::EncryptForm is only supposed to encrypt data that is send to the browser in a hidden field and then send back to the script, to ensure that the data is not compromised by the user. It doesn't, for instance, encrypt data entered in a textarea before it's send to the script.

It might be just what the OP needs, but I just wanted to warn that this is not a "full" encryption system.

"What should it profit a man, if he should win a flame war, yet lose his cool?"

Thanks, Joost! That is really useful information :)

Note that CGI::EncryptForm is only supposed to encrypt data that is send to the browser in a hidden field and then send back to the script, to ensure that the data is not compromised by the user

Encryption doesn't prevent the data from being "compromised" by the user. Source authentication (e.g. a message digest) does. There is no authentication in CGI::EncryptForm. It was plainly designed by someone with zero experience in cryptography. Do not use it.

Okay.. lost password, need to find it again.. but first..

The truth is this'd be useless, if it's going to be decrypted by Javascript then the person who's trying to break it has the source of how to decrypt it, and any key.

Whilst this may stop anyone who's a novice to web technologies it'd be laughed off by anyone who could break HTTPS.

If you're trying to provide some security for those who diregard advice and run it over HTTP then don't, it'd be a false sense of security and could result in fingers being pointed at you and your encryption when it all goes bad.

A better solution may possibly be to make it so your app checks whether it's running over HTTP or HTTPS and refuses totally to even consider doing secure things over an insecure connection.

--Molt.

There is a big increase in complexity with doing the encryption in the browser. The form requires JavaScript, limiting who can use it. You will need to develop and test solution. You will likely run into variations in JavaScript implementations. You will need to get the JavaScript and Perl implementations to talk.

Doing the encryption in the browser doesn't buy you much security. Public-key encryption is probably too complicated to implement in the browser. Not to mention it requires multiple messages to do a proper key exchange. The simplest solution is to put the key in the page. But then the key is visible to packet sniffers.

Yes, I'm intending this to be something other people will use, so I have no control over how they use it. I still haven't made up my mind whether to bother with the encryption (although I'm not sure if the false sense of security would be as much of a drawback as people think it would be), but thanks for the suggestions.