[Cryptography] Blockchain for encryption

Thu May 2 09:05:57 EDT 2019

Thank you for the comments.They are useful.

On Thu, May 2, 2019 at 7:35 AM Alfie John <alfie at alfie.wtf> wrote:

> On 2 May 2019, at 12:46 am, Phillip Hallam-Baker <phill at hallambaker.com>
> wrote:
>
>
> Looking for review and comment on the following:
>
> 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.
>
> 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.
>
> So is there anything I must add?
>
>
> 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.
>

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.

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.

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.

> 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).
>

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.

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.

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.

> 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.
>

BitCoin is not my intended field of application :-)

This is more for applications like GDPR.

> 1.3.7 - I'd consider adding my concern about the performance of traversing
> a daisy chain if implemented.
>

[Thanks for introducing the term traversal, I was using the word index to
mean two different things, will fix]

There are three traversal options, chain, tree and indexed. Which is used
depends on the application.

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.

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)

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)

> 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.
>
> 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.
>
> In short, the system will hold together through reciprocity. Since
> metanotary.com was taken, I call this the emergent reciprocal meta-system
> the internotary.
>
>
> Be aware of colluding notaries in your threat model. If incentives are
> high enough, it will happen.
>
> Alfie
>

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.

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.

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.

The cost of maintaining the defection rises exponentially as the outputs
are introduced to other notaries which must also be induced to collude.

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.

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.

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.

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20190502/d6b4ca16/attachment.html>