hopefully this is the right place to post this:

can someone tell me how pgp pub/private keys are formatted? there seems to be a lack of explainations on how to actually read them (and im terribly inept at reading source codes)

obviously they are in base 64. i mean beyond that. which part is the version number, the cipher, the username, email, etc? how big is each part?

hopefully, your responses can be something like:

"take this:
version (2 bytes, 00, 01, or 02)
cipher (0 = RSA, ...)
key size (x number of bytes)
modulus (n)
and combine it into one big string and change it to base64"

thanks in advance to all who answer

ur msg is not clear whether u r just a recipient of an encrypted msg u r trying to decipher. d'u actually have a key?

if u just want to know how it works, then go to

i mean the actual keys that i generated (or someone else's public key). i want to know how pgp-derivatives read the key. since the data is not exactly stored like: "cipher: RSA, key size: 512bits, email: aaa@yahoo.com". i only know a bit, like: (i think) if the first byte of the key (both public and private) is 0x01 (without the 0x), it means the cipher is RSA. what about the rest of data?

on some linux systems, you can double click a key and it will be put on the key ring, showing you all the data: the name, email, validity/expiration date, key size, etc. which parts of the public/private keys describe these properties?

r u a programmer? i'm sure u can find ur answers at that main site. i have included this text file u might find useful:

Key ID
Some packets use a "key ID" field. The key ID is the least
significant 64 bits of the RSA public modulus that was involved in
creating the packet. For all practical purposes it unique to each
RSA public key.

User ID
Some packets contain a "user ID", which is an ASCII string that
contains the user's name. Unlike a C string, the user ID has a
length byte at the beginning that has a byte count of the rest of the
string. This length byte does not include itself in the count.

Thanks for the file. i think its what im looking for.

im not a very good programmer, but yes, i do do a little python and TIBASIC, but that's it

the only reason im not looking at source codes or rfc is because im terrible at reading other people's codes, and i find rfcs very boring. i read pieces of them if i need to, but i try to avoid them

i dont get some of the first parts of the data. it says:

Key ID
Some packets use a "key ID" field. The key ID is the least
significant 64 bits of the RSA public modulus that was involved in
creating the packet. For all practical purposes it unique to each
RSA public key.

however, in key servers like http://stinkfoot.org:11371/pks/lookup?op=index&search=12345678&fingerprint=on , it shows that the keyid is 32 bits, not 64. i dont get it

thank you so much! where do you find all this? google seems to hate me or something

u just need to ask the right questions. usually when we know what the questions r, the answers will come.

most importantly, u need to enjoy what u do in order to do well. Be confident in order to progress.

yours philosophically .. :-)

well, i do enjoy learning about crypto stuff, but i suck at wording things (statements, questions, etc.) properly for some reason.

ive hit another snag:

Offset  Length  Meaning
(bytes) (bytes)
4          4       Timestamp of key creation
8          2       Validity period, in number of DAYS (0 means forever)
10         1	   Algorithm byte for RSA (=1 for RSA).

i have these 3 sets of values

01001001 11101100 11111100 01100101 

00010001 00000100


the first set is the timestamp, stating that i created the key on 4/20/2009. the next one, i believe is the validity period, is 4356 days, but that doesnt make sense, since in linux, i see it as non-expiring (which would make it 0, but that's the third set). the last one, i guess is the algorithm ID, but I dont know what the number for ElGamal is. that file you found only mentions RSA.

any ideas?

forget the algorithm id values. i found them

wait. i think i might have found what im looking for

i woke up this morning n saw ur posts from having the second problem to .. giving up to .. finding the solution all by yourself (well done there!)

dont u have to sleep? not a good idea to try solve a problem with no rest. sometimes the answer comes after a good rest.

i think u r doing fine.

thanks for being so encouraging!

and i did sleep for 7 hours or so.