[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
(fwd) A new PGP
For those of you who haven't already seen this -- my apologies for
the post if you already have....
Forwarded message:
> From: [email protected] (Peter Gutmann)
> Newsgroups: alt.security.pgp,sci.crypt,talk.politics.crypto
> Subject: A new PGP
> Followup-To: alt.security.pgp
> Date: 13 Sep 1994 16:01:08 GMT
> Organization: University of Auckland
> Lines: 263
> Sender: [email protected] (Peter Gutmann)
> Message-ID: <[email protected]>
> NNTP-Posting-Host: cs13.cs.aukuni.ac.nz
> X-Newsreader: NN version 6.5.0 #7 (NOV)
> Xref: news.sprintlink.net alt.security.pgp:18448 sci.crypt:31730 talk.politics.crypto:7169
>
>
>
> [NB: Followups redirected to alt.security.pgp]
>
> This posting is a call for participation in a complete rehash of PGP to
> parallel the existing PGP effort in the US. All contributions are welcome,
> although any cryptographic material from the US won't be usable by anyone else,
> so it'd be best if all crypto work was done outside the US. I believe Phil is
> aware of this project but can't comment on it due to legal advice - please
> don't pester him (or me) about this.
>
> The following sections are a preliminary sketch of what's to be done, see the
> end of this message for more information on how to participate.
>
> Design goals for the new PGP:
>
> - Proper key database for fast lookup of keys.
> - Something like DER-encoded ASN.1 keys and data, PKCS/X.509 compatible with
> extensions for PGP's trust model and also i18n features not found in X.509
> (exact details still under debate).
> - Ability to plug in alternative routines, eg RSAREF instead of independant
> RSA code.
> - Backwards compatibility with 2.x.
> - MIME security extension compliant encoding of messages.
> - Flexible, planned message/key format which allows easy expandability.
>
> The universal PGP rewrite emphasizes flexibility of design, modularity and
> Chinese-wall seperation for ease of development, and abstraction of messy
> details like low-level I/O. Some rules to go by:
>
> - All functional units are kept in seperate modules. There is one header file
> giving the interface to that module. Only the interface given in the header
> file is available to the outside world. All non-public information should be
> in header files which are private to that module. This should vastly simplfy
> development by multiple people since all the content-coupling of the existing
> code is eliminated.
>
> The whole of PGP is too big for one person to get an overview of, by
> enforcing modularity with a preset interface we can allow independant teams
> to work on the parts they're best at, as well as allow independant developers
> to user the libraries they want in PGP support software without having to
> worry about all the API's breaking every time there's a new release.
>
> - None of the library routines perform any user I/O. This is all handled by
> higher-level code, using callbacks if really necessary. The libraries should
> be usable in any CLI or GUI environment without needing changes made for
> different operating environments.
>
> - All routines return an integer status with well-defined codes. Status values
> are defined in the module interface header and are of the form <3-char module
> name>ERR_<error type>, eg DBXERR_READ would indicate a read error in the
> database access code. No mysterious constants buried seven nesting levesl
> down in routines somewhere!
>
> The basic modules are:
>
>
> Streams
> -------
>
> A generalized stream I/O library. A stream can be a block of memory, a FILE *,
> a file-descriptor-based file, a TCP socket, an X.25 virtual circuit, or
> whatever. The use of memory streams does away with PGP2's overuse of temporary
> files.
>
> int newStream( STREAM *stream );
> int attachStream( STREAM *stream, ??? );
> int ioctlStream( STREAM *stream, ??? );
> int readStream( STREAM *stream, void *buffer, size_t length );
> int writeStream( STREAM *stream, void *buffer, size_t length );
> int lengthStream( STREAM *stream );
> int deleteStream( STREAM *stream );
>
> The attachStream() and ioctlStream() attach a stream to an interface, eg a
> block of memory, a file, or a network connection, and change its
> characteristics. The end user is never aware of any difference, or of the fact
> that, for example, for a small message they might be R/W memory, but for a
> larger one they might be R/W a temporary file. Perhaps an existing PD streams
> library can be adapted to the task.
>
> Error codes: STMERR_xxx
>
>
> PKC
> ---
>
> A PKC library.
>
> int rsaEncrypt( PUBKEY *pubKey, STREAM *stream );
> int rsaDecrypt( PRIVKEY *privKey, STREAM *stream );
> int rsaKeyGen( ??? );
>
> Error codes: PKCERR_xxx
>
>
> Crypto
> ------
>
> A conventional-key crypto library.
>
> int encrypt( CRYPTINFO *cryptInfo, STREAM *stream );
> int decrypt( CRYPTINFO *cryptInfo, STREAM *stream );
>
> The CRYPTINFO struct contains all the information you need to specify
> encryption algorithms and modes, so you'd have something like:
>
> cryptInfo->algorithm = CRYPT_ALGO_IDEA;
> cryptInfo->mode = CRYPT_MODE_CFB;
> encrypt( cryptInfo, stream );
>
> This fixes another complaint with PGP, that for every job you do there are 15
> different functions to do it, all with slightly different parameters and
> options. With the unified interface, the call to encrypt data is *always*
> called encrypt() (rather than encryptIdeaCfb(), encryptFooBar(),
> encryptThisThatAndTheOther(), etc), and the CRYPT_INFO struct contains all the
> parameters you need. A library could then implement a number of different
> algorithms and you choose which one you want without having to know that the
> function name for that option is encryptQwertyFoo(). You could even have a
> getCryptInfo() call which queries a library as to which algorithms and modes it
> implements, or the call could return CRYERR_ALGO_UNAVAIL (algorithm
> unavailable) or CRYERR_MODE_UNAVAIL (encryption mode unavailable).
>
> Error codes: CRYERR_xxx
>
>
> Configuration
> -------------
>
> Get configuration information for PGP routines. Use a proper grammar
> definition, perhaps lex+yacc (tcl has also been suggested), read into (private)
> vars, make available to outside world via getXXX() calls. NO GLOBAL CONFIG
> VARS!
>
> int readConfigFiles( void );
> int getFooInfo( char *fooPtr );
> int getBarInfo( int *barPtr );
>
> Error codes: CFGERR_xxx
>
>
> Random Number Handling
> ----------------------
>
> A random number management library.
>
> int openRandomStream( STREAM *stream );
> int readRandomStream( STREAM *stream, void *buffer, size_t count );
> int closeRandomStream( STREAM *stream );
>
> This could use the existing keystroke latency method, or connect the stream to
> custom hardware, or whatever.
>
> Error codes: RNDERR_xxx
>
>
> Key Database Management
> -----------------------
>
> All keys can (and should be) stored in a database, which encapsulate the full
> DER-encoded keys inside a database allowing fast lookup. The general format
> will be:
>
> { keyID, userID, encapsulated key }
>
> The keyID is a hash of the key (making it independant of the key itself and not
> prone to denial-of-service attacks), the userID is simply the user
> ID/address/whatever, the encapsulated key contains the full key. Lookup is
> done on the keyID and userID which locate the required key. Details of the
> exact mechanism to be decided by the database experts - need to define message
> format, kludges like storage of encapsulated keys in XMS for peecee's, etc etc.
>
>
> En/decoding
> -----------
>
> ASN.1 DER-encoding of keys/data, MIME en/decoding. Needs to be discussed.
>
>
> Compatibility
> -------------
>
> Backwards-compatibility code to handle old PGP keys and messages. Presumably
> keys will only need to be converted once, then we need to read old messages and
> (possibly) write them.
>
>
> Low-Level
> ---------
>
> Low-level OS interface code. All OS-specific code is hidden in this module.
>
>
> I18n
> ----
>
> A proper i18n system which reads the appropriate messages from a database once
> and then keeps them in memory.
>
> int readInternationalizationDatabase( void );
>
> All user I/O then uses strings from the i18n database. The database is
> generated by a precompiler from some user-friendly input format, so that a
> group of seperate language scripts for eg English, French, German, Russian, etc
> are fed into one and, and the output is the full i18n database. Adding a new
> language to PGP then involves simply creating a new script in that language and
> running the database compiler on it.
>
>
> Installation
> ------------
>
> Not part of PGP, but we need someone to do a decent install script which
> removes from end users the need to fiddle makefiles and options.
>
>
> Others
> ------
>
> Other routines as required. For example, we each library should have an init
> call which registers an exit handler with a function called by atexit() to
> allow a clean shutdown no matter how we exit the program. This does away with
> the current need for PGP to explicitly perform exit handling all over the
> place, and hides the messy details from the end user (who may not even think
> about things like this).
>
>
> What we need:
>
> - A well-connected site outside the US to run mailing lists, one per developers
> group:
>
> pgp-streams - streams interface for I/O
> pgp-crypto - public and private-key encryption, random number management
> pgp-dbx - key database management
> pgp-compat - PGP 2.x backwards-compatibility management
> pgp-protocol - PGP data/key format and protocol redesign
> pgp-lowlevel - low-level OS-specific glue code
> pgp-misc - everything else, eg config code, i18n, installation
>
> There may also be a need for a seperate group to handle key-related routines
> such as trust-level checks and whatnot, which is a fairly complex task. The
> idea is to mimimze the amount of unnecessary traffic people will need to read
> in order to get their job done.
>
> The only communication which should be necessary between these groups is the
> header file which defines the data structures and interface and/or a written
> specification of the interface to a module. This means that the PKC group
> can work on the PKC code without having to worry about what the streams,
> database, crypto, and os-specific groups are doing.
>
> An attached FTP site for distribution of code would also be nice.
>
> - Groups of developers with expertise in PKC crypto, conventional crypto,
> database management, low-level OS-specific stuff, code optimization, protocol
> design, software i18n, and everything else imaginable.
>
> Until the mailing lists are set up (someone volunteer a site, quickly!) I'll be
> handling things in email, which means that it could take quite a while for me
> to extract myself from the flood of messages I'm expecting. Please try and
> keep non-essential messages to a minimum, and be patient when waiting for
> replies.
>
> Peter (Hmm, maybe I'd better mount /usr/spool/mail on a seperate drive).
>
- paul