CDR: PACKRAT development plan: Comments?

[Ray Dillinger]

Okay, it's a long message.  I've been thinking 
about/working on this, in my spare moments, and 
I think I have a viable project here.  

I'd like to ask people to look this over and 
help me fill in the important bits I've doubtless 
missed.  

Also, general feedback would be appreciated -- 
Is it useful?  Is it needed?  can any of these 
functions be safely "offloaded" to other 
software?

		Ray




         PACKRAT Development Plan 

 (Protocol Advisor and Cryptographic Key Retention
  and Administration Tool - 'Cause I'll go a mile 
  for a good acronym. :-P )

When completed, PACKRAT should provide a
framework within which "Drop-in" modules will be
able to work together to perform various tasks
security. 

The first kind of Drop-ins are Crypto Modules,
which provide encryption and decryption services,
(or hash functions or signatures), key generation,
and a huge wealth of information about the
characteristics of the keys and ciphertexts and the
efficacy of various cryptanalytic attacks on the
ciphers. 

A second kind of Drop-In is a pseudorandom
number generator or random number generator.
Aside from supplying random or pseudo-random
bits, These modules are expected to supply a wealth
of information about the characteristics of the
streams they generate and the efficacy of the best
known cryptanalytic attacks. 

Another kind of Drop-In is a Cryptanalytic Module,
which automates as far as possible a cryptanalytic
attack against ciphers produced by particular
Programs (including Crypto Modules, RNG's, and
PRNG's). This is needed to keep the designers of
Crypto Modules honest, but strictly speaking, these
are optional to the operation of PACKRAT. 

A fourth kind of Drop-In is a Protocol Script. A
Protocol Script specifies the steps involved in
carrying out some protocol -- it will call for ciphers
and/or (P)RNG's having particular characteristics,
which PACKRAT will then select from among the
crypto modules on the basis of information
provided by the crypto modules and also on the
basis of information about the other participants in
the protocol. 

PACKRAT sits on all these drop-ins, keeping a
database of the ciphers, RNG's, PRNG's, keys,
messages, identities, nyms, and cryptanalytic
capabilities available to it. Each drop-in must be
digitally signed, and PACKRAT will check these
signatures. It will also keep addendums to its list of
keys, correlated with notes about what each key has
been used for. The user ought to be able to see a list
of what information would be compromised by the
loss of any particular key. 

This necessitates a Logging function and assures that
the application must allow logfiles to be kept. These
logfiles must of course be encrypted if they exist,
and people must be able to erase them, select what
level of logging (and therefore correlation/ 
introspection/ compromise reporting services) they 
want. Also, PACKRAT must support a "log management"
function that ages logged records, deleting old
information according to the user's policy. 

The author of any PACKRAT Plug-In may issue a
decertification/insecurity notice, digitally signed.
PACKRAT, on recieving such a notice, will check
the signature and if it matches, warn the user about
the changed security estimates on past protocols
(producing logs of possible compromises with
appropriate references to old logfiles and drawing
the user's attention to them). It will also check the
security of protocols now in progress, halting such
protocols if the revised security level is unacceptable
to the user. 

Decertification notices against particular plugins
may also be issued by other parties, but then it
becomes a trust issue. Since it would be easy to
mount a denial-of-service by issuing decertification
notices against secure modules, such decertification
notices must be backed up by cryptanalytic
Drop-Ins. PACKRAT will initially respond
according to its trust models for the issuer of the
Decertification and the issuer of the affected module
-- but if such test is feasible, it will test the
cryptanalysis module to see if the Decertification
should be believed. If the allegations in the
Decertification turn out to be true, then the trust
model of both the Decertification issuer and the
Module issuer will be modified accordingly. 

PACKRAT will operate, to the extent that its user
allows it, operate partly on its own recognizance. It
will for example cooperate with other PACKRATs
to set up cryptanalytic tests against various ciphers
based on its trust models, or to achieve secure and
anonymous distribution of keys, decertifications,
etc. It will send dummy messages as fodder for
cryptanalytic tests, make choices of ciphers for
protocols based on their advertised and tested
characteristics, and proof itself against traffic
analysis by selecting its communications partners
and times of transmission randomly, while
opportunistically sending or forwarding messages
whenever the randomly chosen connections permit. 


 Version 
        Features 
 0.01 
        Key Retention, Listing, and Expiry
        functions 
 0.02 
        Key decertification by user 
 0.03 
        Ability to Attach Notes to keys. 
 0.04 
        Transaction Logging (with selectable
        logging levels) 
 0.05 
        Identity and Pseudonym Database
        integrated into key database. 
 0.06 
        Explicit Trust and untrust levels set by
        user may be applied to ID, Nym, & Key
        data 
 0.07 
        Configurable trust model integrated into
        Identity/Nym/Key database. (entails
        degree of trust in keys, identities, nyms
        being reduced/enhanced by trust model) 
 0.08 
        Crypto Modules recognized and queried. 
 0.09 
        Crypto Capabilities database built and
        referred to. 
 0.10 
        Whatever outstanding need seems most
        sorely lacking at this time. 
 0.11 
        Crypto Module
        certification/decertification by user. 
 0.12 
        Crypto Modules made subject to trust
        model established by user for their
        authors. 
 0.13 
        Encrypt/Decrypt primitives available for
        protocols. (includes signatures & hashes)
        "Encrypted filesystem" built into
        PACKRAT database. 
 0.14 
        PACKRATD constructed, a server that
        handles communications on a particular
        port. 
 0.15 
        PACKRAT learns how to register itself
        with PACKRATD, so that PACKRATD
        can tell other PACKRATs where to find
        it. 
 0.16 
        PACKRATD learns how to respond
        (encrypted) with the appropriate
        address/port number when given an
        (encrypted) query as to what port a
        particular PACKRAT is running on. 
 0.17 
        PACKRAT learns how to use
        PACKRATD to find what address/port a
        particular PACKRAT is running on
        (hence where communications can be
        directed). 
 0.18 
        Basic Commo infrastructure completed.
        (Transmit/Recieve primitives available to
        Protocols via direct port-to-port after a
        PACKRATD lookup) 
 0.19 
        Protocol Modules recognized and
        queried. 
 0.20 
        Whatever outstanding needs seem most
        sorely lacking at this time. 
 0.21 
        Protocol Capabilities database built and
        referred to. 
 0.22 
        Protocol certification and decertification
        by user. 
 0.23 
        Protocols made subject to trust model. 
 0.24 
        UI for selecting and using Protocols. (at
        this point protocols will have to name the
        exact crypto modules they need) 
 0.25 
        UI for selecting Encrypt/Decrypt modules
        for use with protocols that do not specify
        them. 
 0.26 
        Protocol Scripts enabled to select Crypto
        Modules on the basis of advertised
        characteristics. 
 0.27 
        Logfiles, and Databases of keys, identies
        and nyms, encrypted if a suitable crypto
        module exists. THIS IS THE FIRST
        USEFUL VERSION. 
 0.28 
        Secure Erasure primitive available to
        protocols. 
 0.29 
        Logfiles, and Databases of keys, identies
        and nyms, are secure-erased and
        re-encrypted automatically if key or
        encryption module is decertified. 
 0.30 
        Fix whatever seems to need it worst,
        release first publicly available version. 
 0.31 
        PACKRATD learns to store and forward
        and take messages, making a new commo
        protocol available for PACKRATs;
        Asynchronous Transmit. 
 0.32 
        Protocols able to specify in Transmit
        actions whether Asynchronous Transmit
        is good enough for their purposes.
        Answer may change depending on time
        constraints. 
 0.33 
        Introduce User-Defined Primitives (by
        "subprotocols" that indicate which
        primitive they perform). 
 0.34 
        Protocols able to select subprotocols to
        perfom on the basis of advertised
        characteristics of those subprotocols. 
 0.35 
        Decertification/Expiry of all plugins and
        keys issuable and honored on signature
        verification. 
 0.36 
        Cryptanalytic Modules recognized and
        queried 
 0.37 
        Database of Cryptanalytic capabilities
        built 
 0.38 
        UI for selecting cryptanalyses to test
        against logged messages. 
 0.39 
        Decertifications based on cryptanalytic
        modules issuable and honored. 
 0.40 
        Fix whatever seems most broken at this
        time and package the second publicly
        available release. 
 0.41 
        Automatic testing of cryptanalyses based
        on trust model, stakes, and feasibility. 
 0.42 
        Plug-Ins with "Designated Decertifiers"
        issuable. Trust model updated. 
 0.43 
        Decertifications issued by "Designated
        Decertifiers" selected by author issuable
        and honored. 
 0.44 
        PACKRATD learns to ask PACKRAT for
        decertifications. 
 0.45 
        PACKRAT learns to answer PACKRATD
        about decertifications. 
 0.46 
        PACKRATD learns to maintain a
        decertification database. 
 0.47 
        PACKRATD learns to propagate
        decertifications like news articles. 
 0.48 
        PACKRAT Learns how to ask
        PACKRATD for decertifications 
 0.49 
        PACKRATD Learns how to respond to
        PACKRATD about decertifications. 
 0.50 
        PACKRAT Learns how to update
        decertification database (subject to trust
        model) from PACKRATD. 
 0.51 
        Fix whatever seems to be most pressing
        need at this time - make publicly available
        version. 
 0.52 
        PACKRATD learns how to cooperate in
        cryptanalyses to make distributed tests of
        crypto modules 
 0.53 
        PACKRAT learns to exchange keys
        against need 
 0.54 
        PACKRATD learns to exchange keys
        against need 
 0.55 
        PACKRAT and PACKRATD are
        configurably hardened against traffic
        analysis. There is a tradeoff in efficiency
        and wasted bandwidth. 
 0.56 
        Trust model and Key/Nym DB updated to
        allow PACKRAT to identify nodes which
        help or hinder hardening against traffic
        analysis. 
 0.57 
        PACKRAT introduced to SENDMAIL.
        "send email" primitive available to
        protocols. 
 0.58 
        PROCMAIL introduced to PACKRAT.
        "Receive email" primitive available to
        protocols with proper .procmailrc. 
 0.59 
        Trust database updated to include mail
        servers. 
 0.60 
        fix whatever outstanding needs seem
        worst at this time. Make another publicly
        available version.