encrypting message using only a public key
 

Sorry to bother, but I was wondering if a mod might move my topic into this forum:
http://www.linuxquestions.org/questi...il-4175452903/

The basic idea is that I want to determine how to take a simple text message (possibly containing sensitive information) and encrypt it using someone's public key.

From reading the thread you linked to, it looks like your still looking for a solution?

Here is a simple example using gpg, which in my opinion is much easier than SSL and Mime. I used the example of sending an email to "slackbuilds" since I have their public (only) key

I appreciate the responses, but the goal here is not to login via SSH and use gpg vid command line. I have some facility with gpg and have seen that madboa page before.

What I'm trying to do is concoct a PHP script which will provide a way for a developer to email potentially sensitive information securely to one or more intended recipients by encrypting it with their public key. I believe this is communicated in the other thread. The main issue is that gpg requires interaction and you have to maintain a keyring, etc. I was much rather hoping to skip all the keyring maintenance, all the prompts, etc., and just encrypt a text message using a public key.

There is no way I know of to skip the keyring maintenance you want to avoid with GPG, other than using symmetric encryption only.

PKI might not be the solution you are seeking here. Perhaps you could explain your security requirement in a little more detail.

The primary motivation for wanting this is that I'm working on a PHP script that handles Instant Payment Notifications. While this page is securely hosted (and only makes secure HTTPS connections to verify that any posts are valid) and furthermore does not ever traffic in sensitive payment information such as account numbers, etc., I would like to be able to notify a developer when an unexpected error occurs by emailing the POST data to the developer's email address. It seems a simple enough affair to set up one's mail client to send and receive encrypted messages, it seems that simply using somebody's public key to encrypt a message is unexpectedly difficult.

I'd like to use public-key cryptography so that a server compromise would not necessarily reveal any important keys (such as might be used in symmetric encryption). The basic idea is that the server would be able to send an encrypted message to the developer (or someone else) without needing any especially sensitive data.

I'd like to avoid manipulating a keyring so that deployment of such an emailing script is easier. It would be ideal if the PHP script that sends this message would be configurable with just a few bits of information:
1) the recipient's email address
2) the recipient's public key
3) maybe some SMTP credentials to send the mail via SMTP gateway.

OK so I pulled out my copy of Bruce Schneier's Applied Cryptography (an really good book) and has a very helpful section on Privacy-Enhanced Mail(PEM) which I've been looking at. Turns out PEM is not just way to encrypt things but it describes a variety of privacy-related protocols. To summarize Schneier:
The basic idea is that it describes protocols for sending encrypted and/or signed messages while also describing what has gone into encrypting and/or signing them. It supports both symmetric and public key encryption. The Wikipedia link above says that it was not widely adopted due to its reliance on a centralized root CA.

I think this cocktail of encryption-plus-protocol is what I'm after. Schneier also has a section on PGP (which uses web-of-trust rather than centralized CA) but details about the protocol look pretty light.

Seems to me that if I want to have PHP sending these messages, I will probably have two choices:
1) concoct awkward CLI stuff in PHP and use exec to manipulate key rings and such to get gpg to encrypt my messages (and then take care to shred and/or cleanup the file system to make sure my sensitive messages don't hang around
2) use mcrypt or some other PHP extension to encrypt my messages and then write PHP code to build out the appropriate email-friendly protocol aspects described by PEM and/or PGP such that the message, when it arrives at somebody's mail client, will be decipherable by something like Enigmail or some other secure mail client/plugin.

Surely someone has done this before?

For option 1 above, these functions look pretty useful:
http://www.php.net/manual/en/function.gnupg-encrypt.php

You might also be able to use the PHP execute function to call GPG to perform the encryption. I don't see anyway around maintaining a keyring, at least a public one as you will need the public key for each recipient that you want to send to.

A while back, I was working on a similar project for a payment system that I wanted to submit the information for processing via an encrypted mail. One of the problems I ran into was the need for temporary files to work the encryption on. This was a weak spot in the system that could be potentially exploited and I abandoned the idea. However you go about it, the best idea is to not store sensitive information on your system at all, and what little of it you do have to not write to disk.

I'm inclined to use the PHP extension for the simple reason that it would be easier than concocting all the exec commands myself.

This is disappointing as I was hoping to merely provide the location of a file containing a public key and have my routine encrypt away, but I think I can live with the idea of a keyring. I expect it might be feasible to maintain a keyring for each application.

