RE: OpenSSL data enccryption / decryption
> From: [email]email@example.com[/email] On Behalf Of wujek_srujek[color=blue]
> Sent: Monday, 03 November, 2008 03:52[/color]
> Hi. I wanted to encrypt and then decrypt my data file using openssl. As
> openssh is using openssl to generate the keys, I thought maybe I would be
> able to use my already generatet key pair fot the task.
> So, I invoked the command:
> openssl rsautl -encrypt -inkey id_rsa.pub -pubin -in test.txt -out secret
> And got a sinle line in response:
> unable to load Public Key
> Then, I tried ... using my private key ... [OK][/color]
> So, the questions I would like to ask are:
> 1. Can one or not use the same set of keys for public key
> cryptography with
> openssl, and for openssh?[/color]
Yes, but not the same file. The format and encoding used by openssh
in its .pub file is different than that normally used by openssl.
openssh's privatekey file, with no suffix, does use the openssl default,
which is actually constructed out of several open standards, namely
PEM encoding and (optional) wrapping of the PKCS#1 ASN.1 representation.
You can create a pubkey in openssl format by something like:
openssl rsa -in id_rsa -pubout -out id_rsa.foropenssl
and then (optionally distribute and) use that keyfile for encryption.
> 2. I have been taught that the message is encrypted with the
> public key, and
> only the private key can decrypt it back. In this example, not[/color]
Correct. Or more precisely, in most usages, the message or file
data is encrypted by a symmetric algorithm (e.g. DES, AES, RC4)
with a random key often called the DEK (Data Encryption Key)
(and also normally a random IV, but ignore that for now);
then the DEK is encrypted by RSA with the public key.
RSA-encrypted-DEK plus DEK-encrypted-data are sent together
to the recipient (or stored together for the reader),
who uses RSA with the private key to decrypt the DEK and
then the symmetric algorithm with the DEK to decrypt the data.
This is because the public-key primitives can handle only a
limited amount of data -- e.g. 1024-bit RSA with the commonly
used OAEP formatting/padding can do at most 80-some bytes.
Moreover, directly encrypting data that might be guessed by
the adversary can itself be a security weakness.
> only could I
> not use my public key for encryption, used the private one, but I was also
> able to decrypt the message with the very same key that was used
> to encrypt
> it! This looks like symmetric cryptography to me.
Not really. An RSA privatekey is a superset of the publickey.
The private key has e, d, n=modulus, and normally factors and cofactors;
the public key has only e and n. When you encrypted, openssl actually
used only the publickey pieces; for decryption it used all of them.
> I know I lack basic knowledge about this kind of stuff, so if
> anyone were so
> kind as to point me to some tutorials / links that explain this
> knowledge in
> some detail, and also describe the different key formats (like
> PEM, PKCS#1,
> PKCS#12, .pem, .cer, .der whatever ;-)), I would be very grateful.[/color]
I don't have any good references although I'm sure there are some.
General resources like wikipedia, dmoz, google, etc. may help.
This is complicated somewhat by the fact that many commonly used formats
are defined as a part of something else. A very brief overview:
ASN.1 is a global standard machine-independent way of representing
data structures, and is used as a foundation for many other standards.
One particular variant, DER, is generally used for cryptography
(where sender and receiver must have every bit match to work).
PKCS#1 defines details (actually several slightly different variants)
of applying RSA for encryption/decryption and signing/verification.
Almost as an aside, it defines ASN.1 representations for RSA keys.
PEM defines procedures and formats for securing (encrypting/decrypting
and signing/verifying) email, but never really 'won' that application.
In the process it defined an encoding (base64) for safely transferring
data among systems that (then) did not all support ASCII, and sometimes
treated various characters as reserved, which is now very widely used;
and a style of file/message/data formats (with the ----BEGIN XXX-----
and -----END XXX----- lines) that openssl uses for various other things.
PKCS#8 and #12 define ASN.1 formats and algorithms for securely storing
(or secret) keys and/or related information such as certificates.
by their nature don't need to be kept secret, but it can be convenient to
store and manage them together with the privatekey which does.)
The X.500 series of standards from CCITT (now ITU-T) were intended
to define an international structure for securely identifying people
and entities (organizations), to be used for communicating among them
by among other things email defined by X.400. In practice it was too
clumsy and costly and people rejected it, but one part of it -- X.509 --
defined an ASN.1 format for a certificate issued by a CA (Certificate
binding a publickey to a person/entity, and a CRL (Certificate Revocation
revoking such certificates, and those parts are now used in many other
Thus, for a complete and common example, the certificate files normally used
by openssl, and most applications built on openssl (though not all, as they
can have their own code reading and parsing data and giving it to the
- optionally a concatenation of several
- PEM-labelled block(s) of base64-encoded data which is
- an X.509(v3) certificate, which in turn is
- an ASN.1 representation of a signature over various data including
- the entity's publickey, which if RSA is the PKCS#1 ASN.1 representation.
OpenSSL Project [url]http://www.openssl.org[/url]
User Support Mailing List [email]firstname.lastname@example.org[/email]
Automated List Manager [email]email@example.com[/email]