Make timestamp service (again)

[ineiti]

Have a modular possibility of including data in the timestamp.

[nikkolasg]

Have a modular possibility of including data in the timestamp.

? Well, generally, you submit any data, the timestamp service hash it and timestamp the hash, and returns you the hash + timestamp signed. What other thing you wanna add ?

[liamsi]

Have a modular possibility of including data in the timestamp.

Can you elaborate on that issue?

[ineiti]

Still confused about what we need to do and what the two different options from Friday's discussion are:

Timestamps A

• one for inclusion-proof of the timestamp and
• one for the latest software-updates at this moment in time

Timestamps B

Loosely-coupled timestamp-services

• just creates records of merkle-tree-inclusion-proves - perhaps every minute or every hour
• Associates freshness-proves with the time

[liamsi]

Ok, after discussing with @LefKok and @ineiti here is what we decided to do:

This writeup is a very drafty specification of the timestamp srevice:

We will (first) go with a simplified version where not all nodes of the cothority can take client requests (only the root node can). We will start with a binary tree.

Client = external clients

Client perspective

• Clients send hashes of data to the root node; for "swups" the data will be some client generated random number
• After epoch seconds the client receives is a timestamp and a collective signature on (timestamp, hash(treeroot)) plus an inclusion proof that proves that the clients nonce (or hash of it) has been included in the underlying merkle tree
• The client can now rebuild the for him relevant part of the tree and verify that the recvd. signature is valid and if the timestamp is in a certain fixed timeframe.

Remarks: epoch will be sth like 10s

Cothority (root node's) perspective

• Root node receives the hash of the data from several clients and includes these hashes in the leafs of the tree
• After epoch seconds the root node initiates a cosi round on (hash(treeroot), currentTimestamp)
• After cosi is done the root replies to each client request individually. The data (as mentioned above) is the timestamp, a collective signature on (timestamp, hash(treeroot)) plus an inclusion proof for the requested data (this might be different for every client).
• The role of the non-root nodes is to make sure that the timestamp proposed by the root-node isn't too far off to their notion of the current time (otherwise they refuse to sign). Exception mechanism still isn't implemented. Maybe later, it there is enough time (and if it is relevant for NSDI)

[liamsi]

Any comments, corrections, additions? /cc @LefKok @nikkolasg @ineiti ?

[nikkolasg]

Clients send hashes of data to the root node; for "swups" the data will be some client generated random number

hashES ? For me a generic timestamp service take one slice of byte, and do the timestamp on it. The client should be responsible for hashing the multiple documents together and then send the hash to the timestamp server. If we are going on with this, the timestamp server should only accept hashes, i.e. fixed size array of bytes.

[liamsi]

hashES ?

@nikkolasg Because the server collects multiple client requests (each containing one hash) from multiple clients. The cothority collects these requests and releases the signature when the epoch has passed. Is that more clear, now? Or still doesn't make sense?

Update: discussed offline with @nikkolasg. It was a misunderstanding (it's one hash per request but still several hashes per epoch).