> From: owner-openssl-us...@openssl.org On Behalf Of Jakob Bohm > Sent: Thursday, 22 November, 2012 04:07
> (Since you top-posted, I will do so too in this thread) > But I won't, because I answer multiple points from both of you. > The certificate does not include the private key, only the public key. > > In a real (not test) setup you would use these like this: > > 1. Use the certificate file alone on any computer to encrypt > data using > the"openssl cms" or "openssl pkcs7" command. > > 2. Use the key file AND the certificate file on the recipient computer > to decrypt data using the "openssl cms" or "openssl pkcs#7" command, > with different options. > ITYM the 'cms' and 'smime' utilities, both of which handle the general cases of PKCS7/CMS (enveloped, signed, etc.) with as far as I have found pretty much the same options. The much older 'pkcs7' utility only handles the special case of SignedData-no-data-no-signers used to convey certs and/or CRLs. The PKCS7 *API* has long been able to handle signed/enveloped/etc, only the *utility* could not. When I looked (a while ago) the CMS API (used for 'smime' also) appeared a little more flexible, but not noticeably more capable. > To tell the difference between the kinds of PEM files, just look at > the first line in a text viewer such as Windows Notepad or GNU less, > it will say so in nice big friendly letters. > > P.S. > > The differences between the OpenSSL CMS and PKCS#7 commands and > features have little to do with differences between the CMS and > PKCS#7 standards, it is just that some members of the OpenSSL team > had different ideas about what they wanted the command to do, and > then used two names of the standard to tell their work apart. > > On 11/22/2012 12:21 AM, Peter Parker wrote: > > Dave, > > Thank you for the quick and thorough response. This is good stuff. > > > > Yes, so the files I will be encrypting will be over 100 bytes. I am > > aware of the key size requirements - 1028 was only used as > a placeholder > > for the example commands I provided. Does this mean that I > will be able > > to use RSA or not? > > *Raw* RSA, which is what rsautl does, can only handle data that is somewhat smaller than the key size; the exact delta depends on the padding used, and I don't have them memorized since as I said basically no competently designed sytems use raw RSA, but instead RSA-encrypt only a DEK which is never more than about 32 bytes, well under the limit for any reasonable RSA key. A 1024 or 1028 bit RSA key is 128 bytes, and the usual paddings take about 20 bytes, so I rounded to "about 100". OpenSSL supports RSA up to 16Kbits, but the cost of RSA operations is quadratic in key size so on typical hardware where you can do 1Kbit or even 2Kbit operations at hundreds per second, 16Kbit operations will be on the order of one per second. If you are using unusually powerful hardware, or unusually limited (such as "mobile" devices), adjust up or down accordingly. Other systems may not support RSA above some limit, such as 4Kbits, but as I said standard systems don't use raw RSA anyway. > > You lost me with the chaining and AKI stuff. I have no idea > what either > > of those mean. Does the CMS approach that you suggested address this > > issue? In either case, I like the idea of using CMS. > > > > The major reason that I am using the x509 (or originally > the ca) utility > > is that I want to be able to set begin and end valid dates > (-startdate, > > -enddate****) for the public and private keys and create > certificates as > > well. I also want to associate some metadata with them like > organization > > and locality, for that I am currently using the -subj command. > > X.509 certs are good for associating metadata to a publickey, yes. They don't directly apply to the privatekey, but may indirectly: here you have a keypair&cert intended for encrypting, so if the senders stop using this key for encrypting after validity end, then there will be no data for the matching privatekey to decrypt and it becomes functionally, though not formally, obsolete. If you are using -subj for the child cert(s) *with a different value* than the CA, which you did not mention before, *that* addresses the chaining issue. If you run your own private CA, I would expect often organization and locality (and country) for the "leaf" entities are the same as athe CA -- but maybe not. If you use attribute(s) intended to identify specific party or system -- conventionally CommonName -- that should be unique. In the dim past, only 'ca' could create CA-signed certs, but now 'x509 -req -CA*' can do so also; the main difference now is 'ca' keeps a record for you in index.txt (and can use it to do CRLs), while 'x509' doesn't. Keeping track of certs by hand is tedious and error-prone, so if you intend to do more than one or two -- especially over a long time-frame -- 'ca' is probably better. PKCS7/CMS/SMIME *uses* X.509 certs, but doesn't affect their creation (other than to require it has been done). What is does solve is the raw-RSA problem, by doing in a standard way the hybrid encryption I described -- symmetric-encrypt unbounded data with a DEK which is PK-encrypted to the recipient, or for signing hash unbounded data and PK-sign the hash plus some metadata. It also handles useful variations such as encrypting the same data to multiple recipients, signing the same data by multiple keys (which might actually be different parties, or just multiple keys of one party to support verifiers with differetn/unknown capability), and both encrypting and signing the same message in one operation. > > Am I correct that the large PEM file includes both a public > and private > > key? If so I should be able to extract them from the PEM > and then use > > something (rsautl, enc or ...) to encrypt and decrypt the > files. After > > successfully extracting what I understand to be a public > key from the > > PEM, I receive this error from the rsautl utility: "unable to load > > Public Key. Error in rsautl" > > "The large PEM file" isn't an adequate description; OpenSSL uses lots of PEM-format files. As Jakob said, you can tell what's in a PEM-format file by looking at the dash-BEGIN line(s). In nearly all cases, OpenSSL reads a PEM file by searching for the begin line for the type of data it wants (a cert, a key, a parameterset, etc) and ignoring anything else. This means you can put comments for example a text description of a cert as well as the actual cert, or you can put several related things in the same file such as a privatekey and a cert or a key and a parameterset. Generally you can't put several things of the same type, but a few OpenSSL functions (and utilities) do accept a trust-file containing multiple certs (and use a sepcial process to read it). The commands you posted before give an error on the *rsa* utility, because you gave it a poorly-named file containing a cert when it needs a file containing an RSA privatekey (which in OpenSSL is really the keypair). Since 'rsa' fails, it doesn't create the publickey file which you try to use with 'rsautl', so that fails. > > Could you give me some examples of how you would use CMS > or, just use > > these utilities properly, to achieve what I'm trying to do. > > In my test environment with a server key named srvkey.pem and matching cert named srvcert.pem, and using SMIME format because it's easiest: openssl cms <infile -encrypt srvcert.pem >encfile openssl cms <encfile -decrypt -recip srvcert.pem -inkey srvkey.pem >clrfile There are several variations possible and numerous options that might be useful if you want them. <snip rest> ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