Agreed! And thanks for pointing that out. In reading Schneier, I happened across a discussion about scrubbing a file system -- a lengthy process. Schneier quotes a passage from the National Computer Security Center:
I think all those multiple overwrites are intended if you are worried about someone actually physically obtaining your storage media. I wonder if the linux shred command would be sufficient?

If your using traditional magnetic media, the shred and overwrite commands will do an excellent job of making data practically irretrievable, even with a simple overwrite or two. By practically I mean without special and expensive forensic tools to where the common criminal is not a concern. If you have an SSD or other flash based material, these tools can be spotty at best because of things like the wear mechanisms.

You mentioned reading Schneier. I have been reading his latest book, Liars and Outliers and really enjoying it. It has been out long enough to be available via inter-library loan now too.

Re the keyring, I think you may be worrying over nothing. You're only storing Public(!) keys, so there's no problem with having it sit on the disk, or even be exposed to the world; that's what they are for.
Its only Private keys that require protection.
The keyring is just the equivalent of a big file with all the Public keys stored in it; not that different from your file-per-key.

Note that each user can have their own keyring, so you can do it that way if you want to keep them physically separate.
You'd have to allow your PHP to suexec to each required user (or maybe put them all in the same group and use group perms for php access).

I'm quite confused by this thread. To send a message to someone, you need to know their public key. Only they, with their private key, can decrypt it.

Message-signing requires knowledge of the signer's public key. Successful decryption of the message signature indicates that the possessor of the corresponding private key must have created that signature.

However ... the concept of what you are wanting to do is not a good one, and I daresay that PayPal would put the kabosh on your account if they caught wind of it. The notification should, yes, be encrypted (so that eavesdroppers can't detect whether a notification succeeded or failed), but it should not contain detailed information. The technician should have to log-in himself to see details.

Software support for Privacy-Enhanced Mail (PEM) is not hard to come by, e.g. in Perl or any other "real" programming-language tool. If you're for example trying to pony something up with bash-scripting, you're going about this the wrong way.

I appreciate the input here. I'm a bit over extended at the moment and so I've not been able to get into this as much as I would like.

I'm aware of all this and have tinkered with using GPG in a variety of ways. What I'm moaning about really is the need to maintain a keyring in a server context -- it makes deployment more involved if I'm trying to do this in a PHP script. It would be ideal if my PHP script could just refer to a text file for the public key of the intended recipient. If I must also take steps to import this public key into yet another file and possibly take other configuration steps (like setting a level of trust, etc.) then it gets more involved.

I'm also somewhat confused about formats for public keys. It would appear that the public key I exported using gpg4win (the more-or-less official distro of gpg for windows AFAIK) is not a *certificate* which is what gpg seems to want. I'm still trying to sort out the difference between x.509, PEM, and SSL certs.

Again, this is server config I'd like to avoid. Ideally I would just have a script that refers to a key file and takes care of using it to encrypt something. It's bad enough that I'll probably have to install the GNUPG PECL extension. That each use would then need to maintain their keyring somehow seems like still more configuration blah-blah.

I realize that maintaining a keyring has in large part to do with scrutinizing the trust levels and legitimacy of recipients (a big part of security to be sure!) but would like to reiterate that this encryption thing for me is largely motivated by a desire to email *myself* or *close associates* an encrypted message such that a) any sensitive information would be encrypted end-to-end while in transit and b) there would be no need for any sensitive keys or anything on the server -- just my public key.

Yes, I know.

Yes, I know.

There will be no account information emailed in this way, but the information is still sensitive IMHO. The point is to notify developers when exceptions occur in the code. The script in question is not a payment form and users never enter their payment information into our site. They enter their payment information into paypal's site and the script I'm dealing with is an Instant Payment Notification (IPN) page.

I appreciate your input and generally agree with your assessment that using shell scripting is a bad way to do things. It is my understanding that PEM has been all but abandoned due to its reliance on a centralized CA. And I must protest your assertion that Perl is any more "real" than PHP. PHP also has a library for gnupg and OpenSSL. The failure here is all mine and not that of the language used. At this point, I'm mostly confused about the difference between keys and certificates and how to identify what format I'm looking at and how to translate them, etc.

I hope everyone will bear with me until I can get a more specific (and answerable) question here.

This is in fact exactly the case :)

IOW, on the recipient's end (ie you / your mates home systems ) you generate a Public/Private keypair, then just import ONLY the Public key(s) into the server.
Have the keyring owned by the Apache user and that's it.

