Copy / paste that key into http://phpseclib.sourceforge.net/x509/asn1parse.php and you'll see that there are several different integers in there. $p$ is there, $q$ is there as is the exponent and several other integers to speed things up by taking advantage of the Chinese Remainder Theorem.
The key is encoded using DER and derives semantic meaning via ASN.1....
It is correct that the given private key does not encode a single integer, and that it includes two primes $p$ and $q$. More precisely, that Base64 data encodes a string of bytes, which is an RSAPrivateKey encoded per ASN.1 DER-TLV (and thus BER-TLV) following PKCS#1v2.2 Appendix A.1.2 (likely restricted to version 0). It decodes to:
30 ASN.1 tag for ...
To conclude the answers here's a note about the simplest way (on linux at least) to view the contents of such keys with openssl:
$ openssl rsa -in test.key -text
Private-Key: (512 bit)
how does gpg know which cipher is needed (in this case AES256 instead of the default CAST5?
The OpenPGP Symmetric-Key Encrypted Session Key Packet (RFC 4880, §5.3) says which algorithm.
wouldn't it be "better" to not tell anyone what encryption type was used?
Not really. This is a basic premise of essentially all serious cryptography for more than a ...
PGP key formats are defined in RFC 4880. Specifically, section 5.5.
The private key format includes the public key and quite a bit of other information in unencrypted form. It might be easier to add another layer of encryption on top of that before you use steganography.
As said in comment, I believe you might find answers in the SEC1v2 document, which is used in many implementations (OpenSSL, Go, mbedTLS etc.) as a reference regarding that matter and which spares you the pain of reading all the many RFCs on that topic.
Now regarding the actual facts, if I generate a private key with OpenSSL:
openssl ecparam -genkey -out ...
If you are storing the file on disk then PKCS#12 Personal Information Exchange Syntax format is best practice. It is commonly referred to as a key store. But note that PKCS#12 relies on secret key encryption to encrypt the key store entries. That generally means that entries in such a store are encrypted with password based encryption. Which of course means ...
Is there a standard or at least "commonly used" format to format the result?
PKCS #7 (and CMS which is a further development) describes a standard format for encrypted data. While it's mainly meant for public key encrypted data, it also has options for symmetric keys. It's rather complex due to all the features it supports, however, so unless you can find a ...
I think your key doesn't work, because it is only a signature key. That's subpacket 27, for which pgpdump says:
Hashed Sub: key flags(sub 27)(1 bytes)
Flag - This key may be used to certify other keys
Flag - This key may be used to sign data
The corresponding output of gpg -vv mykey.pub is
:signature packet: algo 1, keyid 836024D82FD34F7F
RFC 2313 specifies the RSAPrivateKey ASN1 structure as a SEQUENCE containing the INTEGERs
The PEM format consists of such a structure encoded as Base64 and framed by the typical BEGIN/END RSA PRIVATE KEY header and footer lines.
Thus, you can use any ASN1 library you like to ...
A hash can be computed for any input, even for an empty input.
Some tools may display the output of some hash function, other tools may not.
If the file is large, it may take some time to compute, so tools may not display the hash immediately, only on-demand.
So this is more a question about specific software than cryptography.
A hash/checksum can be calculated for any data.
However, it is up to the person publishing the file as to whether they will calculate and publish the hash.
If they do, you can check if you downloaded the same file they uploaded.
If they do not, then there is no point in calculating the hash yourself, because you have nothing authoritative to compare it ...
Yes, you're right. Every file, no file inclusive, has a checksum. SHA1 of the empty string ("") is da39a3ee 5e6b4b0d 3255bfef 95601890 afd80709. If you submit a file for hashing (checksumming), it will produce a valid output. Non display of the hash output is not related to the determination of the hash.
The layout of the format doesn't matter much. I would recommend combining all the parameters into a single cipher suite name so that you're not tempted to make nonsensical combinations: just use NaCl crypto_secretbox_xsalsa20poly1305 (or AES-GCM if you must use AES, with the caveat that it subjects your users to side channel attacks on software AES ...
For a checksum such as CRC16 or CRC32 it is very much possible to have a value over a text that contains the same CRC value (in whatever format, be it binary, hexadecimals or base 64). The proof of this is simple: you can simply put e.g. 32-48 bits counter at the end of the text and wait until you find a CRC. But in practice you can just calculate the value ...
This has to do with the physical nature of the storage device. Simply deleting the reference still leaves the data available for recovery. Writing once over randomly might still leave chunk traces of data which could be pieced together.
It is not generally considered easy to recover information overwritten once, and for your own pc... being donated or sold.....
You can use the Web tool pgpdump, available at this address http://www.pgpdump.net/ or the same tool ( http://www.mew.org/~kazu/proj/pgpdump/en/) to install on your pc.
This latter is to use if you are poking with your real secret key.
At the moment I don't remember if the tool outputs in hex or dec, but you can easily convert to your favourite Base ...