> From: [EMAIL PROTECTED] On Behalf Of wujek_srujek > Sent: Monday, 03 November, 2008 03:52
> 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] > 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? 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 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. 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 private (or secret) keys and/or related information such as certificates. (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 Authority) binding a publickey to a person/entity, and a CRL (Certificate Revocation List) revoking such certificates, and those parts are now used in many other applications. 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 library) are actually: - 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 http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
