To Home page

Implementation Steps

Network addresses shall be opaque blobs, which may in practice consist of an IP4 address plus some variable precision additional subnetwork address, or may consist of an IP6 address  some variable precision additional subnetwork address, or some unknown future implementation for some non standard network.. Only the lowest level software knows or cares. To everything above, a network address is an opaque blog of unknown length and unknown internal format, which is by default non human readable and non human writeable, though some subtypes may be human readable and writeable. 

There is a member function which may yield a derived class that is human readable and writeable, but likely yields the null pointer.  The additional subnetwork information is used to handle the now common case that there are many entities on a single machine.

Which is to say, network addresses are implemented as a set of classes whose internal details are as far as possible hidden, derived from an interface base class, and all other software calls the methods of the interface base class.

Similarly for public keys, and indeed everything else.  Exposing the internal structure of network addresses and port numbers and so on and so forth to everything was a huge mistake.

The base classes of these heterogenous objects with common behaviors are of course, abstract classes.  Our networking system shall be built on top of abstract classes, unlike the existing system where class internals are exposed.

  1. Given a network address, a member of our opaque classes, be able to send unreliable messages in the clear.  UDP equivalent, but as yet no TCP equivalent.  At this point, we make absolutely no attempt to deal with NAT barriers.

  2. Client knows server public key and server network address.  Client and server construct strong shared secret despite the possible presence of an active man in the middle adversary.  To deal with replay attacks, establish shared global time and shared probabilistic offset from that time. (Server and client agree to disagree on global time, but know how big a disagreement they have.  Everyone tries to have their shared global cryptographic time to be the median offset)

  3. Client knows server network address and server public key.  Client and server know username and weak password or hash thereof.  Client and server construct strong shared secret despite the possible presence of an active man in the middle adversary.

  4. Client knows server network address but does not know server public key, or anything that would allow it to reliably identify the server public key.  Client and server know username and weak password or hash thereof. Client and server construct strong shared secret despite the possible presence of an active man in the middle adversary.

  5. Code to determine whether a public key and its authenticating rule matches a hash for that authenticating rule.

  6. Client knows hash of rule identifying server public key, and server network address.  Client learns server public key from server, then proceeds with steps 1 or 2.

  7. Unite all the above code as derived from a single abstract base class, which caches the connection between client and server, regenerates a shared secret as needed. 

  8. We define the class “connection”.  A connection is a member of a class containing shared secret and network address information.  We have not yet, however, got to a concept replacing port number, or even got anywhere near being able to build user interface. We have however, placed what we need for encryption where it belongs, at close to the most foundational level.  Encryption first, port number equivalent and TCP equivalent on top of encryption.  Then we get to UI later, and then we will get to how to know these public keys, or hashes of rules identifying public keys.

  9. The encrypted connection, and, finally ports. The encrypted connection is a connection with encryption information. Packets arrive with position information as to the order in which they were sent, though not all packets arrive, and not in original order and some are garbled. Packets are authenticated then decrypted and assigned to their appropriate port, so when they get to the port they are authentic, correct, and have known positions within the port stream and connection stream, though not all make it to the port, and not in order.

    Ports are an encrypted connection plus protocol agreement information. For every connection, there are usually two ports, one to manage the creation and destruction of ports and the connection, and at least one to actually transport useful information.

    A port references an encrypted connection, probabilistic information about the current state of information exchange, and a protocol description.

    Thus, the very first protocol is a protocol to negotiate new ports and thus new protocols, and to shut down this connection.

    This could potentially create additional round trips, thus we have have a generall rule for collapsing round trips, "Assuming you agree to the proposed protocol, here is first packet of that protocol." If server does not agree, then client adjusts its assumptions about server state.

  10. Each side transmits on its best guess about the state of the other, but can back up to an earlier point in the state machine if such provisional transmissions are revealed to be in error.

    In the present tcp implementation, the client is a state machine, and the server is a state machine, and they try to tend to corresponding states. Thus the client state embodies knowledge about the server state. I suggest that instead the client maintains a list of possible server states, and as events happen, updates the weightings of each guess as to server state.

    The client also needs to model server guesses about client state, and the server needs to model client guesses about client state, an estimate about an estimate.

    Client and server negotiate an agreed protocol description by agreeing on a signature (hash of a rule identifying a public key) for the authority that signs lists of protocols, or lists of lists of protocols. That signature authority has Dewey decimal protocol identifier that is unique for that signature authority, though client and server may, and usually do, have differ as to what is the most recent version of that authority's lists.

    There shall be in the initial release at least two signature authorities, with the intent that if the system be widely adopted there will be enormously many signature authorities. Agreement is probabilistic, with provision for discovering mistakes in premature assumed agreement. Client and or server give part of the hash, and assume the rest, but build their assumptions into checksums. If checksum failure, restart.

  11. **

  12. **

  13. **

  14. **

  15. **

  16. **

  17. **

  18. **

  19. **

  20. **

  21. **

  22. **

  23. **

  24. **

  25. **

  26. **

  27. **

  28. **

  29. **

  30. **

  31. **

  32. **

  33. **

  34. **

  35. **

  36. **

  37. **

  38. **

*****

*****

 

These documents are licensed under the Creative Commons Attribution-Share Alike 3.0 License

And, in any case, are a proposal for software that can be used to massively copy copyrighted material.