I was expecting criticism; as is unavoidable with all crypto issues.
You asked many questions, and unfortunately all you missed the
auth="verisign" argument, which _is_ enough to prevent all practical
(,even if they are all theoretical!,) man-in-the-middle attacks.
<html>
<head>
<meta encrypt pubkey="ABABAEFEF2626EFEFEF" pubtool="EC256-AES"
passsalt="colordev.com" auth="verisign"/>
</head>
<body>
<form method="post" action="<?php echo $_SERVER['PHP_SELF']; ?>">
Username: <input type="text" name="user" /><br />
Password: <input type="password" name="password" />
<input type="submit" value="Submit" /><br />
</form>
</body>
</html>
the above 'page' using the meta-encrypt tag, which is enough for a
client browser to submit to site
a) a salted password
b) and a user name transported in encrypted form; over the internet
Maybe someone can show a _complete_ alternative Javascript & https
solution about how those can be achieved in a computer or PDA-device
without javascript support.
I am not suggesting replacing https with anything, government and
business sites can and should keep on using it. I am suggesting a
small easy to use mini-encryption which would be enough for those 90%
of sites should salt their passwords and encrypt sensitive data and
but who currently aren't.
question 1:
The server has to read and correctly parse each HTML page to decide
whether to encrypt it? (And how does the browser know that the page is
encrypted, vs. a legacy server that doesn't encrypt?)
answer 1:
Most servers are already configured to read the requested pages before
submitting those over the internet. For example my above form-page has
a small php-script inside which the server program must notice; as the
PHP-program needs to compile the script. Client never sees the <?php
echo $_SERVER['PHP_SELF']; ?> part but is instead shown an URL. To
implement meta-encrypt tag would just require (on/off) configuring
server program to read the header of requested page and see if there
is a meta-encrypt tag in there the server calls a program which
decrypts! the client submitted data.
Obviously you people will keep complaining, so what do you want to
complain next
1) Man-in-the-middle problem; which doesn't exists because
a) those are just academic mind games
b) if auth="verisign" is used as external CA
2) HTTPS = good (even if it is typically NOT used with forms
3) password salting = webmasters duty to do it (which 50% forget),
after using the HTTPS (which 90% forget)
4) Declaring encrypt action doesn't fit into HTML (; then why is there
a form method get/post)
Juuso Hukkanen
www.colordev.com
