When I was working in a reasearch lab at a large hospital, we considered using SSL for protecting some non-anonymized patient information. We decided against putting those records on the web for a number of reasons. First was a general distrust of the SSL protocol. Versions 1 & 2 were designed by amatuer cryptographers, to protect credit card numbers. We considered patient records much more private than that. Next was the de facto 40 bit keysize of Netscape. We didn't want to try to teach surgeons the difference between the 40 bit crypto in the free version & the 128 bit in the pay for version. They were already convinced that Netscape was unbreakable encryption. (Fortunately, this was about 2 days before the random numbers got to the front page of the New York Times, so they believe me now.) The last reason was becuase I fully expect web servers to become the sendmails of the 90s. Big, badly configured, and used as a means of breaking into a server. Once someone breaks into a web server, all the encryption in the world won't help; those files need to be decrypted so they can be sent out under SSL's arbitrary keys. Adam | Some obvious proposals would be to use something like SSL to do server | to workstation encryption. I don't know what issues may exist such as | the effort to install SSL, key management, and processing delays due | to session keys and traffic encryption. In addition, how could an | on-call doctor access patient records through an ISP and maintain | patient privacy. An obvious issue (which I know have been discussed | on this list) has to do with the trade-off between key size and | privacy. | | Any other thoughts? | | Martin G. Diehl | -- "It is seldom that liberty of any kind is lost all at once." -Hume