General Points

We use the word “discreet” to describe environments where secrets can be kept. Such environments are both for storing and for processing secret data. Sometimes we conclude that an environment is discreet because of the algorithms therein; other times because of the connections with the rest of the world. We shall be interested in both reasons here.
When secrecy of an environment depends on algorithms specific to that kind of environment we refer to “algorithmic discretion”. When the secrecy depends on the authority held within the environment we speak of “structural discretion”.
We believe that these environments are objects
{(p1,object-def)}.

Some objects are inherently not discreet.

It may be that the owner of some data is unwilling to sell access to that data except in such a way that he is informed of the details of each use of the data. Gnosis supports him in that desire, but his question answering service is not discreet {at least as far as Gnosis is concerned}.
In this section we introduce a method of providing such environments so that the algorithms that provide the processing and storage of the secret data need not themselves be trusted not to divulge the secrets. In line with other goals of Gnosis we do this in a way that protects the possibly proprietary nature of the processing algorithms from the owner of the data.

Let D and H be sets of keys and let I be a set of pages and nodes.

We say that a set of keys D is structurally discreet with respect to integral regime I, with holes H if there is a set of pages and nodes R such that:

the only keys to members of R are in D or in the nodes of I or in the nodes of R, and

all keys in D are sensory or designate things in R, and

no I/O keys are in the nodes of R and

If K is a key in a slot of a node in R then either:

K is sensory {(p2,sensory)} or

K is in H or

K designates a page or node and that page or node is either in the nodes of R or I or

K does not designate a page or node.

The important thing about structurally discreet objects is that logic in the algorithms of the integral regime can cause the discretion to persist as the system evolves without reference to the algorithms outside the regime (either in R or outside R). It is also necessary that the regime be “solid”.

The above definition has the strange result that after calling a key in D {presumably a start key} and before the return from that call, R is not discreet because it holds a resume key to the caller. If no other non-sensory keys were passed, we know the resume key is the only exception and that after the return R will again be structurally discreet. Perhaps we need {as a practical matter} to allow keys in R to objects known to the holder of D.

{The aforementioned Integral regime is that of the Security System or TCB or some such.}

It is useless to know that a regime is discreet unless the whereabouts of all slots holding members of D are also known.

Not all discreet objects are structurally discreet. Perhaps not all structurally discreet objects can be feasibly produced by factories.

As an example of the need of the integral regime in the above definition consider the following:

We wish to have a number of discreet regimes which is greater than the number of page ranges.

A bug in a space bank used by code in the regime could cause the space bank to create and disseminate page keys to pages within the discreet regime.

The space bank cannot be in the regime because there are not enough space banks with their own range keys to go around.

Summary
We describe here a general method of creating discreet objects without trusting the creator. We do, however, require that the creator follow a protocol. We also assume that the creator wishes to keep secret the details of the implementation of the object.

We believe that the kinds of objects that are clearly discreet on the basis of the keys that they hold, can be feasibly constructed by these means.

The net result of these ideas is that data abstraction does not require trusting the implementor of the abstraction with your secrets.

has an obsolete introduction to factory logic.

Abstractions within abstractions
Since data abstractions are implemented with ordinary programming techniques and such techniques (at least in Gnosis) involve the use of data abstractions we are faced of abstractions within abstractions.

The outer abstraction can not generally be considered discreet unless the inner one is. These techniques must therefore be recursive -- the proof of the discreetness of the outer abstraction includes the proof of the discreetness of the inner abstraction.

{obsolete}Aspects of the Factory
The object requestor’s view of the factory
The requestor calls a factory with a meter and space bank and an order code requesting a discreet object. {The factory may be newly created for this occasion or may be an old generally useful factory.} The requestor verifies that the factory is official {through FACTORYC} if he is suspicious.
The creator’s view of the factory
General Points
Some creators will be designed to create objects according to the factory protocol. Such objects are manifestly discreet. These are the protocols that such creators must follow.

