<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><div class="gmail_default" style="font-size:small">Thank you for the comments.They are useful.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 2, 2019 at 7:35 AM Alfie John <alfie@alfie.wtf> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;">On 2 May 2019, at 12:46 am, Phillip Hallam-Baker <<a href="mailto:phill@hallambaker.com" target="_blank">phill@hallambaker.com</a>> wrote:<br><div><blockquote type="cite"><br class="gmail-m_-4949678190837777507Apple-interchange-newline"><div><div dir="ltr"><div style="font-size:small">Looking for review and comment on the following:</div><div style="font-size:small"><br></div><div style="font-size:small">The DARE structure uses a public key exchange to establish a master key. Individual records can then be encrypted under a key generated from that master key by means of HKDF Key Generation with a unique per entry salt.</div><div style="font-size:small"><br></div></div></div></blockquote><blockquote type="cite"><div><div dir="ltr"><div style="font-size:small">Besides GDPR compliant server logs, I can think of many, many applications. I use the structure extensively in the Mesh to manage sets and lists of entries. One of the applications I have always had in mind is end-to-end secure Web services including chat rooms and comment forums/mailing lists.</div><div style="font-size:small"><br></div><div style="font-size:small">So is there anything I must add?</div></div></div></blockquote><div><br></div><div>A concern I have is that it looks like it currently doesn't deal with forward secrecy. This is a must in 2019, especially when used for chat. Non-reputablity may be another feature that others may say is missing, but not sure how you would do this in an offline system such as yours.</div></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">There are applications for which forward secrecy is essential and applications where it is impossible. Forward secrecy makes no sense in an infrastructure sharing credential information between devices. So I tend to think we over-emphasize forward secrecy.</div><br></div><div><div class="gmail_default" style="font-size:small">That said, I do have a design for forward secrecy, it just isn't made clear in the current documents. I will add it to part 8 which describes the cryptographic algorithms. The key agreement schedule uses a mix-in key on both sides of the DH exchange as a nonce. All you need to achieve forward secrecy is to pre-share the mix in keys and throw away the private keys when you are done with the key exchange. This is essentially the photoris mechanism.</div><br></div><div><div class="gmail_default" style="font-size:small">This is not going to appear in the container format because the key management has to be handled synchronously and containers are a storage format. </div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><div>1.3.5 - when switching to a new container, I would suggest the last entry in old container contain a pointer to the new one. Consider this analogously as signing your new GPG key with your old one. It will also help with your notary system so that nobody can travel back in time and point readers to a completely different container (with large amounts of data however, traversing this will be slow. Maybe consider a tree-like structure for containers rather than daisychain for performance, but this then breaks your append-only log aims though... just a thought).</div></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">I have not given much thought to container roll-over at this point. There are multiple ways of using containers and it is not clear whether roll-over is a feature of containers or of a particular application of containers.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The first record of log file containers and persistence store containers is usually empty. It would be logical to place a notary entry in the first record. This could link to previous containers in the series and to external notary sources.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">At present, the question I have kinda punted on is whether to introduce notary sources as content data or as header data. It might well be that different approaches are appropriate for different container applications. </div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><div>1.3.6 - I'm not sure using DARE for Bitcoin works there isn't a concept of a master key used to sign and encrypt blocks. Consider Bitcoin as a public broadcast with multiple untrusted writers whereas DARE is trusted between participants.</div></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">BitCoin is not my intended field of application :-)</div><br></div><div class="gmail_default" style="font-size:small">This is more for applications like GDPR.</div><div class="gmail_default" style="font-size:small"></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><div>1.3.7 - I'd consider adding my concern about the performance of traversing a daisy chain if implemented.</div></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">[Thanks for introducing the term traversal, I was using the word index to mean two different things, will fix]</div></div><div><br></div><div><div class="gmail_default" style="font-size:small">There are three traversal options, chain, tree and indexed. Which is used depends on the application.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I have considered getting rid of chains entirely. But it is impossible to differentiate these from indexed containers that have not been finalized yet. One of the cool things about containers is that the append only structure allows us to have multiple concurrent writers. So one process can be appending to a file while another is compiling an index on it. Yet another possibility is that the index could be maintained in a file separate from the container that is indexed.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So consider a file archive. The most useful traversal mechanism would be to have an index of every record in the file in the last record. This would allow O(1) access to any record in the file if the index was appropriately represented (i.e. JSON-B binary representation using table of fixed length integers)</div><br></div><div><div class="gmail_default" style="font-size:small">Index at the end is not possible for log files though. So we would likely want to decide on some max chain length m (128 entries for example) and then create a delta index every n entries and compile these into delta trees giving us O (m + log2 (n) - log2(m) ) efficiency in time for O(nl/m) additional space (where l is the length of the index entry)</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><blockquote type="cite"><div><div dir="ltr"><div style="font-size:small">Right now, I have not published my MetaNotary protocol because I haven't implemented it. I have published the basis for the analysis though in the trust paper.</div><div style="font-size:small"><br></div><div style="font-size:small">A MetaNotary is simply any notary that includes the outputs of other notaries. Thus it is possible to prove quite easily that no other scheme can ever present a higher work factor than a MetaNotary since if such a notary existed, the MetaNotary can simply consume its output as an input and present at least equal the work factor.</div><div style="font-size:small"><br></div><div style="font-size:small">In short, the system will hold together through reciprocity. Since <a href="http://metanotary.com/" target="_blank">metanotary.com</a> was taken, I call this the emergent reciprocal meta-system the internotary.</div></div></div></blockquote><div><br></div>Be aware of colluding notaries in your threat model. If incentives are high enough, it will happen.</div><div><br></div><div>Alfie</div></div></blockquote><div><br></div><div class="gmail_default" style="font-size:small">The notaries can collude but the collusion is visible to anyone running a notary or observing the system. If the system is sufficiently large and public, we would have the US, Russia, UK, Iran, France, Cuba national notaries all in the mix and they would all have to collude. Plus the EFF, Microsoft, Apple, Google.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Collusion can be proved because the notaries sign their terminal nodes according to a published schedule. Any notary that fails to deliver its signed node is in arrears, any that is shown to have signed two incompatible terminal nodes has defected. Defection is highly visible.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Applied to finance, the question that I think BitCoin folk miss entirely is that the banking system has held together for 300 years performing reconciliations only at the end of each day. I just moved my 401K from one institution to another by way of a cheque. Looking at the possibilities for default in that system, the possibilities for default in the internotary system look rather minor. Notaries can collude but only so long as they can prevent any leakage of the signed notary outputs outside the system they have defected on. Once they defect, they must continue to maintain a second chain. Defecting multiple times requires multiple chains.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The cost of maintaining the defection rises exponentially as the outputs are introduced to other notaries which must also be induced to collude. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Ultimately, I believe the internotary system must hold together as the incentive to refuse defection rises as the value of the system rises but the incentive to coerce defection is never as great as the value of the system and is likely constant.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So when the system starts, I would not expect many people to put much trust in it so there would be essentially $0 incentive to induce a defection. Five years on, we might have a dozen groups at the likes of MIT, Apple, EFF etc, running 'unofficial' services. It is doubtful that such a system would be used for financial transactions but there might be a $1 million incentive to induce a defection to assist a US criminal investigation. Well, we already know what happens to those.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Ten years on we might well be using the system for financial purposes and have a few hundred banks running notaries. At this point it is infeasible for any one government to subpoena all the notaries and attempt to coerce them. So there might be a $30 million incentive to coerce a defection (i.e. upper level of FBI most wanted bounties) but the incentive to resist defection would be $1 billion with expectation of rising to $1 trillion.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Yes, collusion is possible but the system would be in the hands of the people who have the greatest investment in the system itself. The system hangs together because of accountability. Any defection is certain to be detected and lead to consequences.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Now there would of course be small scale 'defections' resulting from technical issues and even small scale fraud. But it is highly unlikely that this would ever spread from one notary to another.</div></div></div>