If you're only worried about in-transit encryption, you could (but not normally!) share your private key with your mates ie only 1 Public/Private pair for the whole system.

Hope that clarifies things somewhat.

PS I could be wrong, but I don't think sundialsvcs was saying php is not a real lang; more that you should stick to a lang like php, Perl etc that has bindings for gpg, which bash does not.
FYI though, I had to do something similar for some investment bank some time ago and found an oddity at the time viz:
using the gpg extensions from Perl to create the encrypted file at my end would result in a file that was unusable at the other end using PGP (not gpg) on MSwin, but shelling out to call the gpg prog directly created files that could be read by the target system.
Given that Perl was simply using the API of the same installed gpg SW, it was very odd...


EDIT: PS, for a completely lateral approach, why not just have the system dump the actual error (with sensitive info) in the dev's local acct on the server, either by cp'ing or local emailing, and then have the external email just be an alert, possibly with a classification hint eg class1 => emergency, class2 => urgent etc etc..
Skip all the encryption stuff entirely.
:)

I'm pretty excited about it.

I'm aware that this is how it works, but the devil is in the details. For starters, there appear to be public keys and then public key certificates and there's PEM format and there's X.509 format, etc., etc. I'm working on this today, but my experience in the past has been to acquire a public key via key server and that also seems like an extra step -- keep in mind that I might be explaining this whole key-generation process to very non-technically-minded people.

I've been thinking through how to import a key into a key ring belonging to apache. I was originally thinking it might be accomplished via PHP script with gnupg_addencryptkey but the documentation over there is pretty skimpy -- and, unless I'm mistaken, the parameter to specify the key is just a fingerprint which suggests the key must already by in the keyring.

I'm guessing I would need to manually run gpg commands as root on the server to import keys into the apache user's keyring?

I would like to create some PHP tools for the general case -- namely that I can choose from a variety of public keys to deliver messages. I'm aware that everyone who gets their hands on the private key (and its passphrase, if applicable) will be privy to the messages sent and expect key distribution to any groups will depend on the circumstances of deployment and server performance constraints, etc. E.g., the server may be under intense load so re-encrypting a single message five times for five recipients may present an unnecessary strain.

I appreciate your input -- helps me think it through.

I think we all agree on this point. My original post was before I had located the gnupg PECL extension for PHP. I had seen a script on the IBM website (wtf!?) that was using the exec commands and whatnot. I'm not above doing that if I must but certainly don't want to unless I absolutely have to. As it turns out, it looks like I'll need at least some BASH scripting for the key import business -- at the very least a command entered manually to set up keyring circumstances.

I've already encountered a bit of this oddness in trying to encrypt using openssl and got a failure. NB I have been posting about this same problem on phpbuilder.com.


Well there is in fact all kinds of logging and data entry and whatnot that gets handled on the server but the real advantage of the encrypt-and-email approach is that I would receive a convenient notification with all the relevant detail instead of having to copy some unique id from my email, open an SSH terminal, connect to the server (possibly having to type the password to my ssh cert), then remember where the log file is located, type "tail -f blah blah blah" or "grep unique_id /path/to/file" or whatever. It would certainly be nice to give the overworked forearms a bit of rest, don't you think?

I was mistaken about needing BASH to import a key.

Surely the dev(s) are going to have to login to the server to fix the problem, inc research the root cause anyway?
As I pointed out, the server would dump the sensitive stuff into the local dev's personal acct; no need to go searching all over the place.
Just create a log dir for each dev under their home dir and have the server dump a copy of errors there.
You should still keep the std logs wherever as the definitive log (eg for backing up / avail to any dev if reqd)

Generating keys is a strictly one off affair, done manually, then just stick the Public keys on the server.

Re key generation, importing, this is the guide I used http://www.gnupg.org/gph/en/manual.html

Unless you are sending very(!) large msgs, this is not a problem. Its a bit of an urban myth on modern systems...

Actually, the payload is encrpyted once with a randomly generated symetric key. That key is encrypted with the public key of a recipient. A message going to 10 recipients will have the payload encrypted once with a set of 10 PKI encrpytions of the key needed to decrypt the payload. That's a bit of simplification, but has the gist of it.

I certainly didn't intend to "besmirch PHP." I use it fairly constantly too.

And, hey ... :cry: ... I also didn't mean any insult to anybody out there. Just tryin' to contribute. Just sayin', and 'nuff said, but .. if I need to "eat crow" it sure tastes good.