From:
p2p-hackers@zgp.org (Brad Neuberg)
Date:
Mon Jul 1 16:21:02 2002
Subject:
[p2p-hackers] Distributed Timestamping Service
--------------030106050903060307010605
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Lucas Gonze wrote:
>>>>To make things easier, I don't really need the real time. All I need is a
>>>>timeline of discrete events, one following the other, rather than the real
>>>>time. For example, each "time click" could be a hash, and the next time-click
>>>>would fold the previous hash into itself, and so on. So instead of having a
>>>>service that says 1:00 PM, then 2:00 PM, etc., it simply says Time Click A,
>>>>Time Click B, Time Click C, etc.
>>>>
>>>>
>
>...fun stuff... some thoughts on it while I'm taking a coffee break:
>
>This seems doable as a directed graph with edges from signed data to data
>which it it is used to sign.
>
>When a node signs data for some other node, it certifies that the signed
>data was present by that time. But what about the key being signed with?
>It might have been created at any point. So, the key should have been
>signed at some previous time by a third node.
>
>
Interesting idea. I'm still trying to "grok" it. I should have brought
up that this distributed timing service is living above a very
unreliable network; i.e. nodes pop into and out of existence quite often
(probably on the range that every hour over half the nodes are replaced).
In a sense it sounds like your idea is to create very long certificate
chains. As time "clicks" on and the directed graph of nodes signing
nodes grows, won't it get longer and longer to "authenticate" that time,
or do I have a misunderstanding?
>This establishes sequential information between the signed data
>and the signing key. It says that the key existed first.
>
>There is no need to have just one signer. The opposite -- you want
>a lot of signers and a lot of signatures so that you can establish a
>sequence as a directed graph.
>
>The sequence does break. It's not perfect at all. Signing chains can't
>be traced back infinitely. A signer is not available to affirm that the
>sequence is correct. There will be parallel sequences of signing
>chains where there aren't crosslinks available to help you interleave
>events.
>
>Constantly establishing keys doesn't make sense. The algorithm works
>just as well if there is a third bit of data, a use-once token. Can that
>work? Don't know.
>
>
What do you mean?
>Like anything else this half assed, somebody must have already written
>this idea up better with actual discipline!
>
>
You'd be surprised; this looks like virgin territory. There has been
_very_ little work on distributed timing services, unless someone made
breakthroughs in a parallel field and didn't realize that it could be
applied to this problem. I think the problem is worth solving. Once
you have a crytographicly secure distributed time service you can use it
to create first come, first served bindings between pieces of data, such
as username to public key, or web site name to IP address. Binding
username to public key and stamping it with the time would let you
create a first come, first served distributed PKI service, while binding
web site name to IP address would let you create a first come, first
served distributed naming service.
As a solution to this problem, I'm wondering how our bodies establish a
sort of time or cycles that are used somehow. I think there might be
some interesting biological/chemical solutions to this problem that can
be used as inspiration, similar to the famous Bray-Liebhafsky reaction
that exhibited chemical oscillations. In the BL reaction, certain
chemicals are placed in a dish. After a brief period of inactivity, the
dish begins to oscillate from red to blue and back again in a cyclic,
clock-like pattern. The BL experiment has been called important because
it is a simple chemical reaction that might help us understand how
biological time-like oscillations happen. A biological time-keeping
service, so to speak, would have to solve many of the problems in the
peer-to-peer example: decentralized, no central trust, nodes fall in and
out (cell birth and death), and resistance to hijacking by cancerous
cells or viruses.
Thanks,
Brad Neuberg
codinginparadise.org
>- Lucas
>
>
>_______________________________________________
>p2p-hackers mailing list
>p2p-hackers@zgp.org
>http://zgp.org/mailman/listinfo/p2p-hackers
>
>
>
--------------030106050903060307010605
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
</head>
<body>
Lucas Gonze wrote:<br>
<blockquote type="cite"
cite="midPine.LNX.4.44.0206270910160.9060-100000@localhost.localdomain">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">To make things easier, I don't really need the real time. All I need is a
timeline of discrete events, one following the other, rather than the real
time. For example, each "time click" could be a hash, and the next time-click
would fold the previous hash into itself, and so on. So instead of having a
service that says 1:00 PM, then 2:00 PM, etc., it simply says Time Click A,
Time Click B, Time Click C, etc.
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap=""><!---->
...fun stuff... some thoughts on it while I'm taking a coffee break:
This seems doable as a directed graph with edges from signed data to data
which it it is used to sign.
When a node signs data for some other node, it certifies that the signed
data was present by that time. But what about the key being signed with?
It might have been created at any point. So, the key should have been
signed at some previous time by a third node.
</pre>
</blockquote>
Interesting idea. I'm still trying to "grok" it. I should have brought
up that this distributed timing service is living above a very unreliable
network; i.e. nodes pop into and out of existence quite often (probably on
the range that every hour over half the nodes are replaced).<br>
<br>
In a sense it sounds like your idea is to create very long certificate chains.
As time "clicks" on and the directed graph of nodes signing nodes grows,
won't it get longer and longer to "authenticate" that time, or do I have
a misunderstanding?<br>
<br>
<blockquote type="cite"
cite="midPine.LNX.4.44.0206270910160.9060-100000@localhost.localdomain">
<pre wrap="">
This establishes sequential information between the signed data
and the signing key. It says that the key existed first.
There is no need to have just one signer. The opposite -- you want
a lot of signers and a lot of signatures so that you can establish a
sequence as a directed graph.
The sequence does break. It's not perfect at all. Signing chains can't
be traced back infinitely. A signer is not available to affirm that the
sequence is correct. There will be parallel sequences of signing
chains where there aren't crosslinks available to help you interleave
events.
Constantly establishing keys doesn't make sense. The algorithm works
just as well if there is a third bit of data, a use-once token. Can that
work? Don't know.
</pre>
</blockquote>
What do you mean?<br>
<br>
<blockquote type="cite"
cite="midPine.LNX.4.44.0206270910160.9060-100000@localhost.localdomain">
<pre wrap="">
Like anything else this half assed, somebody must have already written
this idea up better with actual discipline!
</pre>
</blockquote>
You'd be surprised; this looks like virgin territory. There has been _very_
little work on distributed timing services, unless someone made breakthroughs
in a parallel field and didn't realize that it could be applied to this problem.
I think the problem is worth solving. Once you have a crytographicly secure
distributed time service you can use it to create first come, first served
bindings between pieces of data, such as username to public key, or web site
name to IP address. Binding username to public key and stamping it with
the time would let you create a first come, first served distributed PKI
service, while binding web site name to IP address would let you create a
first come, first served distributed naming service.<br>
<br>
As a solution to this problem, I'm wondering how our bodies establish a sort
of time or cycles that are used somehow. I think there might be some interesting
biological/chemical solutions to this problem that can be used as inspiration,
similar to the famous Bray-Liebhafsky reaction that exhibited chemical oscillations.
In the BL reaction, certain chemicals are placed in a dish. After a brief
period of inactivity, the dish begins to oscillate from red to blue and back
again in a cyclic, clock-like pattern. The BL experiment has been called
important because it is a simple chemical reaction that might help us understand
how biological time-like oscillations happen. A biological time-keeping
service, so to speak, would have to solve many of the problems in the peer-to-peer
example: decentralized, no central trust, nodes fall in and out (cell birth
and death), and resistance to hijacking by cancerous cells or viruses.<br>
<br>
Thanks,<br>
Brad Neuberg<br>
codinginparadise.org<br>
<br>
<blockquote type="cite"
cite="midPine.LNX.4.44.0206270910160.9060-100000@localhost.localdomain">
<pre wrap="">
- Lucas
_______________________________________________
p2p-hackers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:p2p-hackers@zgp.org">p2p-hackers@zgp.org</a>
<a class="moz-txt-link-freetext" href="http://zgp.org/mailman/listinfo/p2p-hackers">http://zgp.org/mailman/listinfo/p2p-hackers</a>
</pre>
</blockquote>
<br>
<br>
</body>
</html>
--------------030106050903060307010605--