Understanding symmetric encryption security in relation to password-based key derivation

Question

Here are some assumptions on which the question is based. If anything is wrong with this, please point this out straight away:

Let's say I have a file I want to encrypt with AES256 symmetric encryption. This requires a 256-bit key. It would be very hard to remember though. In its original form it probably contains characters with no ASCII representation, and base64 encoded is would be over 32 characters long.

Which is why I might want to use a password-based key derivation.

The job of a password based key derivation is to to compensate for the fact that the password used might be easier to guess than the actual key by making the action of checking a specific password more computationally expensive.

Now the questions:

1. Considering the password strong enough so it is will never be a weak point (let's say 100 chars, uppercase, lowercase, number, specials) can password-based encryption be as secure as just using the key itself, or does it always allow to infer a smaller set of possible keys?
2. Same as above, but in the context of gpg (assume strongest hashing algorithm with the maximum number of rounds - --s2k-digest-algo and s2k-count)
3. As the worst-case scenario for an attacker is to have to brute force guess the 256-bit key, does it make more sense to just store the key itself? (Assuming that either password or key needs to be stored, as they are both too complicated to remember)
4. If the answer to 3 is yes, then is openssl AES265 with specifying a key directly a good method of accomplishing that? From the research I have done, you can not use a key directly with gpg.

Answer 1

Considering password strong enough so it is will never be a weak point (lets say 100 chars, uppercase, lowercase, number, specials) can password based encryption be as secure as just using the key itself, or does it always allow to infer a smaller set of possible keys?

No, as long as you are able to "compress" it into a key with a suitable KDF then it is fine. Most encryption algorithms do not allow for such long keys, so compression seems a necessity. You could use a PBKDF with a single iteration or a KDF such as HKDF.

This is: assuming that the password can indeed not be guessed (they aren't alterations of a previous password, etc.). But I think that's what you meant here.

Same as above, but in context of gpg (assume strongest hashing algorithm with maximum number of rounds - --s2k-digest-algo and s2k-count)

Sure, and I would think that even the default hash (RIPEMD160) would be fine unless you need more than 128 bits for the keys. Obviously I'd rather use SHA-512.

As the worst case scenario for an attacker is to have to brute force guess the 256-bit key, does it make more sense to just store the key itself? (Assuming that either password or key need to be stored, as they are both too complicated to remember)

Sure, you could go for a base 64 encoded key. It depends on the runtime which is easier.

If answer to 3 is yes, then is openssl AES265 with specifying a key directly a good method of accomplishing that? From research I have done, you can not use a key directly with gpg.

You could use it instead of the 100 character password. At least you'd have relatively few special characters (you might want to use base64url, I'd expect underscore and dash are less troublesome than +, / and =). And 32 bytes in base64url are just 43 characters. Beware that most password managers provide methods to generate passwords though, not encoded keys.