I managed to reproduce the problem which you are experiencing. I did so doing the following:
$ gpg --no-default-keyring --keyring ./test-keyring --secret-keyring ./test-secring --trustdb-name ./test-trustdb --no-random-seed-file --gen-key
<specified parameters and let it do its thing>
gpg: key 58018BFE marked as ultimately trusted
public and secret key created and signed.
<snip>
$
Notice that the process marked the key as "ultimately trusted".
Now I export the keys:
$gpg --no-default-keyring --keyring ./test-keyring --secret-keyring ./test-secring --trustdb-name ./test-trustdb --no-random-seed-file --export-secret-keys -a >private.key
$gpg --no-default-keyring --keyring ./test-keyring --secret-keyring ./test-secring --trustdb-name ./test-trustdb --no-random-seed-file --export -a > public.key
Now I import to a new gpg database:
$gpg --no-default-keyring --keyring ./test2-keyring --secret-keyring ./test2-secring --trustdb-name ./test2-trustdb --no-random-seed-file --import public.key
$gpg --no-default-keyring --keyring ./test2-keyring --secret-keyring ./test2-secring --trustdb-name ./test2-trustdb --no-random-seed-file --import private.key
Now if I attempt to encrypt using the new keyrings I get:
$ gpg --no-default-keyring --keyring ./test2-keyring --secret-keyring ./test2-secring --trustdb-name ./test2-trustdb --no-random-seed-file -r Fake -e
gpg: AE3034E1: There is no assurance this key belongs to the named user
pub 1024R/AE3034E1 2013-06-13 Fake User <fake@example.com>
Primary key fingerprint: AD4D BAFB 3960 6F9D 47C1 23BE B2E1 67A6 5801 8BFE
Subkey fingerprint: 58F2 3669 B8BD 1DFC 8B12 096F 5D19 AB91 AE30 34E1
It is NOT certain that the key belongs to the person named
in the user ID. If you *really* know what you are doing,
you may answer the next question with yes.
The reason for this is the "web of trust" model. By default, in order for a public key to be trusted, it requires either 1 "ultimate" trust certificate (typically where you personally have verified the identities of the people involved), or 3 "marginal" trust certificates (where somebody you know, who knows somebody you know ... has signed the certificate).
Because gpg is a security application, it warns you if you are attempting to encrypt to a key which is not listed as trusted. The reason your own key isn't trusted in this case is simple. It is because you did not export the trust relationships from the previous gpg instance. To do this, use the --export-ownertrust and --import-ownertrust commands.
As always, refer to the man page.
Best Answer
Besides Seahorse, which is only the key manager, you need a package called
seahorse-nautilus
to be able to encrypt/decrypt files with Nautilus.It adds a menu item to the right-click context menu that allows you to encrypt a file directly from the file manager.
Note: This is the package name in Ubuntu 14.04. Other versions may have a different package name.
Additional Note: It may be required to log out of the current session and re-login for everything to work properly after installing the required packages.