+.TP
+.BI \-t " timestamp"
+Specify a timestamp to be used for signing instead of the current time.
+Must be specified as a decimal representation of the unix timestamp
+to be used.
+.SH PACKET AND FILE FORMAT
+.PP
+Signatures and keys are output as hexencoded packet bytestrings. All are 256
+bytes, (512 bytes as hex encoded). Reserved bytes in packet formats must be
+zero. The last 8 bytes are reserved.
+.PP
+On disk format is a series of 32 bytes, hex encoded, followed by
+a newline. This takes one line per 32 bytes, thus 4 lines for 128,
+8 lines for 256. If we waste 8 bytes at the end, we have 8 lines
+and 512 bytes encoded, the last line will be short by 16 characters,
+so that the actual size on disk is 512 bytes.
+.PP
+Timestamps are 8 byte little endian integers of seconds since the epoch. or
+unix time, or some such. Times are a mess. Unix time is leap second unaware,
+and ambiguous during leap seconds. UTC requires a database of leap seconds for
+past time, and the specified second in the future possibly changes. TAI is
+good, but currently 37 seconds behind UTC, which is just weird.
+.PP
+All key and signature data begin with an 8 byte header, consisting of
+the following:
+.EX
+5A 50 4D 53 = "ZPMS" in ascii.
+01 = one byte version number
+xx = one byte packet type
+xx xx = two bytes packet information
+.EE
+.PP
+There are the following packet types.
+.SS Private Keys
+The public key is derivable from the secret key, so the public key is not
+explicitly stored.
+.EX
+private key format is:
+"ZPMS" 4 byte magic "ZPMS"
+byte 0x01 = version 1
+byte 0x01 = private key
+byte 0x01 = chacha encrypted, 0x00 = plain/raw key bytes
+byte 0x00 reserved, probably "key usage"
+32 bytes private key
+8 bytes creation time, little endian
+8 bytes expiration time, little endian
+8 bytes password salt, note, nist wants 16, but we're not using nist
+approved hash algorithms anyway.
+64 bytes reserved
+could have 16 bytes of IV for chacha to encrypt.
+Can probably use those, hashed with the password as the salt, but
+not very much salt then.
+120 bytes id
+8 bytes reserved trailer
+.EE
+.SS Public Keys
+.EX
+public key format is:
+"ZPMS" 4 byte magic "ZPMS"
+0x01 1 byte version
+0x02 1 byte "public key packet"
+0x00 1 byte reserved
+0x00 1 byte reserved
+0x.. 32 bytes public key
+0x.. 24 bytes reserved : create, expire, 8 reserved
+0x.. 64 bytes reserved : self sig
+ 120 bytes reserved : id = 1 byte id length, n bytes id, zeros
+ 8 bytes reserved trailer
+0x.. revocation signatures
+0x.. user id packets
+0x.. certification signatures
+0x.. sub key packets
+.EE
+.SS Signatures
+Data, Key, and Revocation signatures all have the same format,
+with the exception of the packet type byte at offset 5. Type
+0x03 is a data signature used for signing arbitrary data. Type
+0x04 is a key signature used to sign public keys. Type 0x05 is
+a revocation signature, used to revoke signatures.
+.EX
+"ZPMS" 4 byte magic "ZPMS"
+0x01 1 byte version
+0x03 1 byte "signature packet"
+0x00 1 byte reserved
+0x00 1 byte reserved
+0x.. 8 bytes timestamp of signature time
+0x.. 8 bytes timestamp of signature expiration, 0 if none
+0x.. 64 bytes of actual signature
+0x.. 32 bytes of public key making the signature
+0x.. 8 bytes reserved
+ 120 bytes reserved
+ 8 bytes reserved trailer
+.EE