Memo from Martin P Burns of PricewaterhouseCoopers -------------------- Start of message text -------------------- Norman I don't know about the AspEncrypt component specifically, but this sounds like a public/private key architecture, the architecture used by PGP and others. The thinking goes like this: Traditional codes had a single key - an algorithm which let you decrypt the message. For a simple Caesar cipher, this is "Move all letters 2 places on through the alphabet, wrapping round when you reach the end". For more complicated encryption, it's vastly more complicated than this, but the key gives an enormous shortcut in the analysis of the ciphertext to permit decryption in a very short (few seconds) time, compared to the long (thousands of years) time required for a brute force attack. A single key has one enormous problem though - how do you securely transmit the key so that the bad guys between sender and recipient can't intercept and use your key to find your your l33t 53crets *ahem* I mean confidential info? With a bit of mathematical cleverness eg involving very large prime numbers it's possible to produce a non-reversible encryption algorithm. This is how passwords are stored - permanently encrypted, so all you have to do is encrypt the attempted entry and compare the 2 ciphertexts. This is why your sysadmin will tell you "I can't retrieve your forgotten password, but can set a new one for you". Algorithms like MDA5 fall into this category - there's a JS version of this somewhere online - and the Unix commands 'crypt', used for producing .htpasswd files: http://evolt.org/article/list/18/226/evolt.org#c With a bit more mathematical cleverness, you can produce an encryption algorithm which outputs a ciphertext which can be decrypted by a related but different (and non-deducible from the first) algorithm. This makes life very easy, because you can distribute the first algorithm (your public key) far and wide, to enable anyone to encrypt text destined for you, knowing that the only algorithm which can decrypt it (your private key) is held secure by you, and doesn't go anywhere. Your public key or certificate is the one you put on the webserver - it introduces a very-very-close-to-zero-and-insignificantly-low level of additional risk and allowes the webserver to encrypt emails before sending them to you. If the server is cracked, or your ftp session snooped (Mmmm secure ftp and SSH), you don't need to worry because it's your public key you're putting there. Life gets a bit more complex if you want your site to digitally sign emails - this requires your private key, and it's not something you really want on your server. The only compromise is if you create a private key especially for the site, with a short expiry time, and keep a *very* sharp eye out for attacks on the box. Cheers Martin Please respond to thelist at lists.evolt.org Sent by: thelist-admin at lists.evolt.org To: thelist at lists.evolt.org cc: Subject: [thelist] AspEncrypt I was wondering if anyone had used the AspEncrypt/AspEmail component combination for sending encrypted emails? I've got to send credit card details via encrypted emai from a site hosted on innerhost and this seems to be the way to do it. I've visited the site for AspEncrypt and it seems to suggest that I need a copy of the recipients certificate on the server I'm sending the emails from. Is this correct? --------------------- End of message text -------------------- The principal place of business of PricewaterhouseCoopers and its associate partnerships is 1 Embankment Place, London WC2N 6NN where lists of the partners' names are available for inspection. All partners in the associate partnerships are authorised to conduct business as agents of, and all contracts for services to clients are with, PricewaterhouseCoopers. The UK firm of PricewaterhouseCoopers is authorised by the Institute of Chartered Accountants in England and Wales to carry on investment business. PricewaterhouseCoopers is a member of the world-wide PricewaterhouseCoopers organisation. ---------------------------------------------------------------- The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.