Slashdot Mirror
Ask Slashdot: How Do I Request Someone To Send Me a Public Key?
First time accepted submitter extraqwert writes "An organization wants me to send them my personal data by email. I certainly do trust them. However, I would like to politely ask them to send me their public key for encryption. The secretary probably does not know what it is. But they do have a pretty good IT department, so they can figure out. My question is, what is the proper wording for such a request? What is the right terminology to use? Should I say ``please send me your RSA key''? ``Public key''? ``PGP key''? Is there a standard and reasonable wording for such a request? (On my end, I am using GNU PGP: http://www.gnupg.org/ ) Any suggestions on how to be polite in this case?"
Simple and expected processes like this need to be made truly dead simple and nearly automatic. Instead, there are a ton of different formats for keys depending on which the usage and you need to understand a significant amount about what's going on under the covers to do even these kinds of simple actions.
Incidentally, here's the answer to the question. It's anything but clear, but likely to be clearer than any answer you get here.
Ask the secretary 'could you please ask your IT department for your' and then use any term, since they'll know.
Let's put the genes back in Genesis.
Check if they already offer encryption by looking for a key linked to their public e-mail address on a keyserver. If not, just politely ask whether they offer encryption. Tell them what kind of encryption you support (afaik S/MIME and PGP are the standards). Send them your public key (or point them to keyservers.) Ask whether you can use snail mail if they don't offer encryption. That's what I do, and sometimes it even works :)
The recipient will decrypt you data and lose it or possibly misuse it. That is the risk. But by all means ask for a secure way to get the data to them.
http://michaelsmith.id.au
... and since this data is sensitive and personal I'd like to encrypt it before sending to you, to ensure it is protected against unauthorized access from 3rd parties.
What is your preferred encryption method to use for this?
Best Regards,
bla bla bla
This lets them name their method (if they have any); if they don't know you could point them to the PGP website (... could you ask in your IT department what encryption is preferred/used? bla bla bla widespread use of PGP bla bla bla)
Having a pretty good IT department doesn't mean the companies end users have PGP.
I would ask for their "PGP Public Key" with a note that says if they don't understand what that means to please forward the email to their IT Department.
Then if you get the public key, and you send the data, leave another note in the plaintext portion that says if they don't understand what all the jibberish is to ask their IT Department for help opening the email.
If the secretary can find somebody to decrypt your info, she will handle it improperly. Probably scan it directly to their compromised CMS. This is not a company you want to work for.
Help stamp out iliturcy.
Attend or organize a key signing party.
Questions raise, answers kill. Raise questions to stay alive.
If they need the information they should have a secure way to receive it. I just refinanced, the broker had a secure site (SSL password protected file vault type interface hosted on their own servers) with a web interface that I could upload documents to.
If they don't have such a system in place already and routinely request and access peoples personal information your trust is severely misplaced.
How Do I Request Someone To Send Me a Public Key?
I prefer signal fires myself.
If IT sets it up, won't they have the key?
PGP is beyond the grasp of the average secretary or other end user. Unless you know for a fact that the person disseminating the data is familiar with PGP; you should probably not be asking them for their public key.
I strongly recommend an encrypted PDF, Word Document (.DOCX), or Excel file (.XLSX); make sure to choose a strong password.
I like the Office 2010 strong encryption and use of key stretching to make brute force password attacks hard --- but there is a free of charge reader available for PDF documents, and you should pick a strong password for encrypted documents anyways.
Technically, you could implement DRM rights management services on your end, so the user has to contact your organization's RMS server over HTTPS for a license every time the document is opened, but it requires a trust relationship between orgs, or you having an account for the user.
But the simple password protection is a very nice way to protect it. You can include a note in the e-mail message that you will be calling them to give them the password, so they can see the document.
Then there is no confusion about what a 'PGP key is'. If you _regularly_ exchange a lot of documents with them, then you might ask to discuss using PGP
I ran into this situation very recently, im in the process of buying a house. It was a bit of a shock to me how much personal information they wanted. And most through email. And how my data is being passed along from business to business without good security.
I use good practices on my side like two factor authentication, and ssl on everything, even a bit of pgp. But the other side who knows.
You are better off just asking for "A secure means to submit your information" and list a few you are happy to use, Maybe they will send you a public key for secure email, maybe a secure web site or maybe they will just say if you are concerned you can get it couriered to them. If they are confused then chances are they have no system in place for dealing with the request and hence not even secure email is any good as that only protects the data in transit which they will certainly load into some HR system somewhere after it gets there anyway.
Just compress your data in a zip file and protect it with a reasonable long password. Send it by e-mail and communicate the password to the recipient by phone.
You won't have to explain anything other than the receiver of the communication, it is easy and the receiver will have the means to decrypt the zip file for sure.
If you don't have the social skills to phrase a polite question, Slashdot is perhaps not the ideal place to go looking for advice...
Technical issues with giving anyone your private key aside (I can't think of any reason to give it out to someone no matter how much you trust them) just explaining things clearly should work for any reasonable person:
"I have no problem with you having my personal key, but I am concerned about the integrity of the data while in transit. I would appreciate it if you can supply me with a public key for your organization, then I will be able to encode my key so that only you can decode it. This will ensure that our mutual privacy won't be at risk due to using an insecure communication system such as Email. Thanks very much!" etc
Perfectly Normal Industries
Ten years ago, my company had a policy to use PGP and Symantec PGP software installed on all computers. Even the engineers had issues and failed to use it regularly. I remember having to logmein to machine in China to try to figure out why they couldn't read an email with our designs. This is why PGP never took off.
Until the tools take 5 min to setup. And encryption/decryption is as easy as clicking a checkbox in your mail client, PGP will never take off. Things like the public key directory have to handled transparently to the user.
It's too bad Mozilla dropped support for Thunderbird. Tight integration with GnuPG + cloud public keys could have made mainstream PGP a reality.
-----
Every recipient has his or her own private/public key pair. You send an encrypted message to one (or more recipients), and they will be able to read it, nobody else.
The easiest way to get someone's public key is to convince them to send you a signed message. That is, if your email software can handle it. A signed message contains the sender's public key, and hopefully your email software allows you to stash that key away (automatically) and from then on send encrypted messages to that person.
Chances are that they have private/public key pairs that use a company root certificate, so you wouldn't be able to verify that certificate, which might throw a spanner in the works.
If you don't use GPG...
(photo of a lock and key)
FUCK YOU!
I'm sorry to say, but the simple fact of the matter is that PGP/GPG isn't used anywhere in corporate life. Not even in banking-related companies.
For one, people don't perceive email as something that can easily be snooped, and if they do they'll think it's something like a chance encounter as if it's a regular piece of mail where you have to be at a certain point at a certain time to be able to snatch the mail, plus have to have a reasonable idea what you're looking for as a mail thief.
Secondly, and I cannot stress this enough, it's a f'ing drag to use. It's not easy to install. It's not easy to set up, and it's far from user friendly on a day to day basis.
Besides the fact that email encryption isn't commonplace, as long as you aren't sending you pin number or medical data on a regular basis (daily), why bother to be honest. You'll get a stamp as "that weird guy" if you start about PGP etc, and that'll last. If you want to send it securely, just wrap it in an encrypted container, like a ZIP or RAR file and phone them the password.
Manuals are your last resort only
At least with GPG/PGP you can roll a key with no effort and there are public key servers to upload the public key. Persuading someone else to generate such a key and use it is another matter. Probably needs a strong business case which can be impressed on the other person.
I seems doubtful that anyone but the IT department would have any idea what you are asking for, who probably wouldn't want to deal with you directly without direction. You could ask them to liase you to the IT department, that might get things going.
Or send a physical disk. Unless you're worried about the courier being jumped, it's probably quite safe.
"An organization wants me to send them my personal data by email."
"But they do have a pretty good IT department"
No. They don't. Or their IT department is seriously underpowered in terms of getting through to their staff. Don't send personal data by email. If they don't have a system to let you do this (e.g. secured web form, etc.) then their IT department is already a bit of a failure. If they do, their staff would use it and tell you about it.
If you want to ask, just ask. "I'm not going to send personal data by unencrypted email - what is your procedure for encrypted email?"
Chances are, they won't have one and will just ask you to send the details unencrypted or by another method entirely.
Put it on google docs and share it to them from there.
Use a fax. No, it's not encrypted in transit, but it would likely be more _actually_ secure, as opposed to spending so much time trying to get PGP setup and then screw up something basic... not to mention, people actually know what they are.
Robert Clayton Dean: What the hell is happening?
Brill: I blew up the building.
Robert Clayton Dean: Why?
Brill: Because you made a phone call.
- http://www.imdb.com/title/tt0120660/
Who cares? That data will end up in a NSA datacenter anyway.
I don't see why you should be concerned about the request or how "polite" it is. A simple statement to the effect that "I do not send personal information over the Internet without encryption. Please send me instructions as to how your company handles encrypted email. My preferred method is GnuPG, and this will be the quickest and easiest way from my end, but I can try to accommodate other methods."
Create folder, then put the relevant documents into that folder and wait for them to sync. Get person on the phone... "What's your email address?" Share folder with them and tell them they will have 30 minutes to download it. Remove their access to the folder - rinse and repeat to new person(s) as required. Unless you actually want to provide the document in a protected format, this avoids all issues with software compatibilities and is pretty secure, except for what the recipient might do with it after they have it, but then if they have been able to decrypt it with their personal key, then they could take screenshots if nothing else to compromise your security...
Most people are too lazy and confused to use a public key cryptosystem. They need motivation to use their brains. The standard way to motivate lazy people is to pay them to lift a finger to push a few buttons.
You must be pretty new to the business world. I've had a PGP/GPG key ready to use since 1995. You know how many times I've used it for anything less security critical than the company's main password list? None.
The front desk girl is just going to ask her boss what the heck you're talking about, and he's going to tell you where you can stick your key. You will look like a crackpot trying to get them to secure your social security number with GPG. Just let it go and fight some real battles that you can win.
We need some developers to setup-in and develop in-browser Firefox/Chrome extensions (or userscript, or whatever) that seamlessly integrate encryption into popular webmails.
You see plain text on the screen, but what actually goes into the "textarea" of the form is encrypted.
There are already javascript "Rich Text Editors" which do similar jobs (you see a nicely formated text on the screen, but its HTML/BBCode/WikiCode going into the textarea). We simply need something similar, but for encryption and packed into the browser itself through extension mechanisms.
(Note: Proper security comes from *end to end* encryption. It's therefor mandatory that the encryption/decryption layer is something that the end users install on their browser, and not something provided by the webmail site, even if it's client-side script code. Though it would help if webmail sites provided a few hooks or micro format to simplify the plugin of the encryption layer).
Bonus point if someone else manage to do the same with OTR and webchats.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
this is really important. people who don't know what ssh keys are will typically send you the id_rsa (private) key file.
IT IS VERY IMPORTANT that you say to them EXPLICITLY and VERY CLEARLY, "please send me the public key file *only*. DO NOT send me the PRIVATE key. you can identify the private key because it is named xyz. i ONLY want you to send me the PUBLIC key, it is named xyz.pub. if you send me the private key, you will have to destroy it and we will have to start again, so ONLY send me the PUBLIC key, ok?"
and get them to acknowledge what you've said. do not be afraid to "piss them off" by having to be so absolutely specific. make sure you end the sentence with what you *want* them to do, *not* what you *don't* want them to do. depending on the person they could potentially remove the "negative" by their subconscious and do exactly what you ask... with the words "no", "not", "don't" etc. removed.
also if you want to be paranoid then use the signature-thing (fingerprint). get them to read it out to you over the phone (not by email).
This is one of those Slashdot stories where I wish there was a "and they all lived happily ever after?" button on the story where we could all get an instant link to a paragraph or two about how the story finally turned out... because my money is on "they told me to fax it, so I visited the dumpster behind the Smithsonian, found an old fax machine, and sent it to them". It would have been helpful if you could have specified what size of organization (two guys and a lhasa apso? six billion dollar multinational?), and what the relationship is - are you a client? a prospective employee? illegitimate father of the CEO's daughter's new baby? Are you sending them your social security number, DOB and such, or are you sending them the biometric information they need to disarm the nuclear bomb you planted in their cafeteria? The answers to those questions constrain variables like a) the actual value of this private information to the outside world, b) the degree to which the company will feel exposed to liability risk if your data is leaked in transit, and hence their motivation level for doing something about it, c) the likelihood that they actually have a formal key exchange infrastructure in place, d) the likelihood that there is someone actively intercepting this communication line looking for this type of information, among many other things. Since you don't know the answers to these questions, I would call, not email, the person you're supposed to send this data and say "I'm uncomfortable sending the naked pictures you requested via unencryped email on the Internet. Is there a secure way I can submit them?" If they don't have an immediate answer, you can then suggest examples - but as I indicated in my opening sentence, I think the likelihood is that your path of least resistance is fax, assuming whatever you need to send them can be faxed. Of course, whatever route your data takes, you are then totally at the mercy of their internal document security procedures. All security is an illusion. The document I really don't like submitting electronically (but am forced to all the time) is the W-9 Proof of Taxpayer #. For a $50 payment when a TV station bought one of my YouTube videos, I had to email this (nothing else was accepted and no encryption was possible). Normally I prefer to send this form via snail mail, but air dates yada yada.
Why do you want their key?
Send them your keys. That's the safest way. This way you're 100% in control.
I use www.djigzo.com. It's open source, it uses S/MIME, it's server based, and it's easy to use.
no, I don't have a sig
just fax the data to the secretary.. that's what they're there for, to handle administrative tasks such as receiving faxes and information and routing to appropriate persons.
Instead of making the email process a real mess for both party, with all the problem that come with it, why not just send all personnal info in a encrypted file container and then phone the destination and give em the proper password and/or way to decrypt the informations ?
That way easier that assuming that they IT department would even want to mess around GPG/PGP, depending on their country laws, etc...
Just search for the companies domain at http://pgp.mit.edu/
Since encryption can use either private keys or public keys, the only reason to ask for a public key is because you aren't in direct communications with someone in order to securely exchange a private key. Public keys are used for more than just encrypting data, so if you have a public key you want it as public as possible. Since there is also a secret key behind the public key, it's either set up as a fully automatic process that would decrypt your data as soon as it was received or it is saved in encrypted form and only a small group can decrypt it.
So, where a company feels like they need secure encryption they may often have multiple public keys, sometimes tied to a department or even an individual, but in all cases if they have a public key they publish it. If you don't see one listed then they don't have a public key in place for at least that group. Check for the group that handles security concerns and they may have a public key, but unless that is where you want your data to do,,, I wouldn't use it,.
-Robert
They're SUPER-sized morons :)
NOTHING requires the card to generate the keys - they are USUALLY generated externally, then stored ON the card for use in generating other keys. The public key is always available, the private key is available to the issuer, along with any other data they want.
By definition, smart cards can be programmed to do ANYTHING. And that means giving out any generated private keys... But since the private keys are generated using the data stored on the card (known to the issuer), they can also decrypt any messages sent/received.
Even the encryption software itself can be bugged to include third party keys for decoding purposes...
The government IS the third party.
ANY third party... So using it to "securing privacy of said info from third parties while in transit" already failed as the government IS a third party.
You also are assuming the creation of the card is infallable. CAs fail - even government ones. So any single source of keys is already a failure.
1. Make a minimal truecrypt-file and put the data securely there.
2. Find out who is the real recipient of the information.
3. Get his/her email-address.
4. Make sure recipient understands the concept in person and is able to use truecrypt.
5. Securely provide recipient with a good password in which to open the file, along with instructions how to handle the data securely.
6. Send the email to recipient.
7. ???
8. PROFIT!
With any luck, you can continue to use the same password the next time for the same client, but do not have the same password for different clients. /. after all, jerk! ;-)
I'm sorry I can't help you being polite. This is
Why TrueCrypt? In theory, you could use PGP. However, realistically not even hardcore sysadmins bother with PGP. Most everyone and everything can use and understand TrueCrypt though. It's a user-interface and availability thing, which GNU packages rarely provide.
Captcha: antidote
Type the reply on a Royal typewriter and take it to your local post office. Use Certified or Registered mail if you feel squeamish about sending personal information. The NSA can't open a properly mailed letter.
Most companies with a work force of more than about 30 will likely have a VPN setup to allow workers to access their network in the field. Ask them for credentials to log into their VPN. Send your data accross it
You're asking how to ask a question? You request them to send a public PGP key so that you can encrypt the email. If they don't know what that means, you elaborate and point them in the right direction.
The same technique can be extrapolated to any request that you have in life.
"The public key may be published without compromising security"
Source: http://en.wikipedia.org/wiki/Public-key_cryptography
I had previously written:
Send the public key in a normal open email and confirm the hash by voice.
It's the private key that's sensitive and should be kept secure.
Very annoying to be modded down with no explanation. If you disagree with what I'm posting please reply and explain your position.
blindly antisocialist = antisocial
Most IT departments don't know the first thing about email encryption, but if you âdoâ get one, it's more likely to be S/MIME rather than PGP. The former is built-in to most email systems and the latter requires them to deploy additional software, which they won't want to do.
Dear Fascist Bully-Boy,
Give me your public key.
May the seed of your loins be fruitful in the belly of your woman,
Neil
How about just zip the data up, put a strong password on it, call her and tell her the password.
And in your email ask them to call you for the password.
All these comments so far are missing the K.I.S.S. ( Keep It Simple, Stupid) option. There are physical ways to send electronic data, you can even encrypt it if you wish and send the key and instructions via email, but burn it to a disk or put it on a cheap, small USB key and mail it, duh! Problem solved. The data is still electronic and can be accessed from the media as easily as from an email attachment. What they do with it after that is still bound by the privacy regulations of your country and if you encrypted it to send to them you did your part to keep the data safe. He did say he trusted the recipient, but if they don't know how to use encryption that trust seems a bit misplaced if you ask me.
You havent said if you expect the decryption on the other side to be safe! Is this security only for in-transit? If they are just going to decrypt the data on the other side and plop it in a company share that you are just as much at risk.
Simple, use 7zip -- and put your email in an attachment and use 7zip symmeteric key encryption. Then call them on the phone or mail the symmetric key -- or better yet, give it too them in person. They just install 7-zip, and dearchive the attachement, and supply the key. Can do the same with PGP/GPG if you want but more difficult.
I was dragged kicking and screaming onto a HIPAA technical implementation task force for a state government about a decade or so ago when HIPAA was first being proposed. We looked at every possible way to encrypt and secure email, both for Data In Transit and for Data at Rest, and the Data In Transit part was intractable. For the situation we had, which was pretty much open with dozens or hundreds of networks sorta kinda on a shared backbone. Too much turf owned by too many players and each went their own way. Most just decided NOT to use email for PHI.
Many years ago I was dealing with a company that let's just say was huge and their computers guarded massive amounts of money. I was working for a contractor building a web page where customers would fill in an application and the application would be emailed securely to someone who would process it (not a great way but it fit their existing data flow) so after everything was working with our made up keys I asked the head (the entire company's head) of IT for the public key that we would need. He then sent me a collection of files that was all their keys, private and public. And by all I mean the keys to their entire kingdom.
I found the guy's home number and called him that night and explained to him how public and private keys work and that with the private keys people could own him.
So the question is not just how to ask for a public key but to make sure that they only send you the public key.
Personally I have had little success getting people to manage their keys. Few back them up, very few understand the difference between public and private. Often they are fearful of using public keys. Plus the end result is they often send unencrypted emails thinking that they are. "I sent this from my phone. Didn't we set up encryption?"
I have a keypair I got free from comodo, and any email I send is signed by default, which includes my public key. (which isn't visible to most users, using default email viewing settings)
Thus, anyone that gets an email to me can reply back and all they have to do to encrypt the content is to click the padlock.
Owell I suppose it's not as common as it should be. You could tell them to go to comodo and sign up for a key, but it's not as straightforward of a process as it probably needs to be for a non computer tech person to feel comfortable doing.
I suppose the best route would be to direct them to comodo's sign-up form and ask them to get a key and then send you a signed email. If they have problems, or think they've got it set up and you still don't receive a signed email, you might want to fedex a package to them instead. If they prefer an electronic copy, send a pair of usb flash drives with two copies of your data on it, in case one of the drives goes bad. If the person you're talking with isn't a tech, you don't really want to try their patience or make things difficult for them if they aren't able to figure it out immediately.
Here's the link: https://secure.comodo.com/products/frontpage?area=SecureEmailCertificate
I work for the Department of Redundancy Department.
If its that important to you that you send it to them encrypted, and they aren't asking you to encrypt it, then you shouldn't send it to them because once they get it, they aren't going to be secure enough with it to make your sending it to them encrypted matter.
Heres a reality check: No one gives a flying fuck about encryption.
You might, but the instant the other organization get it, thats over with. Its going to probably end up, unencrypted on someones laptop in the public space within a few months.
If they don't have procedures in place to encrypt everything already ... and you have to ask them about it, they don't have the rest of the procedures and support structure in place to make it worth the time to encrypt it in transit to them.
If both of you actually cared, and both of you had a clue (which clearly neither of you do, as you're asking on slashdot), then you'd just make sure both of your mail servers did proper SSL for transport and be done with the stupid crap you want to do.
PS: I develop and make my living writing personal encryption software and systems. Doing all this crap on your end is cute, but worthless when the other guy isn't going to do anything like it and is going to make it trivial for anyone to steal your data anyway.
Grabbing data as it flows across the Internet is really non-trivial as it requires you work at a few specific places. There just aren't that many jobs open for those positions, and most of the people in them are comfy enough that they aren't going to be running Wireshark to get banking info for your poor ass.
Its a waste of your time, you just don't realize it.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
Anyone who is using public key encryption should make their public key(s) available in public places, no need to send it. Could just have it on a web page. That's not quite enough, because there's the problem of authenticity. How is a visitor to the web page with the public key to know it is genuine? Links can be hijacked, web sites hacked, web pages injected, and so on. One answer is to test the key against a digitally signed document that came from the intended recipient of the secure messages, should the communicator possess such a document. More likely is another kind of answer, which is to ask a 3rd party the communicator already trusts. One kind of public place that is specialized in public key encryption is a trusted repository of keys for which everyone has the public key. This 3rd party is sometimes called "Trent". This is basically how https works, and the 3rd parties are organizations such as the somewhat notorious Verisign. Thawte, CAcert, and others also serve as Trents. A person wishing to communicate with a stranger asks Trent for that stranger's public key, or asks if a key really does belong to a particular entity, then can use Trent's public key (because everyone already has Trent's public key) to verify that the message purportedly from Trent is genuine. A problem with this is that one Trent could be a single point of failure. What if Trent is compromised? A way to deal with that is the "web of trust". You don't check the public key of a stranger against just one Trent, you check it with many Trents. If a dozen independent entities all say that some public key really is the public key of the stranger you want to communicate with, then you can be fairly sure you have a good key. This is still not unbeatable, especially if the independent parties get lazy and start leaning on each other too much, so that they are no longer truly independent.
Asking others to send their public keys looks a bit ignorant. Instead, check around for their public keys. That is, Bob doesn't ask Alice for her public key, not over an unprotected channel, instead Bob asks Trent (through the protected channel he already has with Trent) if Trent has a public key for Alice. If no, then might ask Alice directly. Ask if they use public key encryption and have public key(s) and if so, where a suitable key can be obtained. However, the main reason to ask Alice about it is not to get her key, because she probably doesn't have one, it's more snarky, to make Alice aware that maybe she ought to use public key encryption, obtain a key, and get the word out that she has one.
Intellectual Property is a monopolistic, selfish, and defective concept. It is "tyranny over the mind of man"
Whatever key was used to sign that request, is the key to use. Since you've already verified the request, you must already have the key and have verified its identity.
*pause*
Whaddya mean, "the request wasn't signed?" Hmmm.. Are you sure you know who is asking?
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
Ask them if they have a pgp key first. They should know how to answer that question. If they don't, tell them that you prefer to not send the requested data by an unsecured email channel and ask them for a fax number.
I know if I do a key search for myself I find my public keys.
You are better off faxing the info. Otherwise send an AES encrypted zip (warning that the default zip encryption is zipcrypt which is insecure) and over the phone give the password.
The unencrypted data stands a good chance of being sent by e-mail again though. Leave out PII data like your SSN and give it over the phone.
If you are sending an email to a large corporation, then the public key is useless to you because whomever is receiving your email doesn't have permission to use the company's private key to decrypt the email.
-Glires
Finger me for my public key!
"These people look deep within my soul and assign me a number based on the order in which I joined" --Homer re:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
You can always search for it first:
If they're on Slashdot
http://slashdot.org/~usernamefoo/pubkey
Or:
sudo yum install pgp-tools
or
sudo apt-get install pgp-tools
And then:
keylookup e-mail@foo/username/identifying name
For example, keylookup --frontend=plain Rob Malda
gpg: searching for "Rob Malda" from hkp server subkeys.pgp.net
1024R/239BB413 2000-2-9
Rob Malda <malda@slashdot.org>
1024D/8662850F 1999-7-7
Rob Malda <malda@slashdot.org>
Now run gpg --recv-keys <key ids>
I used frontend=plain so I could paste the output, not using it lets you select one via checkbox in the output and import.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iEYEARECAAYFAlIGY14ACgkQnludVzJNqF2B+QCeKNVEU8AJ5OPwqs+A4PEcHYp4
BS4AoMXbo7yopYxycMp+K+WqX58SnYUP
=NDBb
-----END PGP SIGNATURE-----
It may seem a bit overkill, but I already had a web server setup at home to host my own personal (low traffic) website, so I was mostly there already.
At some point, I needed to send someone a private document that I didn't want intercepted by eavesdropping, so I created an SSL-only vsite subdomain in Apache, uploaded the document and simply provided an HTTPS link to the recipient. Add HTTP auth with .htaccess/.htpasswd to require a login and make the login something you've predetermined with the recipient or based on a clue that only the recipient would be able to decipher. Also use "Options -Indexes" and create a robots.txt to deny all bots for further obfuscation.
For extra security, use cron or something to delete the file after a couple of days or tail Apache's access log to see when the file is accessed by your recipient and manually delete it after it's downloaded.
It took me about an hour to figure out how to setup SSL the first time. If you want to use this method, I imagine it would take a 3 hours or so to initially set this up in a VM on your computer (you could use something like Turnkey Linux' LAMP stack to make it really easy). After that, it's just a matter of a couple of minutes to send each secured file by uploading the file and creating user creds.
Wouldn't it make sense to teach this in the public school system? It has the same characteristics as math, reading, science, etc. It's something people aren't motivated to learn because it has no immediate benefit to them, but will help them out in the long run.
then phone the destination and give em the proper password and/or way to decrypt the informations ?
You must be German.
If they are truly concerned with security then the company should refuse to give you their public key. Public keys are public and should we widely publicised by trusted third parties, not supplied by the purported owner. The organization that created the public-private keypair is responsible for distributing the public key in a secure and verifiable matter. They are the ones who know the true owner of the key.
Trust me. I'm J. Edgar Hoover, past head of the FBI. I can provide all sorts of identity documents if you need them. I'll even send you sworn statements from my attorney, my mother, and my dog. Just trust me. We're good at providing sworn statements.
Now, as a practical matter people exchange public keys all the time. Everyone knows you need the public key so just ask them where you can get it. They will either direct you to some trusted key repository or will just send it to you. Of course, if they send it to you then you have to already know and trust them. Word it like this:
I need your public key use PGP. Please provide it or explain how to obtain it. Thanks.
I have to do this all the time for work as I used to manage an large HR unit's IT needs - and they really do need your SSN, on every damn piece of documentation... Find a secure service or hosting option that meets your security requirements, there are hundreds out there. Personally I tend to use LastPass's secure notes or if it's not super secure data I'll just use Evernote w/ attachments and send them a private URL. Again, if you don't like those options, there are literally hundreds of others including roll-your-own services, I've used Accellions (clunky but it works), Box.net and Dropbox or even just spinning up your own web server w/ a required password you give them over the phone. All of varying levels of security and hassle to the end users. To them, it's just an email with a link and perhaps they have to enter their email or go through a sign up process the first time. It doesn't have to be that hard.
If a secretary asked you to send personal information in the email, it's a good bet that she sends it around herself encrypted. You probably have a lot at stake dealing with this organization, but before you start out just be sure to understand that they WILL send your information unencrypted. The contact with them might still be worth it to you. But the loss of privacy is part of the price you'll pay. Now what's worth more to you depends entirely on your circumstances.
Any guest worker system is indistinguishable from indentured servitude.
What I have done in a similar situation is to email an encrypted pdf file and then call them with the file's password.
Just send an encrypted pdf, and wait until they ask for the password.
I think we should add a public-key-requested header to MIME, so that it can be built into mail clients. If the user adds a public to to their account then with a checkbox or button can choose to attach it to the mail. The user can supply their own key or one can be generated.
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
E-mail is not secure. Encryption without some degree of authentication of the party on the other end is only marginally more secure because nothing keeps the man in the middle from sending you his public key instead of the ultimate recipient.
If this scheme/process was open source it would be simpler and better understood. Because if someone disagreed with how it was done, and thought they could do it better, they could just fork it and make a better one. That way we would never have a proliferation of different schemes, because the latest person to fork the code/scheme/process would have the best version, and it would be easy to keep that one up to date since people around the world would only need to concentrate on that one. There wouldn't be dozens of different projects doing the same thing and burning all those hours reinventing the wheel.
-- I ignore anonymous replies to my comments and postings.
Key signing parties work well for helping validate identities of endpoints within reasonable walking, cycling, or public transit distance of one another. I don't see how they'd work so well between cities, especially with TSA cracking down on flight. So as I see it, a web of trust would end up with a bunch of well-connected islands within a city and a bunch of bottlenecks among frequent flyers.
I've yet to deal with an organization that has a GPG/PGP key for encrypting email to the organization. I don't think there's anything wrong with asking if they have one for encrypted email use, and so I think it's fine if you go ahead and do so, but I also don't expect that they have one.
What is more common is for the email MTA to support SMTP over TLS encrypted transfers. This can be verified using 'swaks' by testing each of the company's email servers listed in DNS one by one.
Finding the mail servers that cover a domain, for instance "nonsense.com":
$dig nonsense.com mx +short
10 nullmx.nonsense.com.
$swaks --ehlo testing.example.com --server nullmx.nonsense.com --tls -q TLS
=== Trying nullmx.nonsense.com:25...
=== Connected to nullmx.nonsense.com.
220 mx ESMTP
EHLO testing.example.com
250-mx
250-PIPELINING
250-SIZE
250 8BITMIME
*** Host did not advertise STARTTLS
QUIT
221 mx
=== Connection closed with remote host.
If the company email MTAs all DO support SMTPS, then perhaps that will be good enough. Even if the company did support GPG, there are certain things such as the Subject for the email which don't get encrypted, so SMTPS is important for those reasons anyway.
http://www.mailvelope.com/
Seems to work reasonably well and is OpenPGP. Fairly certain that it's as secure as your PGP Key is (you can import from outside generators or use the built in one). Anybody researched how well this solution is implemented?
Pick a password/phrase agreed upon via a phone conversation. If you try to get their IT department involved, the people working with your documents will just end up passing your decrypted documents around via email or other insecure file storage mechanisms, anyway. A password is simple enough for most non-technical people to understand, and is build into the PDF spec so no special software is needed to view or create, which makes it much less likely that there will be an insecure version of your paperwork sitting around somewhere, and documents sent *back* to you are more likely to also be encrypted (the last time i refinanced my mortgage, my broker actually requested that we do so for all communication). FWIW, assuming you trust them and SSL is enough encryption for you, you can usually share things privately through services like Dropbox and then remove the files once you know they've reached their destination.
Do you really need reason for beer? Wingman Brewers
First of all, your request shouldn't be made over email. If it's an insecure link then the key might be compromised. You're going to have to go into their office and ask them for their key on a flash drive or similar media. Or, you're going to have to grab it from a keyserver that you've verified in a similar way. Keep in mind that anyone can register a public key under any name and add it to whatever keyserver they wish, so you need to make sure that the key you grab doesn't belong to an imposter.
If you're thinking that you don't need to do this "because, really, how likely is it that someone has compromised the link?" then you can just send your personal data in the clear. After all, if it's unlikely that the key will be compromised then it's just as unlikely that your data will be compromised.
Of course, you should probably be ready for this organization to give you funny looks when you ask for the key. When you finally do get the key, if they even have one, then be prepared for "your email did not come through properly and looks like a bunch of jumbled characters. Please resend it." If the secretary doesn't know what the public key is or how to get it then how likely do you think it is that anyone else in the organization knows what it is? Maybe some guy in IT knows what it is, but he probably isn't in the business of running around to everyone's computer to decrypt their email.
-1 disagree is not a modifier for a reason. -1 troll, flaimbait, redundant, overrated are NOT acceptable substitutes.
just asking.
been a while since I've heard of PGP keys and PGP in general. i thought Norton/Symantic stopped developing PGP.
i guess GNU PGP took over Symantic PGP? i used to have Symantic PGP version 7 that ran under windows 98, I think.
Rather than go in to the weeds, how about you just ask "do you have a secure method of sending this to you?" That usually works - often times they don't use GPG/PGP/similar, but they will use a third-party secure email service.
The (computer security software) company I work for does not officially support S/MIME, but I did go through the effort to get a certificate for my email address. In 3 years of having it, including needing to send files and information securely many times, I have had exactly one other person have an email certificate to exchange and send/receive securely.
We *DO* use a third-party secure-email provider that is used by quite a few of our customers. When both sides use this secure email provider, it is fairly transparent (as long as you are using Microsoft Outlook,) when only one side is using it, or you aren't using Outlook, the recipient gets an email that directs them to a "reconfirmation of ownership of email address necessary" secure website that contains the content.
We also (especially for larger data) use SFTP (with "24-hour-only accounts",) and a secure-upload website that, similar to the email provider above, uses double-confirmation. (Merely having the first link is not sufficient, every time you want to access it, it sends you another email you have to click the link in, and that one is only good for an hour.)
"Please reply with a digitally signed message"
So your government gives out these cards - great. That works fine if you're Estonian (and apparently, you don't have a choice in whether you carry one or not...unlike, say, the US, where you are not required to acquire nor posses ID.)
What if you're not Estonian? What if you're not in the country legitimately?
It wouldn't surprise me if you have an entire second class of people - those who can't get the cards, and thus can't sign contracts, can't get bank accounts, can't email officials, can't get transportation passes, etc. Do you need the card to get medical care? File a police report? Etc?
The problem with being forced into the black market is that there's a lot less legal protection in it, and a lot more people interested in taking advantage of you...especially if you can't/won't go to the police.
The technology sounds great, but it's effectively an immigration control tool. Which is a bit of a problem, given Estonia's population has plunged in the last 30 years.
Please help metamoderate.
Hi. I'm a snide, unhelpful a-hole. This makes me indistinguishable from every other Slashdot contributor.
but you risk them thinking of you as a neanderthal.
CKT version dos tools or bust!
And send it in the mail. Only takes a day and is still the safest way to send info (if compared to workload).
Don't forget that unauthorized interception of communications on the POTS networks is a federal felony, while intercepting data packets is at the discretion of the prosecutor.
Dear Organization,
Let me see if I have this right: You want me to send you my personal details in email plaintext, which everybody knows is as secure as postcards. Here we are in 2013, the NSA's for-profit contractors are intercepting everything, passing it on to other agencies such as the DEA, and probably even selling it to whoever will buy it to make even more money, and you haven't thought about communicating securely with people? Why would anyone buy anything from you if they cannot do it securely? Why would anyone want to work for yo.. you know what? Nevermind! Until you pull your head out of the stone ages and post your public key on your web site, I'm not really interested in interacting with you.
Sincerely,
Your customers, clients, potential employees, current employees, and the public in general.
Webmail providers could do something akin to mega.co.nz style vault access, and only the user's password could decrypt the messages they receive.
If the mail is decrypted remotely on the server, that's a possible point of attack.(Either through legal mean, or through hacking/virus). The content could be intercepted while the server is decrypting it for you out of its secure storage.
The only technical mean to increase privacy is to use *END-To-END* encryption. As in: The message is encrypted AS THE AUTHOR is writing it on the author's mail client and the message is decrypted only AS THE RECIPIENT is reading it on the recipient's computer with the recipient's mail client. Each end of a secure communication must do the encryption/decrytion locally on a machine and on a software that they control (which in, my definition, requires also at least some level of opensource, so that 3rd party can check the OS and client and confirm that there are no attempts at eavesdropping). If the encryption or decryption are done on their behalf on a different machine and/or software that the users don't control, there's a risk that eavesdropping happens there.
Same logic with OTR for messaging (end-to-end encryption of messages, NO MATTER OVER WHAT THEY TRANSITED UNDERNEATH).
Same logic for VoIP (ZRTP/SRTP is a good solution for encryption over SIP/Jingle/H323 and other RTP based VoIP protocols. On the other hand Skype is a very bad solution: their encryption scheme is completely obscure and secret, you don't control the software, you can trust them the way they encrypt, and Microsoft openly admits with the EULA that they could comply with local wiretapping rules if required to by law enforcement)
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Doing encryption, decryption, signing and verification in the web browser is horribly insecure
Note that I've specifically spoken about an *extension*, something that rests above webapps and their embed scripts and can overrule their javascripts by implementation.
Just the way that NoScript, AdBlock, and co can override and rewrite a page, no matter what javscript is in there, the same would go for such an extension. It has to run inside the much more secure UI environment part of the browsing experience, rather than running in the webapp's environment. It has to sit outside the sandbox in which the webapp javascript is executed, so that it could never intercept the plain text.
The plain text should be out of reach of the context of web app and run in the same context as - say - the part of UI responsible for browser security configuration or saved password storage.
The maximum that could be allowed is some cooperation to make the extensions job easier. What I meant in the original reply, is simply flagging which part of the pages contain mail body to be decrypted or encrypted by the extension (as in telling "the DIV id# 14857 is the own containing the message body. If you have a decryption extension, that where it should tap into the page"). Never handling the decryption/encryption it self.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
If I mis-read DrYak's post, then I apologize for muddying the waters. But from the other responses above, the water isn't crystal clear to begin with.
In my post, I've never even mentionned *how* public key encryption should be implemented, because I presumed that most people here on Slashdot know how it works. In fact this whole thread simply speaks about known standards, sush as GPG, PGP, S/MIME, etc. nobody is trying to re-invent encryption.
My post was only an answer to the above mention that most people don't use mail clients (like Thunderbird for example) which DO have nice implementations of said secure standards. Instead most people nowadays use webmail (like GMail, for example) which can't handle secure standards for obvious reason.
I'm reasoning that the "secure part" (PGP, GPG, S/MIME, the standard stuff. Nothing new or revolutionnary) could be implemented in a secure way in the browser it self, as an extension. Which therefore runs:
- locally (and doesn't depend on the webapp or anything else on the remote web server. Except maybe some simple collaboration like tagging which DIV contains the message)
- in a different context than the webapp and in the same context as the rest of the UI. the decryption/encryption doesn't happen in the same sandbox as the javscript and thus is less susceptible to eavesdropping (just like webpages can't interfere with your security settings, nor with your management of saved passwords).
In short, I don't tell *how* public/private key encryption/decryption should be done (there's GPG, PGP, S/MIME, etc. for that).
I tell *where* we could do it, so that webmail users (like GMail, and co) could do it too, in a secure fashion.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Web-mail can deploy client side JavaScript decryption. So when a message is encrypted, it gets delivered as is (encrypted) to the client and only gets decrypted client side. This could be done by asking a password or pasting a hash.
This is the WRONG WAY to do it.
Main problems are:
- You're running the encryption/decryption in the same sandbox as anything else coming from the web. The message exists in the same address space as all the other shit which gets downloaded and run from the web. Some clever hacks could use this to retrieve the decrypted message. (A rogue javascript peeking into the result of the decryption java script).
- You're executing code you received from a third party. More precisely precisely, at each refresh, you're getting a new copy from the webserver (approximately, but you see what I mean: you're running code which is more or less stored externally, outside of your control). Next time you log into the webmail, it could very likely happen that the webserver sends you a slightly different version of the script which sends back the decrypted plaintext once it's decrypted. That is one probable way to implement wiretaps if law enforcement ask them.
You need an extension.
- Some thing which runs outside of the reach of the sandbox where all webapp run. something which runs in the same context as, for example, the security settings of you browser, or the management of saved passwords.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
And what would stop this javascript text editor from sending every keypress to a parallel file or server prior to the encryption process?
Nothing could stop it. But what could stop your stand alone mail client from secretly sending screenshot to a parallel server prior to the encryption ?
Some level of opensource is required to audit such an extension, just like some audit would be needed to audit a standalone mail client.
Also, this needs DEFINITELY to be implemented as an extension, not server-provided javascript code, so that it runs outside the sandbox in which all web stuff is executed, and runs in the same context as your browser's security settings and managment of stored passwords). So you have 1 trusted extension (and not some remote code which is sent again each time and could be altered between runs) and so the decrypted plain text is outside of the reach of potential javascript attacks.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Sorry but what has *digital signing* something to do in a long discussion about how to implement *secure encryption* and a subthread about how to do it for people using Gmail and other similar webclients?
Okay, they both use the same technology under the hood (public/private key pair), and of course similar web of trusts for the public keys.
But then mr. "I Am New Here" comes and completely mixes the two, tells that public key *encryption* can't work for security, and gives argument for that based on *digital signing*.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
That is what I said in my second paragraph. That isn't what the post I replied to seemed to be saying. I read his post as saying his browser encrypts messages with his own private key, for the recipient to decrypt with his public key, hence my concern
I don't even *mention* the words "private key" or "public key". Stop tryig to invent things out of what I've writte. :-)
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Most decent PKI implementations include a copy of your certificate/public key in a signed message that you send. Most decent email programs will strip the public key (and/or certificate) out at the recipient's end and associate it with your ID in their contacts list. (A decent company IT implementation would do it globally, but that's another story.) So if you send her a signed message, she can still read it (unless you encrypt it too, which you wouldn't, because she doesn't have your public key yet) and she will have your cert/public key stowed in her contact list.
If you can get her to (a) sign up for a cert, and (b) install it in Windows or Outlook, and (c) set Outlook (she probably uses Outlook, sigh) to sign all outgoing messages, you will get her cert/pubkey the next time she sends you a message. (I believe Outlook handles certificates out of the box, but you need to use an add-on for PGP/GnuPG. A certificate is just a public key with some certified identity information to go along with it.)
Then you can use her certificate or public key (which you got from her signed message) to encrypt your private information for her, even if she doesn't realize she sent it to you. Outlook will automatically decrypt it with her private key if she opens it (even if it doesn't in some list views).
The hard part is getting her to sign up for a cert or create a GnuPG key. Her IT staff could take care of that.
If people would start using the encryption that is built in to their email programs, public keys would be widely distributed and you wouldn't have to ask.
I assume you asked a keyserver (e,g, keyserver.pgp.com) if there was a key associated with her email? That would be something you can check easily.
Instead of anything in quotes, just how you asked us. Could you please "send me [your company's] public key for encryption." If necessary, specify "for secure e-mail," after that. Specifying PGP/RSA will make you seem either too geeky, too specific, and perhaps raise flags that you're trying to find out more than is necessary. The person receiving your e-mail will know who to ask within their organization if they don't already have it scribbled down on a post-it stuck to their monitor.
They may have no process but first you have to ask.
Tell them that you do not trust the coffee house WiFi that
you need to use and that this is important to you.
Since we do not know who the company is, who you are and what nation/ locality you are in we can go nuts on all the options. Consider the chaos that Obama is having over his birth certificate. Personal data needs protection you and those that mandate you disclose it to have a shared responsibility. The law in many jurisdictions almost protects you.
Print it out and send it registered snail mail requiring that the paper be signed for by the recipient unopened. i.e. Old School.
The best way is always in person. Joe Baddude could send you half of a digital encryption key pair and you would never know.
Building a personal library/ web of public keys is important for many. For example if you have a trusted friend in a city far far away that individual could pick up the public half of a key from a company or individual you need to work with and send it signed by his key that you have. You need to do the same for him or her. Many post their key on their personal web site and validate with a MD5SUM or other hash validation.
Truth is stranger than fiction, but it is because Fiction is obliged to stick to possibilities; Truth isn't. Mark Twain.