Why do we need another shopping cart? Here's what this project is about:
When I feel like I have the project stable I'll put it in a .ZIP archive and upload it. Until then, the files from the cart demo are really all you need:
I'm so glad you asked. JavaScript's use of cookies makes tracking simple interactivity, like a shopping cart, easy. What's more, its rudementary math and array handling give enough tools to do relatively secure encryption WITHIN THE BROWSER.
Making a cart which tracks items is quite easy -- there are many interesting JavaScript shopping carts.
Making a cart which can encrypt the order -- that's new.
How does it work?
The mathematics behind RSA public key encryption have been well known for years, and now with RSA's opening of the copyright, we can use them in this type of application. There are many articles documenting the mathematics behind RSA, so I won't repeat those here. I have written simple functions to do arbitrary-precision math (ie math with really big numbers) and functions which use these to securely encrypt orders using the programming language buit into nearly every web browser on the Internet today.
See the crypto demo to see how fast it is on your browser, but for most people, encrypting an order with a safe key can be done in 1 or 2 seconds. Decrypting takes a bit longer: 5 to 30 seconds depending on the speed of your computer and how large a key you've chosen.
As for security, there's two issues: key size and the "man in the middle" problem. Most RSA programs today use from 1024 to 2048 bits for encoding today. Occasionally you can still find 512 bit programs. I've found 512 bits (32 byte p & q) completely functional with this program, and I'd think it's reasonably safe: During the a recent RSA challenge (August 1999) a 512-bit digit was factored. This required 35.7 CPU-years distributed on 292 workstations and high-speed computers, plus a massive amount of storage for intermediate results. Calendar time was 3.7 months. This considerable effort has to be repeated for each RSA key to crack. This means that a 512-bit RSA key can be cracked -- if it is worth spending so much resource.
If decrypting time isn't important to you, or you have a very fast computer, 1024 bit keys (64 byte p & q) will work nicely, or you can go as high as you want.
These algorythms encode a random session key. This session key is used with RC4 to encrypt the message. The session key is the same length as the RSA modulo, so a 512 bit modulo will generate a 512 bit session key for use with the RC4 / ARCFOUR encryption algorythm.
The other problem is the "Man in the Middle" attack. For our purposes this means that either Evil Hacker breaks in to your http server and replaces your public key and delivery mechanism with his own or he modifies your IP packets on the fly to the same effect. SSL prevents this by Thawte or VeriSign signing your server certificate (for a price), but because my crypto routines don't include a transport protocol, there's no practical way to verify authenticity. I think this is an acceptable risk for most of my situations. However, owners should keep an eye on their files to verify that Evil Hacker hasn't done his/her mischief.
So, (if you're paranoid) no, it's not really secure, but yes, it is on a par with what you find elsewhere.
I intend to have it checked by cryptography experts when I'm done tweeking it. It hasn't yet been verified though. Watch the project news and I'll post when it's verified. Know any cryptography experts who want to verify my work?
updated 2/9/05