Pow securewrite
From PlainOldWebserver
Contents |
Pow_securewrite()
DAVE please Don't implement this until I get the client side figured out and coded
As I was walking to work this morning I was thinking how can I do ssl on pow server. Then I realized that with POW you have access to both end of the connection so you don't need to use public key for message passing. You can use symmetric encryption to secure your connection. Lets think about how we can make this work.
Encryption Overview and Code
http://en.wikipedia.org/wiki/Symmetric-key_algorithm
"The disadvantage of symmetric-key algorithms is the requirement of a shared secret key, with one copy at each end."
But with Pow you are getting your own information so you have the key at both end.
Some Cipher's
http://en.wikipedia.org/wiki/Blowfish_%28cipher%29 BlowFish
http://en.wikipedia.org/wiki/Advanced_Encryption_Standard AES
http://en.wikipedia.org/wiki/Twofish TwoFish
JavaScript Blowfish http://aam.ugpl.de/?q=node/1060
JavaScript AES
http://www.movable-type.co.uk/scripts/aes.html
http://www.cs.eku.edu/faculty/styer/460/Encrypt/JS-AES.html
JavaScript TwoFish
http://home.versatel.nl/MAvanEverdingen/Code/
"This page includes an open source JavaScript implementation of the RC4, AES, Serpent, Twofish, Caesar and RSA ciphers."
Possible Implementation
For this to work the encryption needs to be on both the server side and on the client side.
On the server side the options menu would have "cryptography key" which the pow_securewrite() would use to encrypt each output.
On the client side the pow_secureread.js would be a conventional client side JavaScript program to do the encryption. The client side script would have you enter the "cryptography key" on the clients side.
In this manner you have the key on the server and on the client and you never had to pass the key over the internet so you content is secured.
Some Additional notes: It would be tempting to put the "cryptography key" in a cookie on the client side. And I will have to think of it more. But if your Pow server was at 123213.att.com I believe it would be vulnerable to anyone else who had an att.com domain. With Ajax or framed pages it would be trivial to keep the "cryptography key" in the main page so you don't have to re enter the "cryptography key" again and again. For conventional pages maybe there should be a starting page for the secured apps that then open a new window. All the child windows could then referr to the parent window for the "cryptography key".
Doh Just realized that this only handle server to client encryption. Need to do it both ways.
Obvsious it would be possible to encrypt every form submission and that might be the way to go which would be the other 1/2 of what i described here.
But maybe a more fancy solution is in order just creating a encrypted tunnel.
I will think on this more next time I am and not with the kids.
More to come:
Possible API
sjs commands
Pow_securewrite() -->> Outputs encrypted version of plain text String
Pow_secureread() -->> Outputs plain text version of encrypted string
js function
Pow_securewrite() -->> Outputs encrypted version of plain text String
Pow_secureread() -->> Outputs plain text version of encrypted string
On client side need a way to secure text of forms before they are submitted.
On client side need a way to identify part of page that needs to be decrypted.
