How to encrypt using public certificate\key

[Peter Lebbing]

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 peter at 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>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170918/8f21bddf/attachment.sig>