--- pgp/doc/pgformat.doc	2018/04/24 16:39:43	1.1.1.1
+++ pgp/doc/pgformat.doc	2018/04/24 16:40:35	1.1.1.2
@@ -1,11 +1,15 @@
-Internal Data Structures Used by PGP 2.2 (3 Mar 93)
+Internal Data Structures Used by PGP 2.3 (14 Jun 93)
 ==========================================================
 
-This appendix describes the data structures used internally by Pretty
+This appendix describes the file formats used externally by Pretty
 Good Privacy (PGP), the RSA public key cryptography application.  The
-intended audience mainly includes software engineers trying to port
-PGP to other hardware environments or trying to implement other PGP-
-compatible cryptography products.
+intended audience includes software engineers trying to port PGP to
+other hardware environments or trying to implement other PGP-
+compatible cryptography products, or anyone else who is curious.
+
+[To be included: a description of ASCII armor.  And ASCII armored
+file is just like a binary file described here, but with an extra
+layer of encoding added, framing lines, and a checksum at the end.]
 
 
 Byte Order
@@ -155,14 +159,14 @@ packet that contains the message digest.
 The validity period field is generally only used for certifying keys. 
 It should be set to 0 otherwise, for regular message signatures.  It
 may be useful for PEM-like capabilities in future versions of PGP. 
-PGP 2.0 will always just set it to 0, and will ignore it.
+PGP 2.3 will always just set it to 0, and will ignore it.
 
 There is a length field that specifies how many bytes of material is
 implicitly included in the MD calculation.  If this length field is
 5, it means the following 1-byte classification field and the 4-byte
 timestamp are included in the signature packet.  If the length byte
 is 7, it means the 2-byte validity period is also included.  In PGP
-2.0, we are using a length field of 5 for the material to be included
+2.3, we are using a length field of 5 for the material to be included
 in the MD calculation, so the validity period is unused and
 unincluded, and is assumed to be zeroed.  This makes the whole
 signature certificate shorter.
@@ -298,8 +302,8 @@ It is the following 18 byte long hex val
 Enough bytes of FF padding are added to make the length of this
 whole string equal to the number of bytes in the modulus.
 
-All this mainly affects the preblock() and postunblock() functions in
-mpiio.c.
+All this mainly affects the rsa_private_encrypt() and rsa_public_decrypt()
+functions in rsaglue.c.
 
 There is no checksum included.  We do include a copy of 2 bytes of the
 MD in the outer packet to help determine if we used the correct RSA
@@ -346,8 +350,9 @@ in the calculation.  In the above MSB-fi
 checksum is also stored MSB-first.  The checksum is there to help us
 determine if we used the right RSA secret key for decryption.
 
-All this mainly affects the preblock() and postunblock() functions in
-mpiio.c.
+
+All this mainly affects the rsa_public_encrypt() and rsa_private_decrypt()
+functions in rsaglue.c.
 
 
 
@@ -377,8 +382,8 @@ by the 2-byte "key-check" prefix.
 
 The key-check prefix is composed of two identical copies of the last
 2 random bytes in the random prefix, in the same order.  During
-decryption, the 9th and 10th byte of decrypted plaintext are checked
-to see if they match the 7th and 8th byte respectively.  If these
+decryption, the 9th and 10th bytes of decrypted plaintext are checked
+to see if they match the 7th and 8th bytes, respectively.  If these
 key-check bytes meet this criterion, then the conventional key is
 assumed to be correct.  
 
@@ -649,7 +654,7 @@ The trust of a key owner (OWNERTRUST) do
 estimation of their personal integrity, it also reflects how competent
 we think they are at understanding key management and using good
 judgement in signing keys.  The OWNERTRUST bits are not computed from
-anything-- it requires asking the user for his opinion.  
+anything -- it requires asking the user for his opinion.  
 
 To define the OWNERTRUST bits for a key owner, ask:
     Would you always trust "Oliver North" 
@@ -781,5 +786,3 @@ Here is an example of an ordered collect
           Signature certificate to bind preceding User ID and key pkt
           Keyring trust packet for preceding signature certificate
 --------------------------------------------------------------------
-
-