a compilation of pgp oddities
there are a few oddities in the pgp message format, and differences among the pgp implementations and shells, in what is decryptable/verifiable, and what is not.
have looked at the following pgp file types:
clearsigned pgp message
armored signed pgp message
signed and encrypted pgp message
ordinary encrypted pgp message
conventionally encrypted pgp message
public key block
private key block
and have listed a few examples of some of the 'oddities'.
{ n.b. the following examples were written in html for the Opera browser, and may not display accurately in other browsers :( }
{ N.B. Before clicking on any links on this page, please read the important pgp signed notice at the end of this page's text. Thanks }
They are encrypted or signed with one or both of the following keys:
test@key.test (v3 RSA) test@key.test
boo@key.test (DH)
boo@key.test
the passphrase for test@key.test is exactly the same as the keyname, including the @ and . between key and test
the passphrase for boo@key.test is boo
{without the @key.test}
{ 'boo' is a mock scare term that my special needs daughter likes, and was happy for days to hear that a key was named 'boo'
there is no intent to boo/criticize any program/ implementation/etc. ;-) }
observations:
[1] (a) PGP will not recognize a clearsigned message with any addition before the header (on the same line as the header),
{but will identify it as a pgp signed message, and then 'search' for where it is,
as opposed to declaring that there is no pgp information there.
'any' character added before the header, even a blank space, will have this effect.}
GnuPG will also not recognize it.
This may be a source of problems with clearsigned messages undergoing minor alterations during e-mail transit or newsgroup posting, such as an extra > or - added in front of the header.
(b) Neither PGP nor GnuPG will tolerate 'any' alteration in between the line that begins with HASH: (or, in an MD5 signed file, the line that says -----BEGIN PGP SIGNED MESSAGE----- )
up to and including the line that says -----BEGIN PGP SIGNATURE-----
[2] (a) except for clearsigned messages, pgp *does* accept/decrypt/verify/import all other message types,
even if there is an extra dash before the five initial dashes of the header.
not only does it accept an extra dash before, it accepts *any and all* of the following before the beginning of the header:
~!@#$%^&*()_+`-={}|[]\;':"<>?,./-
and does so whether or not there is a space between the addition and the header,
here is an example of an armored signed file with the additions: Tase.txt
but, it does *not* accept 'any' of the numbers or letters used in the radix 64 encoding characters, 'before' the header
{the presence of any such additions cause pgp to declare that there is no pgp information present.}
GnuPG does not recognize 'any' additions before the header, even a single blank space,
and gives the following error message:
gpg: no valid OpenPGP data found.
gpg: decrypt_message failed: eof
[2] (b) 'nothing' is accepted (on the same line as the header) 'after' the five dashed lines ending the header.
[3] no substitutions or deletions within the header are accepted.
[4] the following apply specifically to clearsigned messages:
n.b.
clearsigned messages have a slightly different appearance if done in PGP or GnuPG:
PGP clearsigned messages have a blank line between the end of the text and the beginning of the PGP signature.
GnuPG clearsigned messages do not.
here are examples of a clearsigned messages, with the same plaintext, and signed with the same dh key,
one signed with PGP, Tpgpcs.txt
and one signed with GnuPG, Tgpgcs.txt
Command Line PGP {both 2.x and 6.5.8} are the same as GnuPG in this respect,
see 2.6.3multi6 test
and 6.5.8 command line test
addition or deletion of the empty line to make one appear like the other, will cause a 'bad' signature {in both PGP and GnuPG}.
Other points about clearsigned PGP messages:
(a) 'anything' can be added to the line beginning with HASH: as long as it is after the ':'
(b) the 'real' signing algorithm listed after HASH: can be replaced by a different one
[e.g. SHA1 and RIPEMD-160 can be interchanged, and verify the same way,
but will not verify in GnuPG,
will verify in 6.5.8 CKT build 6, but will display RIPEMD 160 as the signing hash in the verification block], {see example Tcsb1e.txt }
GnuPG gives the following error:
C:\gnupg>gpg --verify d:\tcsb1e.txt
gpg: invalid clearsig header
PGP greater than 5.x will verify without any indication that there were any changes, and will not indicate the true hash that was used.
If only SHA1 is substituted for RIPEMD160, but no other characters are added, {see example, Tcsb1e2.txt }
GnuPG will say bad sig:
C:\gnupg>gpg --verify d:\tcsb1e2.txt
gpg: Signature made 02/13/02 13:28:28 using DSA key ID 7B534E2D
gpg: BAD signature from "boo "
and CKT build 6 will refuse to verify.
and, again, PGP greater than 5.x, will verify without any indication that there were any changes, and will not indicate the true hash that was used.
(c) if the empty line between HASH: and the message text, is deleted, {see example, Tcsb1e3.txt }
PGP will not be able to verify, but will attempt to 'search' for the 'signed' file,and will not say 'bad sig'.
[If the message text is saved, and PGP is referred to the saved file of the message text, it will say 'bad' signature, and identify the signing key.]
GnuPG will interpret the message text as being part of the header, and give the following error:
C:\gnupg>gpg --verify d:\tcsb1e3.txt
gpg: invalid armor header: clearsigned test
(d) one subtle method of alteration of a clearsigned text, undetectable by any PGP or GnuPG version,
originally described in alt.security.pgp by SS (ssalatsk@neo.rr.com) (Jan/23/2002):
is that 'empty space' characters can be added to each line of cleartext, until the end of the line, without affecting the verification.
{The message 'content' and 'visible' form does not change, but the message 'size' does.}
If the received message undergoes some automated process upon signature verification, and file size makes a difference for that process,
then it may be an area of possible exploitability.
{have had some difficulty illustrating this on a webpage in html, but can easily be done in notepad, by clicking the spacebar any number of times on any line, as long as it doesn't produce a new extra line.}
Here is an attempt to illustrate this on a webpage:
First, the original unaltered clearsigned text: Tesnsa1.txt
Now, the same clearsigned text, with empty spaces added to the ends of the text on the numbered lines: TesWsa.txt
When verifying the file TesWsa.txt, note that the 'highlighting' takes up the entire line of the line beginning with a number, but not in the first line that says 'extra space test'.
No spaces were added to that line, so that the difference between the altered and un-altered lines could be seen more easily.
If each of the two above files are copied to clipboard and saved as .txt files, and then their file sizes checked, it can be seen that the original file, Tesnsa1.txt has a size of 433 bytes, while the 'empty-space-padded' file, has a size of 1479 bytes.
If, for example, someone has a setup where signed messages are checked and verified automatically, and if they verify ok, then undergo some storage process where file size matters, then this could be an area of possible exploitation.
If this is a potential issue for anyone's applications, then consider sending the message as a signed file with detached sig., where extra empty spaces anywhere in the file, will yield a 'bad' signature.
n.b.
while GnuPG and PGP treat extra 'spaces' at the end of a line the same way, this is not true for 'tabs'.
GnuPG does not recognize a tab at the end of a line, but makes an exception, as a courtesy to PGP 2.x, and if it thinks that the file was done in PGP 2.x, it will verify it, otherwise it will give a 'bad'
signature to PGP clearsigned files that have a line ending in a tab.
*but*
the way that GnuPG uses to decide if the message is from PGP 2.x,
is by checking for an md5 hash.
if PGP>2.x uses md5 to sign, then GnuPG will give a 'good' signature.
if plaintext with a line that ends with a 'tab' is clearsigned in gnupg, the file will verify in pgp or gnupg, whether or not the 'tab' is there, removed, or had several additional 'tabs' entered.
this is so because GnuPG does not calculate the 'tab' in the hash
when clearsigning.
also, if GnuPG is asked to clearsign a text with a line ending in a 'tab', and is asked to do so for a v3 rsa key, with any hash other than md5, it will produce a clearsigned file that will not even verify in the same GnuPG program .
would like to post examples of all these, but cannot, as there is no html code for insertion of an isolated 'tab' :(
here is an attempt at a workaround to illustrate the examples:
it is an armored file of all the examples, with the 'tabs' intact.
it can be verified in either GnuPG or PGP, then save the verified contents to clipboard, and copy the clipboard contents to notepad,
and verify the clearsigned texts from there.
ok, the armored file is here: Tabcw.txt
[5] for all other pgp message types:
(a) additions or deletions to the comment or version lines, {after the ':' of comment or version} do not affect the decryptability
(b) as many extra 'empty' lines as desired can be added in between the last comment line
and the text, or in between the comment lines and version lines.
(c) similarly, many additional comment and version lines, or any combination of them, can be added,
*but*, must begin with the word 'comment:' or 'version:', if even the ':' is missing, there will be
an 'ascii armor incomplete' error message. The words 'comment', and 'version' are not case-sensitive.
{see example, TeE1.txt }
(d) additional lines in between the last comment line and the text,
or in between the comment lines and version lines, with:
~!@#$%^&*()_+`-={}|[]\;':"<>?,./-
are ok, but any other characters result in an 'ascii armor incomplete' error message.
The above (b), and (d) are not acceptible to GnuPG:
here is the error message for the above file TeE1.txt :
C:\gnupg>gpg --decrypt d:\tee1.txt
gpg: invalid radix64 character 3a skipped
gpg: invalid radix64 character 3a skipped
gpg: invalid radix64 character 2e skipped
gpg: invalid radix64 character 3b skipped
gpg: invalid radix64 character 2d skipped
gpg: invalid radix64 character 29 skipped
gpg: invalid radix64 character 3a skipped
gpg: invalid radix64 character 3a skipped
gpg: invalid radix64 character 7e skipped
gpg: invalid radix64 character 21 skipped
gpg: invalid radix64 character 40 skipped
gpg: invalid radix64 character 23 skipped
gpg: invalid radix64 character 24 skipped
gpg: invalid radix64 character 25 skipped
gpg: invalid radix64 character 5e skipped
gpg: invalid radix64 character 26 skipped
gpg: invalid radix64 character 2a skipped
gpg: invalid radix64 character 28 skipped
gpg: invalid radix64 character 29 skipped
gpg: invalid radix64 character 5f skipped
gpg: invalid radix64 character 60 skipped
gpg: invalid radix64 character 2d skipped
gpg: malformed CRC
gpg: [don't know]: invalid packet (ctb=72)
here is the same message after removal of the line with the non-radix-64 characters: Tee2.txt
and here is the resultant GnuPG error message:
C:\gnupg>gpg -- decrypt d:\tee2.txt
gpg: invalid radix64 character 3a skipped
gpg: invalid radix64 character 3a skipped
gpg: invalid radix64 character 2e skipped
gpg: invalid radix64 character 3b skipped
gpg: invalid radix64 character 2d skipped
gpg: invalid radix64 character 29 skipped
gpg: invalid radix64 character 3a skipped
gpg: invalid radix64 character 3a skipped
gpg: CRC error; 7394b4 - 1f5b22
gpg: [don't know]: invalid packet (ctb=72)
here is the same message after the removal of any blank lines in between the comment and version lines:
TeE3.txt
and here is the GnuPG error message:
C:\gnupg>gpg --decrypt d:\tee3.txt
gpg: invalid armor header: comment:
{the absence of anything entered after 'comment:' results in an interpreted error/ incompleteness of the pgp header,
and further decryption is refused}
the addition of 'any' character anywhere on the same line, after the ':' , renders the message decryptable, even if the character is a non-radix 64 one:
{see TeEnrc.txt }
To sum up the above:
GnuPG allows additional comment and version lines, but only if:
(i) there is a character somewhere on the line
(ii) the word 'comment' or 'version' is followed by a ':'
(iii) there are no empty lines in between any of the comment or version lines
(iv) actually, lines beginning with 'anything' are ok, as long as there is a ':' someplace on the line,
see AnythingG.txt
PGP doesn't care if there is a colon or not,
see anythingP.txt
but PGP does require either an empty space between the ordinary characters, see AnythingS.txt
or any of the 'extra' characters `~!@#$%^&*()_+={}[]|\:";'<>?,./ anywhere on the line, even if there is no extra space
see AnythingE.txt
{there is no extra space, but there is a ! at the end, so it's ok for PGP}
if there is neither an extra character, nor an empty space,
then it will not be acceptable to PGP either
see AnythingN.txt
{none of the words on any of the lines are case-sensitive.}
(v) empty lines 'are' acceptable between the last comment or version line, and the message block
(vi) the 'comment' and 'version' lines, may have spaces and non-radix 64 characters *before* the words 'comment' and 'version', for both clearsigned messages, and other message types
see cavls.txt and
cavl.txt
{continuation of acceptable alterations to pgp encrypted or armored signed messages}:
(e) removal of the footer, or alteration, or substitution with any characters, is ok,
{check TeE1.txt again, i called the footer an ESP message ;-) }
{n.b. this also applies to the footer of clearsigned messages, and is so for both PGP and GnuPG, see Tcsb1fe.txt }
{here there is a difference between the front ends used for GnuPG:
Win PT follows the command line GnuPG, and will decrypt whatever the command line will.
Gpgshell does 'not', and will not recognize any of the footer alterations,
when trying to decrypt the message from clipboard.
Gpgshell 'can' decrypt it from Gpgtools.
(f) removal of the checksum, if removed together with the footer, is ok.
(This is also so, for GnuPG)
(g) removal of the checksum, without removing the footer, prompts for decryption, and after the correct
passphrase is entered, PGP gives an 'ascii armor incomplete' error message.
(This does not stop GnuPG from being able to decrypt, moreover, if the checksum were replaced by another line,
GnuPG would still decrypt, but gives the following error message. {see Tek1k2c.txt }
C:\gnupg>gpg --decrypt d:\tek1k2c.txt
gpg: invalid radix64 character 2d skipped
gpg: invalid radix64 character 2d skipped
gpg: invalid radix64 character 2d skipped
gpg: invalid radix64 character 2d skipped
gpg: invalid radix64 character 2d skipped
gpg: invalid radix64 character 2d skipped
gpg: invalid radix64 character 2d skipped
gpg: invalid radix64 character 2d skipped
gpg: invalid radix64 character 2d skipped
gpg: invalid radix64 character 2d skipped
You need a passphrase to unlock the secret key for
user: "boo "
1024-bit ELG-E key, ID F0E74948, created 2002-01-15 (main key ID 7B534E2D)
gpg: encrypted with 2048-bit RSA key, ID F77AFF7B, created 2001-04-26
"test "
gpg: encrypted with 1024-bit ELG-E key, ID F0E74948, created 2002-01-15
"boo "
gpg: no valid OpenPGP data found.
selective message block alteration test
The 'gpg: no valid OpenPGP data found.' reflects the absence of the check sum.
The exact same error message is given by GnuPG even if nothing is written in place of the checksum.
{see Tek1k2ncs.txt }
If a false check sum is substituted, GnuPG treats it as a crc error, but decrypts without the 'invalid radix64 character 2d skipped' message. {see Tek1k2fcs.txt }
Furthermore, 'anything (besides a blank space) can be added after the '=' sign of the checksum, and have the same effect.
{see Tek1k2fcse.txt }
If there are less than 4 characters following the '=' , {see Tek1k2ifcs.txt }
then GnuPG can still decrypt, but gives the following error message:
C:\gnupg>gpg --decrypt d:\tek1kifcs.txt
gpg: malformed CRC
You need a passphrase to unlock the secret key for
user: "boo "
1024-bit ELG-E key, ID F0E74948, created 2002-01-15 (main key ID 7B534E2D)
gpg: encrypted with 2048-bit RSA key, ID F77AFF7B, created 2001-04-26
"test "
gpg: encrypted with 1024-bit ELG-E key, ID F0E74948, created 2002-01-15
"boo "
selective message block alteration test
This is also so, even if there are no characters at all following the '='.
GnuPG will give the exact same error message, and decrypt as before.
The above, [5] (a) through (g), also apply to alterations within the signature block of clearsigned messages.
Here is an example of altered clearsigned messages which verify in PGP, but not in GnuPG:
Tcsb1pv.txt
and here is an example of altered clearsigned messages which verify in GnuPG, but not PGP: Tcsb1gv.txt
note that there is a slight difference here, in that GnuPG allows 'empty' lines between the 'comment' and 'version' lines for clearsigned messages, but not for other message types.
The following [(h), (i), (j),] apply to pgp 6.xx and 7.xx.
GnuPG in all implementations, does 'not' display any 'extra' additions, and will decrypt/verify only the message block,
even in the presence of additions.
CKT, all builds from 6 and on, has the option of displaying or ignoring 'non-pgp block data'. The default setting is to 'not' display 'any' additions, but it can be changed temporarily to see if anyone 'tried' to put any additions there.
(h) addition of one line with 'anything' immediately after the checksum, but with the footer removed,
does not display upon decryption.
(i) addition of more than one line after the checksum, begins to display with the second line.
(j) addition of one line with 'anything' immediately after the checksum, but with the footer intact,
interprets the footer as 'an addition' and the footer is displayed upon decryption.
{n.b. there is a special case of this for key blocks, where it is imported, but not displayed,
see
boo@key.test and look at the line at the end before the footer,
but the footer is displayed in the pgp viewer 'after' the key is imported.}
for additional quirks in how the pgp viewer is implemented, and the potential for exploitation, see vulnerabilities in the pgp viewer
[6] alterations of the message block itself:
(a) changes in font sizes, types, colors, boldness, italicization, or underlining, are all acceptable to both PGP and GnuPG,
see mblsf.txt
an interesting corollary of this, is that if the font color is exactly the same as the background color, the presence of a pgp message is not immediately apparent,
see mblsfi.txt
{use the 'current window' to decrypt it, or highlight/copy with the mouse}
it is a way to include pgp messages in a webpage, or pdf.
it can also be used for some exploits, {again, see above
vulnerabilities in the pgp viewer }
Any alteration whatsoever, even the addition or substitution of only one character, will give a 'CRC error' in GnuPG.
(b) spaces at the 'beginning' of a line of the message block, are acceptable to PGP, but only if it is the 'exact' same number of spaces as in front of the header,
see mbls.txt
this is not acceptable to GnuPG, as GnuPG does not allow even a single empty space in front of the header.
(c) additions or deletions of any character after the first line but before the last line, of the message
block, will result in a pgp error of 'bad packet' and un-decryptability by pgp.
{Additions to the last two lines of the pgp message block [the check sum, and the one before it], will not affect the decryptability
by GnuPG or the either of the winpt or gpgshell front ends, as long as the GnuPG option of -ignore-crc-error is used.}
{The additions do not have to be in blocks of 4, or be padded.} see Tepp.txt
{PGP will give an error message of 'bad packet, found no PGP information in clipboard}
(d) substitutions within the message block depend on where (which packet and/or tag) it is,
and may cause the key to be listed as 'unknown', the key to be 'dropped', bad packet, or 'encryption session key is bad'.
(the key shows up that it is present, when checking it in pgp dump, but no key is listed in the pgp decryption window)
A substitution of any character in the PGP message block (besides the checksum), will result in an inability to be
decrypted by PGP, and result in any of several different error messages, depending where the substitution is.
The following are examples of a PGP message encrypted to two keys, 'test' and 'boo',
and the effects, error messages and decryptability of a substitution of only one character in one selected place.
Although PGP cannot decrypt it, it is interesting that GnuPG (including the shells), 'can' decrypt the message if one of the public key packets is intact.
Although PGP will detect only one of the decryption keys,
pgpdump, and -gpg --list-packets, will detect both of them.
First, the unaltered decryptable message:
Tek1k2.txt
Now the altered one: Tek1k2jb.txt
The 6th line, last character, was changed from 7 to 1
PGP does not detect that the message was encrypted to 'test@key.test' at all,
and upon entry of the proper passphrase, gives an error of 'ascii armor incomplete'.
{which indicates that the message was tampered with}
GnuPG (and the front ends), first identify that the message was 'tampered' with, and
gives a CRC error,
and then upon entry of the proper passphrase, identifies encryption to both keys, 'test' and 'boo',
and decrypts it,
but only with the 'boo' key.
If the 'test' key is tried, and the correct passphrase entered, there will be an error message of 'wrong secret key'
here is the GnuPG error message after intentionally entering the 'wrong' passphrase for the 'boo' key, and trying to decrypt with the 'test' key:
You need a passphrase to unlock the secret key for
user: "test "
2048-bit RSA key, ID F77AFF7B, created 2001-04-26
gpg: encrypted with 2048-bit RSA key, ID F77AFF7B, created 2001- 04-26 "test "
gpg: public key decryption failed: wrong secret key used
gpg: encrypted with 1024-bit ELG-E key, ID F0E74948, created 2002-01-15
"boo "
gpg: public key decryption failed: bad passphrase
gpg: decryption failed: secret key not available
actually, PGP can also decrypt the message with the 'boo' key, without any problems, once the checksum and the footer are removed,
{removal of the checksum and footer in a PGP message accomplishes the same as an option of 'ignore-crc-error' in GnuPG}
[7] secret keys, and changing passphrases
when a passphrase is changed, the private key block changes
when the passphrase is changed back to the original passphrase,
the private key block changes again, but 'not' back to the original private keyblock that had the original passphrase.
see the original keyblock for test@key.test:
test@key.test
here is the keyblock for the same key with the passphrase changed to Test@key.test test@key.test, new passphrase
{the only change was from a lower case t to a capital T},
and here is the private keyblock after the passphrase was changed back to the original:
test@key.test , passphrase changed back
this can be repeated as many times as desired, resulting in a different private keyblock each time,
much the same as 'any' pgp encrypted message, of the same plaintext, encrypted to the same key, will result in a different message block each time.
this is so, because the symmetric encryption session key, is chosen at random each time.
ordinarily, this is of little practical interest, except for the following uncommon problem:
there is a form of private key, that will cause GnuPG to malfunction;
it is when the encrypted MPI of the secret key block starts with a zero octet:
an example is listed below the following link that describes the problem reported with a key of this type, and also describes a workaround fix:
http://lists.gnupg.org/pipermail/gnupg-devel/2002-June/007267.html
" ... It's probably an encrypted MPI started with a zero octet. This problem is already known, I think.
Workaround: Create a new directory, copy the secret key (in non-armored from) to "secring.gpg", use "gpg --home . --edit-key" to change the passphrase. It's likely that the result is readable by GnuPG (the bug is triggered with a probability of 1:85 or so). ...
"
{n.b. this was fixed in 1.2.0, and is a problem only in 1.0.7 or earlier }
here is an example of the key being discussed:
{an ordinary v3 rsa test key, generated in CKT, and imported into GnuPG}
first, the 'safe' form of the key:
keypic@key.test 'safe'
now the 'problem' form:
WARNING: THIS WILL CAUSE GNUPG TO MALFUNCTION AND GNUPG WILL 'NOT' BE ABLE TO DELETE THE OFFENDING SECRET KEY ONCE IT MALFUNCTIONS.
BACKUP THE SECRING.GPG, PUBRING.GPG, AND TRUSTDB FOR THE KEYRINGS BEFORE IMPORTING THIS KEY.
to restore GnuPG to the way it was before the key was imported, replace the secring.gpg, pubring.gpg, and trustdb with the backups.
it is not necessary to re-install GnuPG.
okay, here is the problem form:
keypic@key.test, UNSAFE FOR GNUPG
if it is imported into GnuPG 1.0.7, the problems will become evident when trying to export a secret key, and GnuPG will give an error message of "mpi too large", and will refuse to export the key, or do any operations involving a secret key.
if it is in 1.0.6, the malfunction will involve many more GnuPG operations.
i found this by accident when trying to import it into GnuPG, and tried re-installing several times, until it was pointed out to me that my keyring is probably corrupt {Thanks, Imad!}, and then i was able to isolate the problem key, and forwarded it to where the problem was found {Thanks, Robert, and Florian Weimer!}
changing the passphrase of the key, from 'keypic' to 'okay, not keypic' avoided any further problems in GnuPG
as 1:85 is not that rare, it is surprising that this problem is not encountered more often,
but it might still be prudent to backup the secring, pubring, and trustdb, before changing a passphrase, or importing a new key pair, or secret key,
and to be aware of this issue if GnuPG suddenly begins giving error messages of 'mpi too large'.
it is possible to check a secret key to see if it has this type of 'problem'
zero octet encrypted mpi, by checking the key with pgpdump: pgpdump interface
{N.B. do NOT do this online for a 'real' secret key, as the entire keypair can then be intercepted. It is for demonstration purposes only.
to check your own private keys after passphrase changes, use a copy of pgpdump downloaded to your hard-drive.
the pgpdump homepage is here:
pgp dump homepage with source code }
the 'unsafe' form of the 'keypic' secret key, displays as:
PGPdump Results
Old: Secret Key Packet(tag 5)(928 bytes) Ver 3 - old
Public key creation time - Thu May 23 14:41:06 UTC 2002
Valid days - 0[0 is forever]
Pub alg - RSA Encrypt or Sign(pub 1)
RSA n(2048 bits) - c4 5a f1 97 b7 50 94 f4 70 7d 6d c2 65 ab c2 34 7b 05 27 6e 29 cb 80 f1 ff 8b fc 74 2c 8a bf fe da 09 da 3a 5b 76 6e b2 f2 12 83 ff 0b 46 b4 01 67 dc e0 d4 8a a6 f6 7d 6f dc b2 15 df 73 1d 40 86 28 17 14 27 3d cd a3 85 d6 12 26 8f dc 35 d2 7e e7 6b 65 cd 03 13 57 72 a3 5c 6e 20 97 28 bb 7a 14 3f 24 c7 2c a3 43 bc 8b 42 94 05 8b 95 d4 4e 8a 69 a2 3a 21 e8 6b e2 2c 6c 36 b0 4a 30 92 f9 2c 7f 39 b2 a3 c0 28 39 f3 a4 7f f9 0f ec d2 19 48 43 86 0d 2f 5c d3 59 3a a4 2c 08 8f de 6e 4a 67 ad 9f 80 e1 c6 0a 7d 51 75 db 46 c2 e6 27 3c 1f 8e fd 56 2b 21 0c 41 b3 f4 84 68 cc 4c 34 3a 06 65 44 bf db e5 30 3f c3 76 dd c9 dd 09 3e a4 b4 b3 2a 4d bc a6 d9 3a 2c 43 5e 21 6a 8f 13 17 a1 1a f8 2e b9 70 1f 29 a3 c7 d3 a0 09 a5 cf d6 8f c5 97 6e e5 df e1 01 3e da 2b 0c dd fc 6b
RSA e(5 bits) - 11
Sym alg - IDEA(sym 1) IV - 98 61 5a b5 79 4e 00 4f
Encrypted RSA d(2045 bits) - 00 61 ff 84 df 3f 8c fa 4b 88 ea 7c 85 33 c6 da 60 b7 53 0d 0e 2f 90 82 76 e5 fd 67 a7 27 fe ac 15 1e 4c 5e 87 43 79 57 da 21 8d 4b 49 a5 64 62 bb 40 da c4 19 28 38 93 de 3c 27 70 ff 87 2a 92 c1 61 2d 91 34 04 60 6c 69 eb 45 34 3f 6c 9e 42 0f ef b8 a2 16 6a 96 45 5e d5 18 9f 26 3a 62 c1 41 13 36 4b ef f3 91 0c 1e 0a 80 46 e6 ec 68 8f 16 37 72 22 aa f0 96 4c 97 ef 70 79 66 54 c1 6a 4e 83 a6 9d c2 e3 48 e5 2b 85 de 24 01 a7 1b 66 89 ac 47 0a 83 b3 1f 05 f9 77 dc ea 41 72 93 44 61 35 ba 91 3f 9e 27 4e cc 9f 3f 52 54 3c a3 45 ee dc 60 3a 28 fd fe cc 44 04 88 4b ed f8 2a 6c 68 84 51 eb 48 d5 81 28 fa 73 e8 88 aa 66 3a 00 75 dc 08 6b 2a cb 25 c8 96 dc d2 10 ed 44 0c e6 1c cc 0c 03 03 a3 c0 59 75 84 68 9c a9 55 42 45 29 64 a0 a4 ad af 60 08 8c 51 88 5c a8 00 a5 af
Encrypted RSA p(1024 bits) - 64 73 da 89 bd 21 9d 17 d4 50 4c fd e8 53 87 36 6b b2 4a f4 89 2f 28 68 76 56 45 28 be 45 3b 34 46 b0 ba 87 04 b4 61 81 08 48 e5 8c 67 4d fb c2 a6 94 b8 93 6f 76 1c 45 0b a9 0b 19 3c d6 d2 85 3c 16 35 eb 4b 41 af d5 90 1c 68 58 29 55 c6 b1 ca e5 dc af d8 96 62 27 bc 9d 9e f1 e7 9c 45 96 22 b8 4f 11 71 82 a4 92 2b b4 6b 1d 2c 68 55 1e c6 22 0e d6 76 d5 74 c8 28 c1 a9 d6 51 b0 0c a1
Encrypted RSA q(1024 bits) - a7 38 2b 41 dc da 00 00 62 3c f5 c6 7c 42 99 24 7c d3 01 7e 17 79 58 b1 18 73 1f 6b 55 bb e4 cf 65 e1 05 52 dd a0 e8 66 62 dd 77 7c 58 37 26 3f f3 50 65 d3 91 b8 19 fa b7 23 0e 94 8d 3a 60 87 5d 61 03 78 ec 98 9f 89 a8 14 07 42 fd 35 33 97 fc f6 3f 7e 50 19 ba 52 0b 91 d9 8b a2 9e 04 77 f9 05 ca 04 cb df 31 ae 2f e2 94 af 3a 15 22 cd 29 3e 4d 80 1f d2 7f dd 2b 17 27 a8 ab b0 66 4b
Encrypted RSA u(1023 bits) - d2 e8 77 ba aa 8a e4 d8 08 80 51 7d 2e c1 e5 3d 81 be 9f ee 64 27 d2 85 02 64 04 d0 43 d2 8b d3 50 20 29 79 1d 0e 54 97 90 70 53 42 bb 47 ce c6 35 27 d4 15 a0 65 37 72 99 e3 4d 42 2b 84 21 0d 0b 22 b3 d9 f2 bf 38 c5 18 90 6e 89 6f 37 50 80 a5 6f dc 17 8a 90 77 d1 04 14 93 ed 7f 88 0e 92 90 fb c7 7b d2 c0 96 7f f8 15 8b de 14 29 dc 47 02 78 7d cf 5f b2 b0 61 8f 2a c5 8f a0 eb ac ec
Checksum - 3e 32
Old: User ID Packet(tag 13)(24 bytes) User ID - keypic
here are the results for the 'safe' form of the key, with the passphrase changed:
PGPdump Results
Old: Secret Key Packet(tag 5)(928 bytes)
Ver 3 - old
Public key creation time - Thu May 23 14:41:06 UTC 2002
Valid days - 0[0 is forever]
Pub alg - RSA Encrypt or Sign(pub 1)
RSA n(2048 bits) - c4 5a f1 97 b7 50 94 f4 70 7d 6d c2 65 ab c2 34 7b 05 27 6e 29 cb 80 f1 ff 8b fc 74 2c 8a bf fe da 09 da 3a 5b 76 6e b2 f2 12 83 ff 0b 46 b4 01 67 dc e0 d4 8a a6 f6 7d 6f dc b2 15 df 73 1d 40 86 28 17 14 27 3d cd a3 85 d6 12 26 8f dc 35 d2 7e e7 6b 65 cd 03 13 57 72 a3 5c 6e 20 97 28 bb 7a 14 3f 24 c7 2c a3 43 bc 8b 42 94 05 8b 95 d4 4e 8a 69 a2 3a 21 e8 6b e2 2c 6c 36 b0 4a 30 92 f9 2c 7f 39 b2 a3 c0 28 39 f3 a4 7f f9 0f ec d2 19 48 43 86 0d 2f 5c d3 59 3a a4 2c 08 8f de 6e 4a 67 ad 9f 80 e1 c6 0a 7d 51 75 db 46 c2 e6 27 3c 1f 8e fd 56 2b 21 0c 41 b3 f4 84 68 cc 4c 34 3a 06 65 44 bf db e5 30 3f c3 76 dd c9 dd 09 3e a4 b4 b3 2a 4d bc a6 d9 3a 2c 43 5e 21 6a 8f 13 17 a1 1a f8 2e b9 70 1f 29 a3 c7 d3 a0 09 a5 cf d6 8f c5 97 6e e5 df e1 01 3e da 2b 0c dd fc 6b
RSA e(5 bits) - 11 Sym alg - IDEA(sym 1) IV - 96 17 68 fd d6 65 11 22
Encrypted RSA d(2045 bits) - e5 87 dd 78 5f db 85 09 75 88 e3 4e 66 c5 3a 43 58 f5 3d 09 a5 f3 76 67 84 04 c5 9e e7 07 06 9b da f3 ac 83 68 cb 52 75 48 9a 84 38 2b 56 76 56 c1 13 c9 b4 68 7e 37 6c d9 41 73 07 02 60 9d fa 56 ae fc dc f1 65 4e 16 d8 13 40 08 3e fa 19 bd 31 d1 c9 e3 1a 9d 29 25 2f b7 02 80 73 af 51 c3 4e 4a b7 03 36 b4 d7 b6 49 b7 7d 96 02 97 61 83 f3 6e 10 f6 5b 8a 80 17 a5 69 96 e6 e2 ad ef c2 22 26 14 d1 41 24 c8 6d 46 82 7f 29 59 41 73 84 e6 d1 ca 0c 7f 3f 56 d9 3b d5 0c c9 28 53 cb fb b0 ce f3 f1 c8 51 9a 21 2a 3a 54 79 7b bd ac 7f 55 ca d8 77 d1 9a df 91 1d 69 35 ea 74 69 03 41 57 b2 00 e3 34 27 01 1a 8f 97 bb 28 34 02 2d da 60 0b a1 57 f5 59 57 5e ea f9 71 97 e1 24 e2 0a ac 97 84 89 05 65 83 80 93 42 bd 15 8a ad e8 46 08 36 61 4d ee 0c cd 80 f1 b1 4d 0e 96
23 27 ea
Encrypted RSA p(1024 bits) - 73 d8 68 71 08 ca ab 1f a6 d6 e5 62 fe 5d 92 61 d2 b1 bd 36 a2 64 bf fc 01 4e 78 88 fb b4 d4 dc 35 9d af 5d b7 e2 ab b5 d8 0a 6a 0c 67 13 70 31 d3 28 b1 8a fc c5 89 5c a4 97 3d 6a f0 ab 85 64 29 da e7 e6 c4 b7 a9 02 45 a3 4c c1 0f 17 3e 9b 0b df 4a c8 35 8d 12 09 81 84 44 e7 c8 94 8a 55 7a f9 e5 81 1f 53 b2 44 f4 c1 39 33 ca 20 d1 37 2f f5 f4 85 1a da 2d 0c f9 f4 cf 06 ac bb 01 95
Encrypted RSA q(1024 bits) - 06 a6 b4 c7 1c 68 2b 20 7e 54 d4 86 db 53 88 c1 64 6d 3c ae 85 be 88 bf 73 ad ea c0 69 ba d3 98 6e 78 2b da 38 04 2e 39 49 0f 05 2c 10 18 21 aa 59 80 a2 6c 33 f8 f0 5a da f8 5d 3a 12 02 b9 2e 52 ba 53 96 ca 58 cc cd fd 6a 21 bd 88 0e 13 9e 37 58 8f 9f 2b 9f 8c fe a2 d8 51 68 22 af fe 14 4e 8c 75 07 3f 79 73 24 db e6 df 48 8b a0 63 e8 cc 1a ee 52 d6 f6 57 ff b5 d2 56 2f 97 6a 05 5b
Encrypted RSA u(1023 bits) - cd 2b ac cf 0f 73 de b0 ab ef e3 5b 79 05 d2 71 a9 63 af 8e 4a 67 fd 17 17 58 ca a0 11 e2 60 b7 f2 2e 2c 8a af 11 69 72 b4 3f e1 0c a4 e6 aa 14 a5 f4 17 01 e6 64 ed d2 ee fd bd 75 a3 c2 9f f8 09 7d 2c a6 11 e3 3c fe 91 b2 86 41 08 f6 85 0e 1c 1f eb d7 77 0c 2f b9 36 1b 07 d7 b9 ba 4d 20 7c 19 83 5d 59 56 63 bd f2 42 b0 fa 67 63 fe d1 70 9d 99 1c b5 b1 ca 74 b3 82 c4 ab 74 8a d8 d8
Checksum - 3e 32
Old: User ID Packet(tag 13)(24 bytes) User ID - keypic
compare (unsafe): Encrypted RSA d(2045 bits) - 00 ... and (safe): Encrypted RSA d(2045 bits) - e5 ...
the 'zero octet' is present at the beginning of the key encrypted packet in the 'unsafe' form,
and is not present in the 'safe' form.
it might be a good idea to check the secret key in pgpdump for '00' at the beginning of an encrypted packet, and if present, backup the keyrings and trust db before importing to GnuPG.
{n.b. the zero-octet issue applies only to 1.0.7 or earlier, it has been fixed in 1.2.0 }
[8] Armored files (not 'armored, signed', just 'armored')
An interesting, useful feature of GnuPG and PGP,
is to be able to armor 'any' file type, and represent it in ascii text form, and include it as part of an encrypted message.
This allows any file to be sent as part of the e-mail itself, rather than as an attachment.
This can be done only from the command line, but 'all' the command lines are ok
{PGP 2.6.x, PGP 6.x, GnuPG}.
There is only one way to do this from the PGP command line, but there are two very different ways to do this
from the GnuPG command line, only one of which is decipherable by PGP.
The following are examples of how a wordpad .rtf file can be armored and deciphered by each method:
{an .rtf file was chosen because wordpad is present in most post-3.x windows versions, but the same principle holds for
any file type.}
First, for reference, the original wordpad file:
armorT1P.rtf
(a) Now, the armoring as done by GnuPG with the following command:
C:\gnupg>gpg -a --store d:\armorT1p.rtf
gpg: NOTE: old default options file `C:\GnuPG\options' ignored
gpg: writing to `d:\armorT1p.asc'
here is the example of the resultant .asc file:
armorT1P.asc
this can easily be retrieved in the original file form by any post 2.x version of PGP, by using pgptools,
(or in PGP 8, 'pgpmail') and double-clicking on the saved .asc file,
nothing else needs to be done to the .asc file first.
PGP will identify the original un-armored file, and ask where to save it.
to retrieve it from GnuPG is also very simple,
*but*:
the gnupg commands of --decrypt --verify do not retrieve the original file,
but are useful in that they do list the orginal filename before it was armored:
here is the GnuPG output of the --decrypt command:
C:\gnupg>gpg --decrypt d:\armort1p.asc
gpg: NOTE: old default options file `C:\GnuPG\options' ignored
gpg: armor: BEGIN PGP MESSAGE
gpg: armor header: Version: GnuPG v1.2.1-nr1 (Windows 98)
:compressed packet: algo=1
:literal data packet:
mode b, created 1049221931, name="armorT1p.rtf",
raw data: 273 bytes
gpg: original file name='armorT1p.rtf'
{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fnil\fcharset0 Times New
Roman;}{\f1\fswiss\fprq2\fcharset0 Arial;}}
\viewkind4\uc1\pard\qc\ul\b\f0\fs32 Formatting Test\par
\par
\ulnone\i\f1\fs24 just to see if the file is recovered intact\b0\i0\f0\fs20\par
}
here is the GnuPG output of the --verify command:
C:\gnupg>gpg --verify d:\armort1p.asc
gpg: NOTE: old default options file `C:\GnuPG\options' ignored
gpg: armor: BEGIN PGP MESSAGE
gpg: armor header: Version: GnuPG v1.2.1-nr1 (Windows 98)
:compressed packet: algo=1
:literal data packet:
mode b, created 1049221931, name="armorT1p.rtf",
raw data: 273 bytes
gpg: original file name='armorT1p.rtf'
so, how 'can' the intact file be retrieved using GnuPG?
simply by typing gpg and then the filename
C:\gnupg>gpg d:\armort1p.asc
gpg: NOTE: old default options file `c:\gnupg\options' ignored
gpg: armor: BEGIN PGP MESSAGE
gpg: armor header: Version: GnuPG v1.2.1-nr1 (Windows 98)
gpg: armor header: Comment: Acts of Kindness better the World, and protect the Soul
:compressed packet: algo=1
gpg: armor: BEGIN PGP MESSAGE
gpg: armor header: Version: GnuPG v1.2.1-nr1 (Windows 98)
gpg: armor header: Comment: Acts of Kindness better the World, and protect the Soul
:literal data packet:
mode b, created 1049221931, name="armorT1p.rtf",
raw data: 273 bytes
gpg: original file name='armorT1p.rtf'
File `d:\armort1p' exists. Overwrite (y/N)?
This can also be retrieved in a similar manner, from the PGP commandline
(same command for either PGP 2.x or 6.5.8 : pgp filename}
D:\d263m6>pgp d:\armort1p.asc
Pretty Good Privacy(tm) 2.6.3ia-multi06 - Public-key encryption for the masses
(c) 1990-96 Philip Zimmermann, Phil's Pretty Good Software. 2002-04-22
International version - for use everywhere (including USA).
Current time: 2003/04/11 19:32 GMT
PGP is now using IDEA with MD5.
tempfile: created 'd:\armort1p.$00'
de_armor_file: infile = d:\armort1p.asc, outfile = d:\armort1p.$00, curline = 0
tempfile: created 'd:\armort1p.$01'
Decompressing plaintext...done. rmtemp: removing 'd:\armort1p.$00'
tempfile: created 'd:\armort1p.$00'
strip_literal: infile = d:\armort1p.$01, outfile = d:\armort1p.$00
File type: 'b'
Original plaintext file name was: 'armorT1p.rtf'
rmtemp: removing 'd:\armort1p.$01'
Output file 'd:\armort1p' already exists. Overwrite (y/N)?
here is the way the way armoring is done from the PGP commandline:
D:\d263m6>pgp -a d:\armort1p.rtf
Pretty Good Privacy(tm) 2.6.3ia-multi06 - Public-key encryption for the masses
(c) 1990-96 Philip Zimmermann, Phil's Pretty Good Software. 2002-04-22
International version - for use everywhere (including USA).
Current time: 2003/04/02 15:56 GMT
PGP is now using IDEA with MD5.
tempfile: created 'C:\WINDOWS\TEMP\armort1p.$00'
make_literal: infile = d:\armort1p.rtf, outfile = C:\WINDOWS\TEMP\armort1p.$00,
mode = 'b', literalfile = 'armort1p.rtf'
tempfile: created 'C:\WINDOWS\TEMP\armort1p.$01'
squish_file: infile = 'C:\WINDOWS\TEMP\armort1p.$00', outfile = 'C:\WINDOWS\TEMP
\armort1p.$01'
Compressing file...compressed. rmtemp: removing 'C:\WINDOWS\TEMP\armort1p.$00'
Output file 'd:\armort1p.asc' already exists. Overwrite (y/N)?
here is the resulting armored file:
armorT1Ppgp26x.asc
the same command works from the PGP 6.5.8 commandline:
D:\ckt8\PGP>pgp -a d:\armort1p.rtf
Pretty Good Privacy(tm) Version 6.5.8ckt http://www.ipgpp.com/
(c) 1999 Network Associates Inc.
Export of this software may be restricted by the U.S. government.
Transport armor file: d:\armort1p.rtf.asc
here is the resulting file:
armorT1Ppgp658.asc
note that when this is done from 6.5.8 or from GnuPG, the .asc extension is added to the original filename and extension,
and this makes retrieval of the original file much easier.
when this is not done, then PGP 2.6.x or GnuPG will recover the file with just the filename without 'any' extension ('armorT1P' in our example)
the filename would then need to be re-named with original extension added, for full retrieval of the original file.
*but*
(b) when it is done from GnuPG the second way, with the --enarmor command,
it can be decrypted by GnuPG, *only* by the --dearmor command:
first, the enarmor command:
C:\gnupg>gpg --enarmor d:\armort1p.rtf
gpg: NOTE: old default options file `c:\gnupg\options' ignored
File `d:\armort1p.asc' exists. Overwrite (y/N)?
here is what the 'enarmored' file looks like:
enarmorT1P.asc
now, the 'de-armoring' :
C:\gnupg>gpg --dearmor d:\armorT1P.asc
gpg: NOTE: old default options file `C:\GnuPG\options' ignored
gpg: writing to `d:\armorT1P.gpg'
gpg: armor: BEGIN PGP MESSAGE
gpg: armor header: Version: GnuPG v1.2.1-nr1 (Windows 98)
now simply renaming 'armorT1P.gpg' to the original filename (in this case, armorT1p.rtf) restores the original file
here is what happens when dearmoring this type of file is tried in GnuPG with the gpg command:
C:\gnupg>gpg d:\armor\enarmort1p.asc
gpg: NOTE: old default options file `c:\gnupg\options' ignored
gpg: armor: BEGIN PGP ARMORED FILE
gpg: armor header: Version: GnuPG v1.2.1-nr1 (Windows 98)
gpg: armor header: Comment: Use "gpg --dearmor" for unpacking
gpg: [don't know]: invalid packet (ctb=7b)
note the new header and footer in 'enarmort1p.asc'
-----BEGIN PGP ARMORED FILE-----
-----END PGP ARMORED FILE-----
also note that the message block here begins with 'e' rather than 'ow' as for almost every
other armored or armored signed file
(it doesn't need to begin with an 'e', and can begin with other letters too, but it will 'not' begin with 'ow')
as it cannot be decrypted by GnuPG with any command other than '--dearmor',
so, as a guide, GnuPG automatically adds the comment line of:
Comment: Use "gpg --dearmor" for unpacking
another unusual point here, is that the armoring done in GnuPG with the --enarmor command, or in
PGP with the -a command, will result in exactly the same message blocks no matter when or how many times they are done.
this is the only time {afaik} that a pgp message block remains the same on repeated commands
this is not so, when using the GnuPG command of -a --store
the --store command adds a time of creation packet, which changes every time the message is armored.
{n.b.
with regard to GnuPG enarmored files in PGP:
here there is a difference between the commandlines of PGP 2.6.x and 6.5.8:
PGP 2.6.x does 'not' recognize the 'ARMOR' headings,
and refuses to to anything further with the file:
here is the PGP 2.6 output:
D:\d263m6>pgp c:\enarmort1p.asc
Pretty Good Privacy(tm) 2.6.3ia-multi06 - Public-key encryption for the masses
(c) 1990-96 Philip Zimmermann, Phil's Pretty Good Software. 2002-04-22
International version - for use everywhere (including USA).
Current time: 2003/07/17 18:22 GMT
PGP is now using IDEA with MD5.
tempfile: created 'c:\enarmort1p.$00'
de_armor_file: infile = c:\enarmort1p.asc,
outfile = c:\enarmort1p.$00, curline = 0
Error: 'c:\enarmort1p.$00' is not a ciphertext, signature, or key file.
rmtemp: removing 'c:\enarmort1p.$00'
For a usage summary, type: pgp -h
For more detailed help, consult the PGP User's Guide.
exitPGP: exitcode = 3
The 6.5.8 commandline has no problems with the new file type,
and quickly de-armors the file:
D:\ckt8\PGP>pgp c:\enarmort1p.asc
Pretty Good Privacy(tm) Version 6.5.8ckt http://www.ipgpp.com/
(c) 1999 Network Associates Inc.
Export of this software may be restricted by the U.S. government.
Plaintext filename: c:\enarmort1p
note that it is still necessary to rename the file,
and add on the original filename extension,
in order to retrieve the original file.
[9] armored, signed files
well, what if you like the idea of sending a file within the e-mail message body, but don't like to use the command line, can it still be done?
yes, very easily, by armored-signing it.
in PGP, use either PGPmail (PGPtools in pre-PGP 8), or right -click on the file from any file-listing menu, and click on PGP, then on sign, and when the signing window opens, uncheck the 'detached signature' box, and then check 'text output'.
the result will be a .asc file of the original file and its signature.
here is an example of the same .rtf file used above, but this time as an armored signed file:
armorT1PasPGP8.asc
to recover the file, use PGPmail/(PGPtools) or double-click on the file.
PGP will verify the signature and save the original separated unsigned file, (and by default, will prompt to save it with the original filename and extension).
this can also be done just as easily from either of the two front-ends for GnuPG:
(a) from WinPT:
use file manager, select the file, select sign, and when the signing window opens,
check 'normal signature' and 'text output'
(it is not necessary to place the 'armor' option into the options file/gpg.conf)
(b) from GPGShell:
open GPGTools, and click on the plain signing window
(the one with the quill without a letter D {for detached sig}, and without the letter C {for clearsigning})
then when the gpgshell menu opens, asking which key you want to sign with, click the box on the top right corner of the window where it says 'ASCII armored'
either way, the GnuPG output will be a .asc file similar to the PGP one:
armorT1PasGnuPGfe.asc
[10] File splitting and reconstituting:
A very interesting property of armored pgp files,
is that they can be used to split *any* file type
into any number of fragments of any desirable size,
and reconstitute them to the original file,
and can do so cross-platform.
So, if someone has a large program, and wants to split it,
send the fragments and reconstitute it,
it is a trivial (although minorly tedious) thing to do using any open pgp implementation.
All that is necessary is to armor the program,
and then split the resulting textfile into smaller parts of suitable message size,
and send it as an inline e-mail text,
and then concatenate the texts of all the fragments,
and then restore the program by de-armoring it.
This can be done using simple armoring, armored signing, armored encrypting, or armored signing and encrypting.
Here is an example of a 2.5 mb TrueCrypt container (tct.tc), that was signed and encrypted with the 'boo' key,
and split into 5 parts;
Etct1of5.txt
Etct2of5.txt
Etct3of5.txt
Etct4of5.txt
Etct5of5.txt
Copy the Etct105 as is, and then copy only the pgp armored blocks in all the others, concatenate them together,
and save the entire text as c:\Rcn12345.tc.asc
(Practically, the easiest way to do this is to use a programmer's text editor that can display line numbers.
For the splitting and reconstituting, i used
Crimson Editor
(freeware) Excellent, but not yet portable to run from a usb drive.
A nice free programmer's editor that *can* be run from a usb drive without installing it on the host machine, is EditPad Lite
So, to make things a little more fun and interesting, i have included it in the TrueCrypt container,
and you can recover it when you reconstitute the file.
The passphrase for the TrueCrypt container is:
password
So, once you have reconstituted Rcn12345.tc.asc and saved it, either decrypt it using PGP, or open gnupg and type:
gpg C:\Rcn12345.tc.asc
gnupg will ask you for the passphrase for the 'boo' key,
enter it, and gnupg decrypts, verifies the signature, and saves the TrueCrypt container as
C:\Rcn12345.tc which can then be mounted as any TrueCrypt container can, and the contents recovered.
As TrueCrypt containers can be as small as 19 kb (as FAT), any filetype that might be blocked as malware,
can be put into a TrueCrypt container, and signed and encrypted and sent as a text e-mail (in fragments, if necessary).
Signing and Encrypting is preferred over simple armoring, both for reasons of privacy, and for trust, so that the receiver can see who is sending the .exe programs,
and decide if it is wise to run it or not ;-) .
With the increasing size of gmail, yahoo, and other mailboxes,
it is now possible to store up to a few gig of 'backup' of whatever is 'really important' to you.
For privacy, you can put it into TrueCrypt containers, and split the containers and save them securely in your e-mail,
without anyone, (even your e-mail provider ;-) ), knowing what types of files are being saved, or even how big the individual files are.
It should not be difficult to make a simple script in python, perl, bash, or even Microsoft Visual Basic, to automate the file splitting and reconstituting.
(If anyone does write such a program, please let me know, Thanks!)
[11] files signed with more than one signature at a time:
in GnuPG, it is possible to sign a message or a file with two separate keys, at the same time (well, maybe a second or two later ;-) )
as of now, this can be done only from the command line.
examples of simultaneous double signed files, are here:
double-signed messages
the messages are verifiable in PGP from 6.x onwards, with the exception of clearsigned double-signed messages causing PGP 6.x to crash.
this is not confined to two signatures, but can be as many as desired, just as multiple simultaneous 'encryption' can be to as many different keys as desired.
this can be useful if someone wants to send a signed and encrypted message to several different people, who, for whatever reason, each have their own different public key (never uploaded to any keyserver), for that sender.
each receiver can verify the message independently for his/her key.
[12] Separation of signed and encrypted messages into signed messages
that can be re-encrypted to someone else, leaving the original signature intact.
In June 2001, Don Davis published a paper entitled:
"Defective Sign & Encrypt in S/MIME, PKCS#7, MOSS, PEM, PGP, and XML."
{available here: Davis paper, on Defective Sign and Encrypt
}
In the paper he explains that the way that simple 'sign and encrypt' is done,
can lead to the following situation:
Alice, in a hurry, signs and encrypts a message to Bob, saying:
"must speak with you ,
very important,
meet me at Pier 17 tomorrow at 7pm
--Alice"
Bob, who for some reason, is currently not too pleased with Alice,
{surprisingly treacherous situations have been known to occur in the ongoing Bob and Alice cryptodrama ;-) }
decides to play a trick on her, and separates her signed message, signature intact,
from the signed and encrypted message, and re-encrypts it and sends it to a mutual acquaintance,
(but not really a friend), Charlie,
who now receives a signed message from Alice, thinking that she urgently wants to meet him!
The paper goes on to describe/recommend a possible solution:
First encrypt, and then sign and encrypt the already encrypted message,
The resultant message, if separated into the signed message,
is still just a signed encrypted message, and cannot be understood if re-forwarded
to anyone other than the person to whom it was encrypted.
Until now,{afaik}, while this is acknowledged to be 'possible',
there is no existing PGP implementation that can accomplish this separation
for a message that was encrypted to a DH or RSA V4 key.
It can, however, easily be done in PGP 2.6.3 for v3 keys, and messages that
were signed and encrypted to them.
In order to demonstrate this, it is necessary to have two more new keypairs:
one for the sender, and one for the receiver, both here:
sender and receiver keypairs
we start out with a simple text message, and use Disastry's 2.6.3 multi 6
version to sign and encrypt the file, signing by 'sender', and encrypting to 'receiver':
here is the PGP command and output:
D:\d263m6>pgp -seat d:\1st1.txt -u sender receiver -jpjd
RIPEMD160 chosen for message digest algorithm.
3DES chosen for conventional encryption.
Pretty Good Privacy(tm) 2.6.3ia-multi06 - Public-key encryption for the masses
(c) 1990-96 Philip Zimmermann, Phil's Pretty Good Software. 2002-04-22
International version - for use everywhere (including USA).
Current time: 2003/08/14 16:40 GMT
PGP is now using 3DES with RIPEMD160.
A secret key is required to make a signature. tempfile: created 'C:\WINDOWS\TEMP
\1st1.$00'
tempfile: created 'C:\WINDOWS\TEMP\1st1.$01'
signfile: infile = 'C:\WINDOWS\TEMP\1st1.$00', outfile = 'C:\WINDOWS\TEMP\1st1.$
01', mode = 't', literalfile = '1st1.txt'
searching key ring file 'secring.pgp' for userid "sender"
You need a pass phrase to unlock your RSA secret key.
Key for user ID: sender
2048-bit key, key ID 626F4B0D, created 2002/10/29
Enter pass phrase: Pass phrase is good. searching key ring file 'pubring.pgp'
for keyID 626F4B0D
Just a moment....rmtemp: removing 'C:\WINDOWS\TEMP\1st1.$00'
tempfile: created 'C:\WINDOWS\TEMP\1st1.$00'
Recipients' public key(s) will be used to encrypt.
encryptfile: infile = C:\WINDOWS\TEMP\1st1.$01,
outfile = C:\WINDOWS\TEMP\1st1.$00
searching key ring file 'pubring.pgp' for userid "receiver"
Key for user ID: receiver
2048-bit key, key ID 30F42FA9, created 2002/10/29
tempfile: created 'C:\WINDOWS\TEMP\1st1.$02'
Compressing [d:\1st1.txt] compressed.
rmtemp: removing 'C:\WINDOWS\TEMP\1st1.$02'
rmtemp: removing 'C:\WINDOWS\TEMP\1st1.$01'
Output file 'd:\1st1.asc' already exists. Overwrite (y/N)? y
armor_file: infile = C:\WINDOWS\TEMP\1st1.$00,
outfile = d:\1st1.asc, filename = d:\1st1.txt
Transport armor file: d:\1st1.asc
exitPGP: exitcode = 0
rmtemp: removing 'C:\WINDOWS\TEMP\1st1.$00'
here is an example of the signed and encrypted file: d:\1st1.asc
1st1.asc
Now for the separation:
first, the following command:
D:\d263m6>pgp -dt d:\1st1.asc
Pretty Good Privacy(tm) 2.6.3ia-multi06 - Public-key encryption for the masses
(c) 1990-96 Philip Zimmermann, Phil's Pretty Good Software. 2002-04-22
International version - for use everywhere (including USA).
Current time: 2003/08/14 16:44 GMT
PGP is now using IDEA with MD5.
tempfile: created 'd:\1st1.$00'
de_armor_file: infile = d:\1st1.asc, outfile = d:\1st1.$00, curline = 0
tempfile: created 'd:\1st1.$01'
File is encrypted. Secret key is required to read it.
decryptfile: infile = d:\1st1.$00, outfile = d:\1st1.$01
searching key ring file 'secring.pgp' for keyID 30F42FA9
Key for user ID: receiver
2048-bit key, key ID 30F42FA9, created 2002/10/29
You need a pass phrase to unlock your RSA secret key.
Enter pass phrase:
Enter pass phrase: Pass phrase is good. Just a moment....
Recipients:
receiver
Memory used: 8k
3DES.rmtemp: removing 'd:\1st1.$00'
tempfile: created 'd:\1st1.$00'
Decompressing plaintext...done. rmtemp: removing 'd:\1st1.$01'
tempfile: created 'd:\1st1.$01'
rmtemp: removing 'd:\1st1.$01'
This file has a signature, which will be left in place.
Output file 'd:\1st1' may contain more ciphertext or signature.
Output file 'd:\1st1' already exists. Overwrite (y/N)? y
savetemp: renaming 'd:\1st1.$00' to 'd:\1st1'
exitPGP: exitcode = 0
{cannot put this file up as an html page, as there are many encoded characters
that do not display ;-( }
but it can be armored and displayed by the following command:
pgp -at d:\1st1
Input file 'd:\1st1' looks like it may have been created by PGP.
Is it safe to assume that it was created by PGP (y/N)? y
Note: 'd:\1st1' is not a pure text file.
Output file 'd:\1st1.asc' already exists. Overwrite (y/N)? n
Enter new file name: d:\1st1asf.asc
armor_file: infile = d:\1st1, outfile = d:\1st1asf.asc,
filename = d:\1st1, clearname =
Transport armor file: d:\1st1asf.asc
exitPGP: exitcode = 0
here is the example of the armored signed file, separated from the signed and encrypted file:
1st1asf.asc
note that this message block does not begin with the characters 'ow'
as for ordinary armored signed messages, and clearly looks like it was
not sent by the original sender,
(although it unquestionably verifies that the sender did sign it)
*but*
if the unarmored file d:\1st1
(which couldn't be posted here,
but which you can eaily reconstruct yourself with the command line entries as above)
is re-encrypted to any other (v3 key) person,
then it *does* 'look' like it was signed and encrypted by the same person.
Here are the 2.6.3 commands and output for the re-encryption:
D:\d263m6>pgp -eat d:\1st1 test@key.test -jd
3DES chosen for conventional encryption.
Pretty Good Privacy(tm) 2.6.3ia-multi06 - Public-key encryption for the masses
(c) 1990-96 Philip Zimmermann, Phil's Pretty Good Software. 2002-04-22
International version - for use everywhere (including USA).
Current time: 2003/08/17 15:10 GMT
PGP is now using 3DES with MD5.
Input file 'd:\1st1' looks like it may have been created by PGP.
Is it safe to assume that it was created by PGP (y/N)? y
Note: 'd:\1st1' is not a pure text file.
File will be treated as binary data.
tempfile: created 'C:\WINDOWS\TEMP\1st1.$00'
Recipients' public key(s) will be used to encrypt.
encryptfile: infile = d:\1st1,
outfile = C:\WINDOWS\TEMP\1st1.$00
searching key ring file 'pubring.pgp' for userid "test@key.test"
Key for user ID: test
2048-bit key, key ID F77AFF7B, created 2001/04/26
Output file 'd:\1st1.asc' already exists. Overwrite (y/N)? n
Enter new file name: d:\1st1RE.asc
armor_file: infile = C:\WINDOWS\TEMP\1st1.$00,
outfile = d:\1st1RE.asc, filename = d:\1st1, clearname =
Transport armor file: d:\1st1RE.asc
exitPGP: exitcode = 0
rmtemp: removing 'C:\WINDOWS\TEMP\1st1.$00'
here is the re-encrypted file to the 'test' key:
1st1aRE.asc
the signature is the same as when it was encrypted to 'receiver'
(this can be confirmed by separating 1st1RE.asc as previously with the -dt command,
and then armoring it with the -at command,
and the resultant separated armored signed file is the same as the one
that was separated from the original signed and encrypted file.)
While this can be done now, only from files done in pgp 2.x ,
it is theoretically possible from any PGP/GnuPG program for any key,
with a (not yet done) hack to the code, enabling a -d type command.
[13] Separation of a signed and encrypted message into a free-standing verifiable clearsigned message.
In [12], it was shown that a signed and encrypted message could be separated and re-encrypted,
it can also be separated and made into a clearsigned message,
again, (afaik), of all the current PGP/GnuPG implementations, it can be done only in PGP 2.x
the description and demonstration is here:
separation of signed and encrypted messages into clearsigned messages
{this doesn't work in the 6.x commandline.
using the -b command there just decrypts, but doesn't save the signature, although, again, it is 'possible' to have a (not yet done) hack to the code.}
*but*
it *is* already possible 'now' for *any* key type, by using a different open pgp implementation of the pgp commandline, that is currently available, ( and endorsed by PRZ ):
filecrypt
even the download demo can accomplish the separation with the -b command
{i haven't yet gotten the -d command to be able to accomplish a re-encryption
of a separated signed message }
here is the demonstration for a message encrypted and signed using DH/DSA keys:
separation of signed and encrypted DH messages into verifiable clearsigned messages
so, be careful of what you sign, you never know where it may eventually turn up ... ;-)
i hope that this has been interesting ;-)
Please e-mail me if there are any inaccuracies in any of the above, or for any suggestions / comments / etc.
Thanks,
vedaal
my pgp keys are:
v3 rsa
size: 2048
key id: 0x6A05A0B785306D25
fingerprint: 96A6 5F71 1C43 8423 D9AE 02FD A711 97BA
v4 rsa
size: 4096
key id: 0x5AA20C866A589A97
fingerprint: ED03 5602 A6A9 093F 0BF7 1BD0 5AA2 0C86 6A58 9A97
v4 rsa
size: 4096
key id: 0x506F4FA1D35FB186
fingerprint: C982 4216 3053 B6F3 62F2 7DC0 506F 4FA1 D35F B186
they are available here:
my keys
-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
N.B.
it has come to my attention that there are ads for pgp related products
on my pages.
any ads on my pages are done *without* my consent or awareness.
i set my pages up taking care to avoid any ads *at all* on the page itself,
and chose the option of having separate pop-ups instead, which the reader
can close at will
the presence of 'embedded' ads for pgp related products, is something 'new'
which
i have seen today for the first time.
(ordinarily i use the opera browser which does not show the embedded ads,
but happened to check my page today using a netscape browser)
the *only* 'commercial' pgp products that i have tried and recommend are:
[1]PGP 8.x (currently distributed by the PGP Corporation)
[2]PGP 6.5.8 commandline (currently distributed by NAI)
[3]Hushmail, and Hushmail products/services
i have purchased my own copy of PGP Personal edition,
and encourage any/all who can afford it, to purchase a copy,
and support the PGP Corporation,
and its generosity in providing free editions for personal use.
with Thanks, Appreciation, and Respect,
to the current and previous PGP owners,
vedaal
Sept.2, 2003
-----BEGIN PGP SIGNATURE-----
Version: 6.5.8ckt http://www.ipgpp.com/
Comment: Acts of Kindness better the World, and protect the Soul
Comment: KeyID: 0x6A05A0B785306D25
Comment: Fingerprint: 96A6 5F71 1C43 8423 D9AE 02FD A711 97BA
iQEVAwUBP1ZhBGoFoLeFMG0lAQNfFgf/TCJGex5xEKFFPcDr/OC5Xr7qWMTWj8Mn
/UfClehAwacb8yPc0zgzuiiDC1Bc/X2FmWSoC66uVOokuY7PLxszNbEYgztP4WiY
U2mwsLtlDG+a21xx3BsowXQVHJ8F4V93KiBGqouS1RsSWpyoERQnhODIp82BNi+Y
m/oUby29uJkk4S6eljKDQuXgH2Lhr8KELvnKTfncMRVfmOJg+oZcMHmWy9sNN6k/
FpH8YK90ZDfshDzfMH6dKkFzFrtKPT+mxrsCFb5XS8HzcDQAoR1pBEZfrSW9L1uJ
mVHB6BUg+ratqqn0qBflqR6DWL90jI9ENQhKaH7SuY2m8wVQ864IOg==
=Cr5p
-----END PGP SIGNATURE-----
e-mail : vedaal at hush dot com
