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.