The object will be created from components available or producible by the creator. The components most basic to the construction of objects are access to segments and start keys to domains.

Access to segments is made manifestly discreet by the sense key logic. This directly provides for access to segments via node trees.

Objects that are components of newly created discreet objects must themselves be newly created and manifestly discreet -- at least the rules below enforce this.

The creator is protected with this protocol in that the creator never works directly with components that can stall or disappear. The instructions that the creator provides will be executed using such objects but the creator is protected from flaky banks.
The creator calls FACTORYC to get a factory E.

The creator calls E passing a memory key C.

{This is to some code that will run with different privilege than the creator.}
The creator then calls EA up to sixteen times. Each of these calls uses either order code 1 or 2.
When order code 1 is used a data key or segmode key may be passed.

When order code 2 is used a factory is passed. This factory key has come from some creator {of a discreet sub-component}.

The creator then makes the requestor’s key available to the requestor or potential requestor’s at large.
Keys returned by the factory are structurally discreet {(p3,struct-disc)}.
Using the Factory to Build Manifestly Discreet Virtual Copies of Segments {See (p2,segfac) for example.}
The holder of a segment to be virtually copied, calls the segment. The segment keeper calls FACTORYC for a factory. The segment keeper then calls the factory passing a segment key to the segment keeper’s code and a sense key to the top node of the segment. The segment keeper then completes the factory and returns the requestor’s key to the segment key holder.

Upon a call by a requestor, the factory constructs a domain with a read-only no-call segment key to the keeper’s code as the memory tree root. This domain holds the sense key to the top node of the segment. Now segment keeper code runs in an environment acceptable to both keeper’s designer and segment holder.

An Easier Way?
Some justification for the factory is necessary for it may be pointed out that most creators may be installed in such a way as not to have access to outward signal paths in the first place {be structurally discreet}.

This is not possible however when the creation of the object is relative to some other objects that did not exist when the creator was created. An example is the creation of virtual copies of segments. The creator needs read access to the segment but must have nothing else.

Design Issues (leading to the current design)
In general X asks Y to produce a discreet object D. D will be produced in factory E by program C, provided by Y, from weakened components accessible to Y or components producible by actions that Y can take.

An issue here is whether the program C is allowed to call upon Y as it runs.

Program C may be complex and its requirements difficult to forsee. Presumably it has not been tainted by any of the secrets that it will be privy to and so these calls (mediated by E) could be allowed.

On the other hand program C has had access to the secret space banks and meter. Possible space bank rejects have occurred which might signal something. If you did allow C to call Y, Y would not know how long these calls would last and Y might need to be tending to other business and thus evolving.

An immediate case in point is the supernode:

We presume that each of the keys held by the supernode is to be weakened.

If the copy were to be done outside the supernode, the supernode holder would have to build a tree of nodes and pass a sense key into the factory. This is objectionable because it duplicates the factory tree logic, and causes the keys to be passed over twice to boot.

If we modify the logic of the supernode to produce a copy with a factory we may use the ideas of virtually copyable segments.

I currently think that C must have all of its materials in hand before it starts and not have the ability to call Y.
With this decision, Y must provide all of the capabilities that will be required by C. Y is responsible for getting these past the customs agent E1. Fortunately factories believe factories and the answer is at hand.

If C will need a subcomponent that is available only in the form of a start key S then S must be discreet to the satisfaction of the factory E1.

Y must get a new factory E2 and give E2A to to S. S will do its factory thing and return. E2B may now be sent to E1A and the first factory will recognize it as a factory and do the call on E2 and keep the yield for access by C.

Who trusts Whom about What
There are two security issues at stake here:
The requestor wants the use that he will make of the object to be kept secret;

The creator wants the implementation of the object not to be divulged.

They both trust the factory.

