Second request for comments...
Gyre <[email protected]>
| Newsgroups | gmane.comp.security.pgp-n-gpg |
|---|---|
| Message-ID | <[email protected]> |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Aloha all,
I've completed the second draft of my article and the changes include
some new text, slight changes in the old text, some spelling and
punctuation corrections and so on..
As before, I invite anyone who may be interest to read and comment on
it. All comments will be gratefully accept and appreciated.
Thanks in advance for your time and effort...
[I intend to donate this article to the PGP-BASICS group, for whatever
purpose they may wish to make of it, when it is 'done.']
Have a wonderful day!
Aloha, a hui hou...
======================================================================
The Anatomy of a an OPEN PGP encrypted message.
Reference: rfc2440bis-08 ("A work in progress") (which can be read at:
<http://www.ietf.org/internet-drafts/draft-ietf-openpgp-rfc2440bis-08.txt>)
Disclaimer: The information contained herein is for explanatory purposes
only! It is intended only for the enlightenment of those
people who are 'beginers' or 'newbies' in the use of PGP
and/or GPG.
INTRODUCTION: OPENPGP messages have a unique format that is easily
identified This article attempts to explain why the format
appears as it does and, generally, how PGP/GPG operates on
the included information.
{descriptionS of the various messsage encrytion/decryption
processes is consider beyond the scope of this article and
**NO SUCH DESCRIPTIONS** are provided.
NOTE: The terms 'code,' 'coded,' codes,' and 'coding.' as used herein
are intended to refer to the transfer of information from one
representative form to another, usually to make that information
easier to handle. this transfer in no way changes the underlying
'meaning' of the information nor does it 'obscure' the meaning
(as encryption would). Certainly, 'secret' coding schemes can,
and probably do, exist, but the schemes described herein are a
matter of 'public knowledge' and available for use by anyone who
wants to use them.
I An 'OPENPGP' message has six basic components.
An OPENPGP message is arranged as six easily identified components.
This provides a way for 'humans' to easily check the message for
various kinds of possible 'damage' that may have occurred in transit.
More importantly, it allows PGP/GPG to easily identify the various
areas and to make any decisions that 'it' needs to make concerning
them. When PGP/GPG properly 'identifies' a particular component it
follows certain proscribed steps to 'deal' with it.
The sections, or 'parts' are:
a. An Armor header line ('-----BEGIN PGP MESSAGE-----' in the most
commonly encountered messages)
b. Armor headers: (such as:)
1. Charset: ISO-8859-1
2. Version: GnuPG v1.2.1-nr1 (Windows 2000)
3. Comment: Please use PGP/GPG for your e-mail privacy
c. A 'blank' line. [1]
d. The ASCII Armored data: (such as:)
(hQQOAyB042JrqsjvEA//Q3X14KcYkhzy ...)
e. An ASCII Armored check sum (of the form '=U7Nb').
f. An Armor tail ('-----END PGP MESSAGE-----' in the most commonly
encountered messages)
II The 'Armor Header Line' ('-----BEGIN PGP MESSAGE-----')
Actually, 'the Armor header line' is at least two lines because it is
specified that it be preceded by a 'perfectly' blank line or 'white
space.' [1] It 'signals' the start of an OPENPGP encoded message.
When PGP or GPG 'parses' a message it simply examines and discards
every byte it encounters until it reaches this line. Then it starts
paying attention looking for certain 'clues' as to how to handle the
message decryption.
III The 'Armor Headers'
The 'Armor Headers' provide certain 'clues' to PGP or GPG as to how
to handle the message decryption. Each 'Header" consists of two
parts, known as the 'key' and the 'value.' The 'key' is a word like
'Charset', 'Version', or 'Comment' (the most common ones)
immediately followed by the characters ': ' (a colon and a space).
'Comment' keys are ignored by PGP and/or GPG probably because
they may possibly contain information that 'it' wouldn't understand
and which would only tend to confuse matters.
The 'Charset' key and value is used to identify the original
character set used to produce the message before it was encrypted.
The idea is that PGP and/or GPG produce an 'exact' copy of the
original message after decryption. Generally, PGP and/or GPG will
do what it can but only if it supports the desired character set.
Otherwise, it may have to substitue a different character set.
Interestingly, this allows for the development of PGP or GPG
versions that support, for instance, character sets of the
'ideographs' used in Chinese, Japanese and other languages.
Of course, that requires support from the underlying computer
operating system and the word processor or e-mail client used.
The 'Version' key and value is used to identify the version of PGP
or GPG, or whatever, that originally encrypted the message. This
could be important because there may be differences beteen the
various versions that need to be accounted for. Also, things that
a version of PGP does may be done entirely diferently by GPG, or
some other encryption application. Knowing that these differences
exist can allow for appropriate adjustments in message processing...
IV The 'Blank Line'
The specification for an OPENPGP message requires that a blank line
precede the armored data block. This may be a slight case of
misdirection as what is important here is not the blank line,
itself, but the 'LES' [1] that produces it. Two 'LES's in
succession, one at the end of the last 'Armor Header' and the one
in the 'blank' line, signal the start of the 'Armored data' block.
And this is what PGP and GPG look for.
V The 'Armored data' block
The existence of ASCII Armor needs a bit of an explaination:
During encryption, PGP or GPG produces a stream of 'bits' [2] that
are assembled into 'bytes' which have '256' possible combinations.
Any of these combinations can appear in the encrypted product.
Of the '256' possible bit combinations for any byte, only about '95'
are regarded as 'printable' characters by most operating systems,
word processors and e-mail clients; The remainder, '161',
combinations are not.
The 'printable' characters include all the characters that are typed
with a single key, or a single key plus the 'Shift' key, on most U.S
keyboards. These range from the 'space' character (byte value '32'
decimal) to the 'tilde' ("~") byte value '126' decimal) and include
the numbers '0' through '9'; the uppercase letters 'A' through 'Z';
the lowercase letters 'a' through 'z' and the various punctuation
marks, signs and other miscellanious marks that you see on your
keyboard. Unfortunately not even all of these printable characters
are 'faithfully reproduced,' as the author intended, by every
operating system, word processor and e-mail client...
The 161 combinations that are not considered printable can be
'interpreted', and inappropriately used, in many different ways,
depending on the circumstances, by client software when inserted
in a message. Many may be used as hidden formatting characters.
There is no way to predict how these differing interpretations and
inappropriate uses may affect PGP' or GPG's decryption of a message.
Worse yet, some computer systems have been known to 'strip' the
high bit (bit-7) from every byte which has a value of '128' (decimal)
or higher (that's half of the possible byte combinations!). This
completely changes the 'meaning' of that byte and will definately
prevent proper decryption of the message that contains it
To get around the difficulties that this situation presents, the
Base-64 encoding system was introduced. In this system only 64 of
the characters regarded as printable - the ones least likely to be
misinterpreted or damaged - are used. The selected characters are
shown in the following table:
Value Encoding Value Encoding Value Encoding Value Encoding
0 A 17 R 34 i 51 z
1 B 18 S 35 j 52 0
2 C 19 T 36 k 53 1
3 D 20 U 37 l 54 2
4 E 21 V 38 m 55 3
5 F 22 W 39 n 56 4
6 G 23 X 40 o 57 5
7 H 24 Y 41 p 58 6
8 I 25 Z 42 q 59 7
9 J 26 a 43 r 60 8
10 K 27 b 44 s 61 9
11 L 28 c 45 t 62 +
12 M 29 d 46 u 63 /
13 N 30 e 47 v
14 O 31 f 48 w (pad) =
15 P 32 g 49 x
16 Q 33 h 50 y
As noted, "=" character is also used but only as a 'placeholder'
or 'padding byte.
In this system, three encrypted message byte are encoded into four
ASCII Armor bytes; This results in an increase in the original size
of the encrypted message by a full one third (33 1/3 %).
The encoding is performed as follows:
a. the first three encrypted message bytes are gathered into a
24-bit grouping (in a register, usually) like this:
+--first byte---+-second byte---+--third byte---+
|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
Note that the high order bit, or 'Most Significate bit,' is on
the left while the low order bit, or "Least Significant bit,' is
on the right for each byte.
b. The bits are then examined in groups of six bits which can have
a 'byte value' {2] of from '0' to '63'. This byte value is used
as an index into the table, above, to find its equivalent
character.
+--first byte---+-second byte---+--third byte---+
|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
+-----------+---+-------+-------+---+-----------+
|5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0|
+--1.index--+--2.index--+--3.index--+--4.index--+
c. The eight bit byte representation of the table character 'value'
is used as a direct replacement for the six bit index value
(usually in a 32-bit register). When all four replacement
characters have been assembled, the four character group is
placed in the proper position in the message body.
+--first byte---+-second byte---+--third byte---+--fourth byte--+
|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
This represents a four byte group that has an appearance such as
'AAAA' or 'hQQ0'. (The first group contains three message bytes
each with the byte value of '0' while the second contains three
message bytes with byte values of '133' '4' and '52' (decimal).)
d. This continues until all the message bytes are encoded.
e. If the encrypted message had a number of bytes that was evenly
divisible by '3' that's all that happens. However, there is a
likelihood that there may be '1' or '2' odd bytes left over. If
so, a single left-over message byte would be encoded as two ASCII
Armor characters plus two padding chracters '=' to make it four
characters wide. The group would have this form: 'hQ==" (this
carries a single message byte with a byte value of '133'
(decimal)).
If there are two odd bytes, they are encoded with three ASCII
Armor characters plus a single padding byte '='. It would have the
form 'hQQ=' (which carries two message bytes with byte values of
'133' and '4' (decimal) respectively)).
Since it takes a minimum of two ASCII Armor characters to encode
a single message byte, you should never see more than two padding
characters in the last message group. If you see more, then
something is not right...
Decoding the four character groups is essentially the reverse of
encoding:
a. Take the first four character ASCII Armored group and, using each
included character in order from left to right. Enter the table
and obtain its associated value. Place the six-bit representation
of this value into the appropriate position in a register. When
all four characters have been processed the register will appear
as follows:
+-----------+---+-------+-------+---+-----------+
|5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0|
+--Value 1--+--Value 2--+--Value 3--+--Value 4--+
b. Then remove the bits, eight at a time, to form the program bytes
as follows:
+--first byte---+-second byte---+--third byte---+
|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
c. Successively, decode each of the remaining four character ASCII
Armored groups, as above, until all have been processed.
d. The last group signals the number of valid message characters
it carries by the number of padding bytes it contains. If there
are none then it contains three message bytes. If it has one
then it carries two message bytes and if it has two then it
carries only one message byte. So for this final group you
remove the proper number of bytes from the register accordingly.
VI The ASCII Armored 'Check sum'
To help determine whether the received encrypted message is
identical to what was originally sent, a 'check sum' is provided.
Internally, when decrypting the message, PGP or GPG develops a
similar check sum. When decryption is complete, the internally
generated check sum is compared to the check sum included within the
message; if they match there is a high probability (around 16.8
million to 1) that NO changes have occurred.
The 'Check sum' group appears immediately after the last ASCII
Armored message line but on a seperate line by itself. It is
proceded by an '=' character. PGP and GPG use the combination of an
'LES' followed immediately by the '=' character to accurately locate
it. This check sum consists of four ASCII Armor characters as
described above and the group is encoded and decoded in exactly the
same manner.
The check sum carries three bytes with individual byte values of
from '0' to '255' just like every other byte. Numbers in this range
require two place hexadecimal decimal numbers to express them so
this equates to a six place hexadecimal number. A six place
hexadecimal number has a maximum value of '0xFFFFFF'; which is
equal to '16777215' decimal. So there are '16777216' possible check
sum values (256 cubed)...
The 'Check sum' is generated by 'running' the bare message bytes
(ASCII Armor removed) through a 24-bit CRC check sum 'generator.'
The process essentially makes the message bits into one 'very long'
binary number that is continuously divided by '0x864CFB' ('8801531'
decimal) until all that is left is the 'remainder' of the division.
That 'remainder' is then encoded as the 'check sum.'
During decryption of the message, PGP and PGP perform exactly the
same CRC 'division.' If the remainder obtained is identical to the
'Check sum' included in the message it is highly unlikely that the
message suffered any damage in the transition of the message from
the originator to the recipient...
VII The Armor tail ('-----END PGP MESSAGE-----' in the most commonly
encountered messages)
This merely confirms to PGP and GPG that it has indeed reached the
end of the message (which it already 'knew' when it finished
operating on the 'Check sum.')
Its greatest value is in defining the end of the message for humans
and other processors that may not know much about the PGP/GPG
process.
VII I hape you find this information interesting and, perhaps, useful!
(Written by:)
Jim McQueeney
Kapolei, Hawaii
07/22/2003
[1] The 'Line Ending (bit) Sequence' (LES) is a bit sequence expressed
as one, or more, bytes. Basically, the 'LES" tells your word
processor, e-mail client, or whatever, to 'stop printing on this
line and print everything that follows on a new line.' The key
labled 'Enter', on most key boards, is usually responsible for
inserting this sequence. (and it's interesting to note that on some
key boards, what most of us know as the 'Enter' key is called the
'New Line' key.)
In the Windows operating system the 'LES' is two bytes with the
respective (decimal) values of '13' and '10'. which are sometimes
known as a CrLf (Carriage return, Line feed) pair (probably a relic
of the old mechanical teletype machines which used one 'code' to
move the carriage to the left side of the paper and another 'code'
to advance the paper one line). In other operating systems, such as
Unix, linux, etc, a single byte with the (decimal) value of '10' is
used. Other 'codes' may be used by other systems. EVERY line in a
message (including otherwise 'perfectly' blank lines!) ends with an
'LES'.
[2] A computer produces a stream of binary bits, each of which can have
a decimal value of either '0' or '1'. These binary bits are gathered
together in bundles of eight bits, which are called 'bytes' (and
sometimes 'octets'), which then have associated numerical values in
the range of '0' to '255'. For instance the letter 'A' is normally
encoded as the binary stream, or byte, '01000001' which has a
'byte value' of '65' (decimal).
Often the bit positions in a byte are labeled, from right to left,
as bit-0, bit-1, bit-2, ... through bit-7. The labeling is
convenient because the number in the label indicates the value
which that particular bit position represents expressed as a power
of 2. for instance the bit-7 position represents 2 raised to the
power of 7, or 128 (decimal), which can be expressed as '2^7'. The
'0' or '1' bit value indicates the presence, if '1', or absence, if
'0', of that particular value in the total numberical value of the
byte.
So, to obtain the byte value (decimal) you simply add up the
included values. the byte representation of the letter "A", above,
includes the values '2^6' (decimal '64') and '2^0' (decimal '1' -
ANY number raised to the '0' power is '1') so the byte value
(decimal) is 64+1, which is equal to 65 (decimal).
Don't assume that the letter 'a' has that same byte value, though
- it doesn't. The uppercase letters 'A' through 'Z" have byte values
that are different from those for the lowercase letters 'a' through
'z'. While the letter 'A" is encoded as the bit stream (byte)
'01000001' with a byte value of '65' (decimal), The letter 'a', on
the other hand, is encoded as the bitstream (byte) '01100001' which
has a byte value of '97' (decimal).
There is a difference of '32' (decimal) between the values for
uppercase and lowercase letters (i,e., 'A' has a (decimal) value
of '65' while 'a' has a (decimal) value of '97' - 97-65=32; the
value for "B" is '66' while the value for 'b' is 98 - 98-66=32; and
so on...)
The difference 'boils down' to whether bit-5 is 'set" (equal to '1')
or 'unset' (equal to '0'). Since bit-5 has a decimal value of '32',
that value can be added or subtracted simply by 'setting' or
'unsetting' that particular bit. So, to change 'A' to 'a' simply
'set' bit-5 in the byte that represents 'A'; that byte now,
magically, represents 'a'. To reverse the process, simply 'unset'
bit-5 in the 'a' representation and it, magically, represents 'A'
again. This holds true for any uppercase/lowercase letter 'pair.'
- - --
*Jim McQueeney <[email protected]> ***
****** PGP ** RSA: 0x45A3FB5D *****
****** Keys * DH.: 0xA82248FD *****
- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1-nr1 (Windows 2000)
Comment: Please use PGP/GPG for your e-mail privacy
iD8DBQE/IKruEJJ5KUG29okRAuJ5AKDs36h6JJk9ieHfsxkk4+q7/UnHiQCgvf9B
8YkbRduM42wiyRaawY5AvaM=
=7tXU
- -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-nr1 (Windows XP) - GPGrelay v0.92
iD8DBQE/IOwUPmBJUiQaRN4RAgflAJ42HOyE9dzSVtH0QZQV572OUuAr4QCgsGDE
cu2VEKUgo/+hRAXRgXs8TAA=
=QEf2
-----END PGP SIGNATURE-----
------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Ink Cartridges & Refill Kits for Your Epson at Myinks.com
Free shipping on orders $50 or more to the US and Canada.
http://www.c1tracking.com/l.asp?cid=5705&lp=home/epson.asp
http://us.click.yahoo.com/brYXfA/_xWGAA/ySSFAA/MFQulB/TM
---------------------------------------------------------------------~->
----------------- COMMUNITY ADDRESSES -------------------------~->
Post message: [email protected]
Moderators: [email protected]
News: news://news.gmane.org/gmane.comp.security.pgp-n-gpg
Off-Topic List: PGP-n-GPG-Off-Topic-subscribe-hHKSG33TihhbjbujkaE4pw@public.gmane.org
Unsubscribe: [email protected]
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/