GPG Implementation of Symmetric Operations, and To-Self Encryption

[utternoncesense at gmail.com]

I have a couple of questions about GPG that fall in the range above
pure mathematical equations but below "You use this option."  Mostly
they're of the form "This is how I understand it now, can you confirm
that I've got it?"

Firstly, in pure RSA/ElGamal etc, there is no passphrase U - there's
numbers p,q,g,a,b, etc.  The way I understand it:
Your secret key is encrypted using your passphrase.  Your passphrase
essentially acts as a symmetric key, one never stored anywhere except
your head.  Am I correct in the belief that this is how it works?  I
imagine it's some type of hashing or somesuch.  If you don't want to
give all the details of transformation from passphrase to key, that's
okay, just want to make sure I understand it.

Secondly, Using the option --symmetric creates a .gpg file and prompts
you for a passphrase that the symmetric key is based on.  Decrypting a
Symmetric-ly Encrypted file is done by generic --decrypt option, and
the header, non-encrypted part of the file says "Hey this is
symmetric, prompt for a passphrase"

Thirdly, GPG is based upon a hybrid system entirely.  The data of any
file is ALWAYS encrypted symmetrically, and a symmetric key is made
for each encryption use.  The symmetric key used is then encrypted
with the public key of the recipient and the whole thing is bundled
together.

If I'm encypting something already zipped or compressed in any other
method, I should use -z 0 because trying to compress it further isn't
likely to do much, and it will slow down the processing - right?

 RSA & ElGamal use keys around 1024-2048 usually.  EC uses 160-224 bit
keys, but is based on mostly different math (it may be equivalent at
some level, but I'm neither aware nor able to understand anythig
beyond yes or no on that topic).  AES uses 256 bit.  It's not allowed
to go over 256 bit.  This is because it's an entirely different area
of cryptography?  Block Ciphers as opposed to integer factorization,
discrete logs, or curvature?  And comparing key lengths between the
three areas (IF/DS, EC, Block) without any normalization is like
comparing the engine in a semi to one in a sedan without considering
the weights of the vehicles - They both enable the vehicle to go 80
(encrypted to some rigor) but the semi needs a much larger one because
the truck weighs more (easier to test factors than undo block
ciphers).  Right?

Some questions I couldn't find answers too online:
RSA, ElGamal - I've always learned them as Asymmetric Ciphers - Public
Key/Private Key.  What algorithm does GPG use for the symmetric side
of things?  What's the size of the key? (the size of the key chosen
for the Keypair?)

For encryption of documents to myself, I can:
 - Use Symmetric Encryption with a passphrase of my choosing.  But a
passphrase seems weaker than a full blown key.
 - Use the --encrypt-to-self or --recipient options.  I encrypt the
Document using my public key so only my Private key can open it.
- Is there an option to have a Symmetric Key, that behaves like both a
public and a private key?  Obviously you'd have to not publish your
the key, but apart from that?  It may be protected by a passphrase, it
may not and rely upon the user to control Key access (an interesting
implementation would be a very large symmetric key, that is stored on
a removable media or encrypted partition that is inserted/mounted
whenever access is needed, and not allowed to be stored anywhere but
Volatile Memory)
 - Any other advised methods?

--throw-keyid --encrypt-to-self  will produce a file that, considering
all available information available in the file, is known ONLY to be
encrypted by GPG X.Y.Z with the private key of some individual.  But
may only be decrypted by myself (because it's encrypted to myself).
Right?

What would happen if I tried --symmetric --throw-keyid ?
Does ElGamal double the size of the encrypted document if used without
encryption?

Thanks for any and all answers.