We notice that if the object is itself implemented with a start key to a sub-object, that that sub-object must be discreet as well and that the creator is here a requestor (for the creation of the sub-object) but that he must convince another party of the discreetness of the sub-object. That other party is the factory which the creator is priming.

Where does the program running in the factory get its domain creator creator?!!
Other design issues
Shall we support objects that are, for convenience, not normally discreet? If so how shall we handle the discretion of subcomponents?

Do we need repair key conventions for the factory?

Fitting the Factory Design to Current System Architecture
There can be no general method of making objects discreet. Some of them just aren’t discreet, but several of the creators and copiers will need to be upgraded to do their thing with factories.

In particular I suspect that the dcc is structurally discreet and can produce new manifestly discreet dcc’s. With some connivance from the factory logic the new dcc could be the same as the old.

If this efficiency were important, a particularly simple connivance would be for the dcc to hold a key to an official factory {according to FACTORYC} which always produced the same, one and only, dcc.
Space banks are not structurally discreet. {Thus it will be up to the logic of the space bank to be discreet.}
Factory Programming Notes
Some factories are created to be called once. In this case the requestor calls the creator who produces a {custom} factory for this particular case. In other situations the creator creates a factory in the beginning and that one factory is used for all objects of this type.

The 16 component limit:

If 16 components aren’t enough you can use more factories. The trick is to get subsidiary factories, install components in them and pass their requestor’s key to the primary factory.

The subsidiary factories have a standard program installed in them that merely coughs up the components on demand.

If sense keys are implemented, components that aren’t requestor keys can be placed in a common node and a sense key to that node may be placed in the factory.

Normally the first use of the requestor’s key follows the last use of the creator’s key. It might be possible to safely ignore this rule to install new releases of software.

If systems {objects} built in factories are to use general Gnosis programming techniques we must provide the functions of meters, space banks and domain creators.

Space Banks and Meters

Domains in discreet objects must designate meters and yet the prime meter cannot be in a discreet object. Meters superior to those in a discreet object must be in the integral regime (relative to which the regime is discreet) where we know that spies cannot see them. Analogous problems arise with space banks.
While one page or node is indistinguishable from another, one second of CPU time is distinct from another due to the STCK instruction.

The code of integral regimes must explicitly implement whatever degree of discreetness is required. There are several techniques to support discreetness and confidence in discreetness.

Running out of space

Some space banks are designed to over-allocate space and, as a result, may refuse to provide storage at un-expected times. Such refusals may be used for covert communication channels.

One answer here is not to provide such space-banks. An alternative is to dedicate some fixed set of pages and nodes at factory creation time and provide a space bank {in the factory} to hand these out as needed. This function is provided by current space banks {(p2,sbt1)}.

Such a space bank is still structurally discreet only relative to a regime with a senior space bank because a senior space bank holds range keys the this set of pages. Now, however, it suffices to know that that senior bank will not use those keys for those pages and nodes for the duration of the existence of the discreet object. This is a much easier thing to prove and believe.

Running out of time
One might pre allocate some specific future time slots as we allocated specific pages and nodes above. This would require the regimes to be ready when the time came. This might in turn require other timely services of the integral regime. This might be a can of worms -- who ever heard of saying when your program would finish?!

Perhaps optional factory logic could provide the place to stand to provide backup or archive. I think that the factory is in a position to talk with all of those concerned with the security issue.

We suspect that users on a particular Gnosis machine will tend to trust and use the same integral regime. This will be thought of as an extension of the kernel. We anticipate that space bank and scheduler code will be included.

The network communications could be handled in {at least} these three ways: {This can now be reworked with relative discretion.}

The Tymnet adaptor {(p2,tymnet)} is included in the regime and the security designed therein trusted {including receptionist, network supervisor, etc.}.

If a small fixed number of discreet regimes is required, each has its own TA, Tymnet base and Tymnet.

An enciphering facility exists in the integral regime which interfaces with TA which is not in the regime!