1993-04-12 - Trusting PGP

Header Data

From: norm@netcom.com (Norman Hardy)
To: cypherpunks@toad.com
Message Hash: 7cac49f750fe2753323a772b87eb2fe090da0ce488492da39af0d982be5d15ec
Message ID: <9304120442.AA28271@netcom2.netcom.com>
Reply To: N/A
UTC Datetime: 1993-04-12 17:54:32 UTC
Raw Date: Mon, 12 Apr 93 10:54:32 PDT

Raw message

From: norm@netcom.com (Norman Hardy)
Date: Mon, 12 Apr 93 10:54:32 PDT
To: cypherpunks@toad.com
Subject: Trusting PGP
Message-ID: <9304120442.AA28271@netcom2.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


   At last I have read the operating instructions for PGP 2.2. I am impressed. 
I raised the issue of trusting PGP. John Draper correctly suggested that 
it was possible to trust PGP because the code was available for inspection.   
I agree that this places PGP far ahead of various competition regarding trust. 
I propose, however, that if there were a single specification that 
covered various file formats and perhaps program logic, that PGP would 
eventually gain substantially more trust. Here is why.
 
As it is now, someone who reads the code to establish his trust in PGP must be 
familiar with C, in which PGP is written, number theory and various crypto 
threats and weaknesses. There are certainly such people. If, however, there 
were one operating specification then many more people would be attracted to 
the effort, ultimately yielding greater trust in PGP. Cryptographers without 
the skill or tenacity to read the code could contribute, as could programmers 
without the crypto theory. Each class would consult the specs, the programmers 
to verify that the code implemented the specs and the cryptographers to ponder 
whether programs with such specs were appropriate for their market.
 
Such specifications are required for government rated secure software for just 
this reason.





Thread