First you need to generate a key pair. (Actually, it's four numbers: p, q, d, and e: p * q and e make the "public key" and p, q, and d make the "private key.") This is the slowest part. Pick how large a key you want. Larger keys are more secure, but take longer to generate, and somewhat longer to use (especially decrypting the orders). 512 bit key modulos (32 byte keys, ie p and q are 256 bits each) are still considered somewhat secure. My browser took about 3 minutes to generate a key of this size on my p2-450. Try a smaller one first, like 8 bytes and square that time twice to see how long it might take for you.
Encrypting the orders takes very little time, maybe a second or two, but those decrypting will notice a definate lag (7 seconds for me).
Note that many browsers require you to NOT cancel the script after it is taking a while to generate the keys. I've tested this on InternetExplorer 5 (win). If you find it works/doesn't work with another browser, let me know. I've been told that Netscape is much slower than Microsoft for this type of thing.
Generate a key pair. For example, when I did I got:
Put a copy of crypto.js on your hard drive and on the server. Then
add the following to your public script on your server:
And put the following in your private script (probably on your local hard
disk -- not on the internet -- if your private key is found this whole
thing is useless.)
Ok, so you might want to do something more interesting than just put the data into document.form.text.value (this assumes you have a <form name="form"> in your document, by the way).
Enjoy!
John
| 10/7/11 | Fixed a typo in the simplemod function that broke generation of larger keys. Changed the Crypto library to BSD License. Generating a 1024 bit (ie 64 byte x 2) key took 90 seconds in Firefox on my 2.67gz E7300 Intel cpu. Decrypting is 0.3 seconds. |
| 7/12/02 | I found a bug in the b2t function (crypto.js) which made odd key sizes fail. It's fixed I also changed the crypto.js rc4 to be more secure (especially with short keys) and to be compatible with the decryptor.py python script. Encryptions made with this version ARE NOT COMPATIBLE with encryptions made the old way. |
| 4/25/01 | I just found out about random.org and changed the seed function to take advantage of it. |
| 3/19/01 | Just for kicks I thought I'd try to generate a 960 bit (60 byte) key pair. On my p2-450 it took slightly more than 10 minutes to generate the keys, and decryption took 33 seconds. I'm happy. |
| 3/19/01 | added the entropy pool to the random number generator. This only
slowed key generation by < 10%, so I think it's worth keeping. |
| 3/11/01 | replaced decode's mod-exp call with optimized Chinese Remainder
Therom version; decodes are roughly 2x faster. NOTE: this means calling
interface for rsaDecode is changed. |
| 3/10/01 | replaced general slow radix function with simple optimized
versions for b2t, t2b, textToBase64 and base64ToText; this greately
accelerated encrypting longer strings |
| 3/10/01 | rewrote session key generation (again) |
| 1/25/01 | concluding massive rewrite including Maurer's provable primes and
Barrett's modular reduction; increased speed by 10 - 100 times |
| 1/3/01 | added sieve to prime number locator -- increasing speed lots! |