You can decrypt the file with your private key and the other person's public key.

The public key contains no information about the private key, and no amount of processing can derive the private key from the public key (or the public key from the private key). The key pair is created by an algorithm that causes the two to be halves of a one-way symetrical operation.

For the details on the algorithm, see Wikipedia's RSA and DSA pages. However, unless your degree is in mathematics, you will have to take it as an act of faith that these algorithms have been subjected to public scrutiny, and have been found secure, for now.

Let's try another way. In Wikipedia is this postal example:
Alice sends message to Bob. She asks for padlock (public key?).
So Bob creates padlock (public key) and key (private key), right?.
He sends his public key to Alice. So now Alice has only Bob's public key?. So she encrypts the message with this public key and I wonder... so what exactly she does?. Is this some kind of "latch"
padlock?. Does this mean that she can't decrypt her message(open
the padlock)?. She can only send back the message to Bob?.
And only Bob can open it?.

That's correct. Once encrypted for someone else (your private key, their public key), even the originator cannot decrypt the file.

So I need only someone's public key to encrypt message and
this person must have this public key and his private key to decrypt it?.

But what about this kernel source authentication?.
I have public key and hashed signature and it seems that I
decrypt this signature with public key. I don't need and have private key, have I?.

That's why I asked question about whether public and private key
of one person are connected. I think it is like in this postal example public key is a padlock and private key is a key to this padlock, so can't someone cut the key to the padlock having this
padlock?. I think it's possible.

Again, you need the other person's public key, and your private key to encrypt. The other person needs your public key and their private key to decrypt.

That's a signature, not an encrypted file. The algorithms and process is different.

No, it is not possible. If you can "solve" the problem without using hundreds of thousands of CPUs in a reasonable time (decades of processing), you will be forever famous.

So we exchange public keys?. I send my public key to someone and
someone encrypts message with it and sends the message back with his public key so I can decrypt it?.

Well, it doesn't fit into this postal analogy. Because how can I
lock padlock which is not mine with my key?.

Well, so encrypting message and signing message are two different things?.

Could you explain what I have to do to sign message (theory - not how it's done in particular program). And what the other person
has to do to verify signature (well, this part I guess I know from
kernel source example). I use public key and decrypt signature with it and this signature is compared with sequence of letters and numbers derived from signed file. The sequence is created on my computer locally, as it is done in md5 verification. Am I right?.

At this point, we are not covering new ground, but simply reiterating the same points over and over. I understand that you find the material confusing, but asking the same questions and getting the same answers will not enlighten you.

I suggest that you set up two login accounts on your Linux system. Generate a key pair for each account. Exchange files, sign files, and orbserve how the software operates. Attempt to defeat the process by any means you see fit. You have the environment to empirically validate the process and understand the operation yourself.

Document what you find, and present it in a way that makes sense to you, so that others may benefit.

Yes, I think this is the best way. Thank you for patience.

I created two accounts as you suggested. I used KGpg GUI
And here are the results:
1. Receiver produces pair of keys
2. Sender produces pair of keys
3. Receiver sends his public key to sender
4. Sender imports receiver's public key
5. Sender signs receiver's public key with sender's private key (must enter password referring to sender's pair of keys)
6. Sender encrypts file with receiver's public key (signed with
sender's private key)
7. Sender sends encrypted message
8. Receiver decrypts file with his pair of keys (must enter password
for his pair of keys).

I have one question: why is point 5 needed?.

This is really like this "latch" padlock concept.

Step 5 is not needed. By signing someone else's public key, you are assigning a level of trust to that key. It's somewhat like like using a certificate authority on the web, but with more shades of gray:

unknown

Nothing is known about the owner's judgment in key signing. Keys on your public keyring that you do not own initially have this trust level.

none

The owner is known to improperly sign other keys.

marginal

The owner understands the implications of key signing and properly validates keys before signing them.

full

The owner has an excellent understanding of key signing, and his signature on a key would be as good as your own.

More details here.

Well, is it not needed?. But without signing someone's public key with my private key I can't encrypt file. There is not even
such key to choose from in menu of KGpg. Level of trust is set to
0. When I sign public key level is 100%. And only then I can
encrypt file. Does KGpg - GUI give only 0% and 100% level of security available?. Do I have to use command-line gpg to
set other levels?.