[cryptography] Fwd: The Wandering Music Band

[realcr]

It has been a while, but I think I know now about an idea to solve this
problem.
I really appreciate all the help I got from your responses.

I wrote a document that explains it here:

https://www.newtolife.net/the-trusted-supernode-and-distributed-banking.html

Abstract:

The Trusted Supernode is an abstract idea for a distributed secure and
efficient banking system. This system allows payment operations that
disturb only small amount of participants. It overcomes adversarial attacks
by applying a useful proof of work, combined with node mixing.

The Trusted Supernode bank system relies at its core on a special form of
trusted entity called the supernode. In addition to its ability to manage
payments, the supernode should allow to securely exchange computation and
storage services for money.


real.

-- Forwarded message --
From: realcr 
Date: Wed, Jan 7, 2015 at 5:40 PM
Subject: The Wandering Music Band
To: cryptography@randombit.net


Hi,
I am looking for some crypto primitive to solve a problem I have.

Assume that I meet a group of people. call it S. I get to talk to them a
bit, and
then they are gone.

This group of people walk together in the world. Sometimes they add a
person to
their group, and sometimes they remove one person. (You can assume it's a
music
band, then it all makes sense). Generally, though, you may assume that they
have
at least k people in the group at all times.

Assume that I meet the resulting group at some time in the future, after
many
members were added or removed. How can the new group S' prove to me that
they
are the descendants of the original group S?

I include here some of my thoughts about this.

1. Naive Solution: Remembering lots of signatures.

Every person in the world will have a key pair (of some asymmetric crypto)
to
represent his identity. When I first meet the group S, I collect all their
public keys and keep them.

Whenever a new member x is added to the group S, all the current members of
S
sign over the new list: S U {x}. Whenever a member x is removed from the
group
S, all the current members of S sign over the new list S \ {x}. The group
members always have to carry with them all the signatures since the
beginning of
time.

When I meet the group at some point in the future, I can just ask them to
prove
their current public keys, and also to show me all the signatures since the
beginning.

My issue with this solution is that the group has to remember more and more
signatures as time goes by. I wonder if there is a more efficient way.


2. Using "Transitive Signatures"

I have seen two articles about a concept called Transitive Signatures.
Shortly: Given a signature of x over y, and of y over z, any participant
will be
able to generate a signature where x signs over z.

http://people.csail.mit.edu/rivest/MicaliRivest-TransitiveSignatureSchemes.pdf
https://eprint.iacr.org/2004/215.pdf

I didn't manage to apply this method to my problem though.


I will appreciate any idea or hint about how to solve this.

Regards,
real.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Fwd: The Wandering Music Band

[Natanael]

Den 10 dec 2015 21:02 skrev "realcr" :
>
> It has been a while, but I think I know now about an idea to solve this
problem.
> I really appreciate all the help I got from your responses.
>
> I wrote a document that explains it here:
>
>
https://www.newtolife.net/the-trusted-supernode-and-distributed-banking.html
>
> Abstract:
>
> The Trusted Supernode is an abstract idea for a distributed secure and
efficient banking system. This system allows payment operations that
disturb only small amount of participants. It overcomes adversarial attacks
by applying a useful proof of work, combined with node mixing.
>
> The Trusted Supernode bank system relies at its core on a special form of
trusted entity called the supernode. In addition to its ability to manage
payments, the supernode should allow to securely exchange computation and
storage services for money.

Interesting approach.

So you create a top-level supernode W as a gatekeeper? How do you handle
the abnormal incentives to become corrupted for these members? And hacking
risk? What about node selection attacks (including RNG manipulation)
performed by existing bad members trying to increase the share of bad
nodes? Any kind of trust / reputation / behavior based node priority in the
node selection?

Then of course having separate T_user's risks synchronization issues too,
how do you ensure consistency with 3 or more of these at once,
simultaneously sending and receiving multiple requests?

And network disruptions and hacking with zerodays are also not dealt with.
Also, it looks like you didn't deal with the risk of good nodes that used
to be in the group turning bad after the fact and faking the history, which
is really critical over long time periods. And overall, it looks easy to
disrupt by messing with the network.

Also what if somebody prevents a supernode from communicating with good
nodes (a variant of sybil where you isolate the target, an eclipse attack)
during node selection? Forcing the choice of bad nodes?

And your risk calculation is a point-in-time value for one single
supernode. What's the aggregate risk over time, given some defection rate
and some transition rate? The birthday paradox is relevant, for example.

While still not yet practical, Zero-knowledge proofs would enable signature
set compression.

As far as I can see, in stable trusting groups it can work reasonably well
even if large, but I doubt it can work in the long term in fully open
groups. In the latter case, you can not effectively defend against being
overrun by dishonest users.

Where I can see this being applied is for something like say cooperating
groups of sensors (maybe environmental sensors) with different owners
(different research teams?) in a large mesh network *without any explicit
adversaries* (but maybe some greedy users), where you can't guarantee a
reliable link to any trusted servers. So they coordinate themselves the
best they can with an algorithm like yours. There must be a low incentive
for malice.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography