What's the simplest way to perform public key encryption?

Question

I'm applying for a job and they asked me to send my SSN to them over e-mail. Call me paranoid, but that doesn't sit well with me.

So, I'm looking for a simple form of public-key encryption that a non-technical HR person could generate a public-key, send it to me, I could encrypt my SSN, send it, then the HR person could decrypt using their private key.

Perhaps something like this website http://travistidwell.com/jsencrypt/demo/index.html but in this site, the encryption doesn't work without the private key (base and modulus... are probably regenerated)

Answer 1

Use a website like https://www.igolder.com/PGP/generate-key/ to generate PGP public and private keys. Have the HR person send you their public key. With their public key encrypt your SSN, then send it to the HR person who can then decrypt it with their private key.

Answer 2

What's the simplest way to perform public key encryption?

Simplest for whom? I guess you mean for the person from the HR department. The easiest protocol that I see that can be implemented so that they only need to access the website twice without any additional actions on their part.

You would need to build a non-static site on your personal server where you are reasonably sure that the server provider is not looking on the server's hard drive.

Let's see the steps (implementation details are interwoven with the protocol):

1. Generate two cryptic URLs on your server and send the first URL to the HR person (recipient from now on). You ask the recipient to call you once they clicked the URL.

2. The recipient clicks the URL and a number of things happen:

   • The server checks whether this URL was requested before and will show an error if it was. In that case, this process must be initiated again.

   • If this is the first time that URL is called, the JavaScript generates a key pair (public+private).

     • The public key is sent to the server and stored there and the private key is stored in the localStorage in the recipients browser.

     • Additionally, the recipients browser generates a random string (called token), stores it in localStorage and sends it to the server where it is stored.

3. Now, the recipient calls you. At that time, you ask them whether there was an error. If there wasn't one, you need open the second cryptic URL that you generated in step 1. This cryptic URL is linked to the information that was received from the recipient in step 2 and contains a form where you can type in your SSN.

4. The SSN is encrypted with the stored public key and the ciphertext is published to a third cryptic URL that is based on the token from step 2.

5. You ask the recipient to click the link again and receives an error page, but this error page is quickly hidden, because there are additional values in the localStorage which means that it is a legitimate request. The recipient's browser does the following:

   • It fetches the token from localStorage and queries the ciphertext.

   • It fetches the private key from localStorage and decrypts the ciphertext.

   • It displays the SSN.

This protocol solves the issue that the SSN is never stored in cleartext on the server and if anybody would have clicked the link before or after the intended recipient, they would see nothing. Although, this might be still vulnerable to SSL interception by a malicious hoster and there are entry points for social engineering.

You could improve that a bit by using long-polling or web sockets if you don't want the recipient to click the URL a second time.

---

If you mean simplest for you, then you either need to compromise security or go to their offices in person.

---

You shouldn't use JSEncrypt for that. It would be hard to integrate it here. You should either go for forge (provides RSA and everything around it) or sjcl (provides ElGamal encryption through KEM which would need to be implemented together with AES-GCM; so also not really easy).