forked from cheng/wallet
142 lines
8.5 KiB
HTML
142 lines
8.5 KiB
HTML
|
<!DOCTYPE html>
|
||
|
|
<html lang="en">
|
||
|
|
<head>
|
||
|
|
<meta content="text/html; charset=ISO-8859-1" http-equiv="content-type">
|
||
|
|
<style>
|
||
|
|
body {
|
||
|
|
max-width: 30em;
|
||
|
|
margin-left: 2em;
|
||
|
|
}
|
||
|
|
p.center {
|
||
|
|
text-align:center;
|
||
|
|
}
|
||
|
|
</style>
|
||
|
|
<link rel="shortcut icon" href="../rho.ico">
|
||
|
|
<title>Implementation Steps</title>
|
||
|
|
</head>
|
||
|
|
<body>
|
||
|
|
<p><a href="./index.html"> To Home page</a> </p>
|
||
|
|
<h1>Implementation Steps</h1>
|
||
|
|
<p>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. <br/>
|
||
|
|
</p>
|
||
|
|
<p>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.<br/>
|
||
|
|
</p>
|
||
|
|
<p>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.</p>
|
||
|
|
<p>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.</p>
|
||
|
|
<p>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.<br/>
|
||
|
|
</p>
|
||
|
|
<ol>
|
||
|
|
<li>
|
||
|
|
<p>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.</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>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)<br/>
|
||
|
|
</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>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.</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>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.</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p> 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. </p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>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. </p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>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.</p></li></ol>
|
||
|
|
<p>Ports are an encrypted connection plus <a href=".%5Cprotocol_negotiation.html">protocol
|
||
|
|
agreement information</a>. 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.</p>
|
||
|
|
<p>A port references an encrypted connection, probabilistic information
|
||
|
|
about the current state of information exchange, and a protocol
|
||
|
|
description.</p>
|
||
|
|
<p>Thus, the very first protocol is a protocol to negotiate new ports
|
||
|
|
and thus new protocols, and to shut down this connection.</p>
|
||
|
|
<p>This could potentially create additional round trips, thus we have
|
||
|
|
have a general 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.</p>
|
||
|
|
<p>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.</p>
|
||
|
|
<p>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.</p>
|
||
|
|
<p>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.</p>
|
||
|
|
<p>Server ids contain a link to a list of protocols they accept, signed by an authority responsible for those protocols. Protocols are identified by stream of bytes, in which zero or bytes have their high bit set, the stream being terminated by a byte with the high bit cleared. Lists of protocols are maintained by the system responsible for the list of server ids, with new lists only being added by a human decision at the distinguished proposer.</p>
|
||
|
|
|
||
|
|
<p>These lists only identify protocols capable of setting up a connection. When a connection is made, the client offers a list of subprotocols that it wants, and the server accepts the first one in the list that it recognizes and wants to handle. We will have no central authority for such subprotocol lists. Anyone can roll there own, and in the event that there come to be a lot of them, the implementer just chooses an identifier long enough and random enough that the risk of collision is small.</p>
|
||
|
|
<p style="background-color : #ccffcc;
|
||
|
|
font-size:80%">These documents are licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative
|
||
|
|
Commons Attribution-Share Alike 3.0 License</a> </p>
|
||
|
|
<p style="background-color :
|
||
|
|
#ccffcc; font-size:80%"> And, in any case, are a proposal for software that can
|
||
|
|
be used to massively copy copyrighted material. </p>
|
||
|
|
</body>
|
||
|
|
</html>
|