On 07/09/17 12:58, shaarang tyagi wrote: > I am trying to understand the encryption process and the all the input > that is required to perform encryption. > > So according to this RFC, section 2.1:
If you want to learn about what makes an OpenPGP message, gpg --list-packets is very useful: $ echo Talking to myself | gpg -r pe...@digitalbrains.com -e | gpg --list-packets And now you see which packets make up a message encrypted to me. > https://tools.ietf.org/html/rfc4880#section-2.1 > > There can be 2 sources for encryption key, either a session > key(generated randomly) or a shared pass phrase (key is derived from > this phrase) ? Well, in a sense that's correct, but it's missing an important point. What GnuPG does is: - Create a random session key, unique for each encrypted message. This is what the data is encrypted with. - For each public key the data is encrypted to, include a Public-Key Encrypted Session Key Packet[1] (PKESK), which is the session key encrypted to a specific public key. - If decryption by passphrase is requested (--symmetric), also create a Symmetric-Key Encrypted Session Key Packet[2] (SKESK), which allows to decrypt the session key with the passphrase. RFC 4880 section 2.1 indeed also mentions a different method where the passphrase is used to derive the key to encrypt the data, rather than using a random session key. This is possible if the data is preceded by a single SKESK that specifies how to derive the key from the passphrase, as in section 5.3 [2]. But this type of data is never produced by GnuPG, to my knowledge. So /the/ method, the single method, to create an encrypted message is to generate a random session key which is used to encrypt the data. Then get that session key to your recipient, be that by public key or by shared passphrase. Finally, multiple passphrases that all decrypt the data (multiple SKESK packets) are permitted, but I don't think GnuPG can create such messages (I'm not sure). > gpg -e -u "Sender User Name" -r "Receiver User Name" somefile What you /should/ do is put all options before the command; that way the command line is unambiguous and gpg will always catch your meaning. "-e" is the command, and "somefile" is the command argument. So: $ gpg -u "Sender User Name" -r "Receiver User Name" -e somefile When you include options after the command, it might work, but it requires guesswork on the part of gpg, so you should avoid it. > Which method does this command uses exactly? It encrypts the data with a random session key, and encrypts the session key to the public key belonging to "Receiver User Name". To be exact, the first public key it finds in its keyring that matches "Receiver User Name". Which one is the first, you don't know, so it's best to make sure only one key matches what you give. And the command line contains useless cruft, as it specifies a signing key, but doesn't request signing of the data. So the "-u" argument is silently ignored as not relevant but not harmful either. If there is only one private key, it's never necessary to specify it by "-u". > It does message encryption with a given username's certificate's pub > key?(Is this a third method which is not mentioned in that RFC ) ? No, there's no third method to decrypt data, it's either encrypted to a public key, or a passphrase unlocks it, or both. Okay, I guess that does make three ;-). > Also, Where can i find all the commands for all the possibilities using > different key sources? Either the man page if you're on a UNIXy OS: $ man gpg Or the Texinfo documentation which is on the web[3] and can also be read on UNIXy OSes by: $ info gnupg (or a different info reader, I usually use "pinfo"). The Texinfo manual has more than the man page, and is also a lot easier to navigate. But they are mostly reference manuals, you'll still need other documentation to get you started. Let me point out, as you're perusing the OpenPGP RFC, that there is even another method[4] to encrypt data[5] to a passphrase defined there, but it's deprecated. As it should be, no salting!, obsolete cipher: > [...] If no packets of these types precede the encrypted data, > the IDEA algorithm is used with the session key calculated as the MD5 > hash of the passphrase, though this use is deprecated. Just ignore this, it's ancient. If somebody sends you such messages, please page them or send them a fax, requesting them to come over to the 21st century. It's not that scary on most days. And there is more such stuff in the RFC. If it says something like "deprecated" or SHOULD NOT or something, you can probably skip it. HTH, Peter. [1] <https://tools.ietf.org/html/rfc4880#section-5.1> [2] <https://tools.ietf.org/html/rfc4880#section-5.3> [3] <https://www.gnupg.org/documentation/manuals/gnupg/> [4] <https://tools.ietf.org/html/rfc4880#section-5.7> [5] Okay, that puts "is there a third method to encrypt" into a different light again :-) -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
