[Cryptography] hash/sign material for distro of IoT params

[Natanael]

Den 1 jan 2015 18:33 skrev "ianG" <iang at iang.org>:
>
> On 31/12/2014 03:53 am, grarpamp wrote:
>>
>> I'd consider models of hashing and signing distributed materials
>> as a serious and necessary applied crypto conversation.
>
>
> One of the things that is going on in the bitcoin 2.0 world is that some
of the groups are wrestling with how to distribute different instruments.
As we know, Natoshi Sakamoto hit upon an elegant simplification by
eliminating the semantics of his issue, by the trick of only having one.
This simplification breaks down as soon as you want more than one issue,
more than one chain, more than one semantics.  As soon as you want choice
in anything, more or less.
>
> One way to distribute information about something like an issuance of
value is what I call the Ricardian Contract [0].  This is a contractual
document that has a few smart fields slipped in, and carries its own PKI.
When cleartext signed to fix it, it can then be canonically hashed to form
the identifier for the unit of issuance.
>
> Now, if you look at things like blockchains, there is an emerging pattern
that many people want to run their own, and different ones.  But the basic
pattern is the same, in that the description of any given blockchain
remains largely in the same format, with some different parameters [1].  If
one imagines a commercial service running a chain for some particular
purpose -- call it coffeechain for low value fast retail -- then we could
also include some static contractual information.  Something like an open
combination of params and legal text could be useful to describe
coffeechain.
>
> The same pattern might be observed with IoT devices that can be accessed
from anywhere.  We need to access the public key of the device, we need
examine the params, and we need to be able to examine the service
conditions.
>
> Why is this interesting?  Because if we are in a world of millions of
these things, we also need some strong identifiers, and ways to go from the
identifier to the description without fail, and ways to go from the
description to the identifier without fail.
>
> We also need a world in which anyone can play.  We don't want a world
where in order to run a chain or put up a new device, we have to get the
permission of someone else, or get enslaved to some facade security model
which incumbents lock up and stop from migrating in OODA time.
>
> Using an open document and taking the message digest of it for service as
the identifier for that document/device achieves some of those goals, at
least on paper.
>
>
>> Not
>> least of why because many of the people on these lists have no
>> idea how to actually do such things, let alone well.
>
>
> Indeed.  And my knowledge of IoT devices is rather popularist.  So, does
a device have these characteristics?  Does it have some params that need
exploring?  Does it have a service agreement?  A need to publish keys,
control info, etc?
>
> Could we benefit from having an architecture that settles on one
identifier across the IoT space, and uses (eg) a DHT to find the document
for it?
>
> I don't know.  It seems analogous enough to ask, what would a
cryptographically secure data infrastructure be for small cheap devices on
the net?

I'm not sure if I have correctly understood what you are looking for, do
you want a generic public append-only data structures with custom
validation rules?

But the blockchain derived document management system Factom might be
relevant. They've got things like what they call "proof of process" where
you frequently publish documents in a chain where one can verify that
there's just ONE chain of such documents and which is the most recent one
(you can't hide or replace old documents or create forks). http://factom.org

Then we have the various Turing complete prototype altcoins where you can
create your own namespaces á la Namecoin and register and process arbitary
data. But that's still not all the way there.

I've been considering something much more flexible myself by merging the
concepts between Namecoin, Pay-to-script-hash addresses in Bitcoin (P2SH)
and the Turing complete coins plus Zero-knowledge proofs like what Zerocoin
uses.

Here is what Zerocoin does: there's a global mixing address which you use
by committing to a unique secret "serial number", a nonce, when sending
coins to it. All these transactions are then entered into an RSA based
one-way accumulator (assuming this is for simplifying ZKP creation). To
withdraw you create an address in a deterministic way from your serial
number (so it can't be used twice this way) and generate a Zero-knowledge
proof of that you did indeed send coins to the mixer and haven't previously
claimed then. This allows you to withdraw a random set of coins of the same
value as what you sent to the mixer.

P2SH is a way in Bitcoin to force the usage of a certain script to withdraw
coins from that address. Multisignature addresses all use P2SH, to enforce
the requirement of signing with multiple specified keys.

Now you could extend this: you would register a data structure / namespace
with predefined validation rules which you then must prove you have
followed by using Zero-knowledge proofs. This way you can keep the contents
and even the validation rules you're using secret, and yet the miners don't
need to know anything more than that your public transaction with its
commitment hashes and its pointers to your previous transactions has a
valid Zero-knowledge proof.

This allows anybody to prove and verify just about anything that can be
stated algorithmically AND simultaneously ensure global consistency of
those same claims. Scoreboards, financial audits, checkpointing your own
internal databases, etc, you could use it for just about anything.

And for your question on identifiers, this would allow you to specify that
too in the transactions as part of the public data. You could refer to an
entry in another DNS data structure, or to a DHT, or a Tor or I2P service,
etc...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20150110/cf27ea62/attachment.html>