Re: [Hyperledger Indy] Some Burning Questions on Decentralized Identity/Self-Sovereign Identity - Please help? -- Nathan Aw from Singapore

On Thu, Nov 15, 2018 at 6:22 PM Stephen Curran <swcurran@cloudcompass.ca>
wrote:

> I'll take a stab at these...
>
>
> *Stephen Curran*
> Principal, Cloud Compass Computing, Inc.
> P // 250-857-1096
> W // https://www.cloudcompass.ca
> [image: Twitter] <https://twitter.com/scurranC3I>
> On Nov 15 2018, at 9:06 am, Nathan Aw <nathan.mk.aw@gmail.com> wrote:
>
>
> Hi all,
>
> I am a blockchain engineer from Singapore. Been working on blockchain 3
> years back and now looking at decentralized identity very, very seriously.
>
> After studying and experimenting Hyperledger Indy on my machine, I
> discovered that Indy is a great decentralized platform and I am keen to
> evangelise this platform in this exciting part of the world - ASEAN.
>
> However, I have some genuine burning questions on decentralized identity
> and Indy. Please find questions below. Can someone help clarify, please?
>
> 1. Understand that Indy Node maintains a public permissioned distributed
> ledger and arrives at consensus via RBFT. In this ledger (rocksDB), it
> contains the transaction logs which are connection requests/proof request
> correct? Key-value store.
>
>
> No interactions between identities (e.g. connection requests/proof
> requests) go on the ledger. The things that go on the ledger are
> DIDs/DIDDocs, Schema, Credential Definitions and Revocation Registries.
> CredDefs link a Credential Issuers DID and a Schema to enable issuing
> Credentials. Revocation Registries are linked to CredDefs.
>
>
> 2. Other than a trust anchor, what could be the reason (i.e., incentives)
> for one to run a validator node? In short, why should anyone run a indy
> validator node?
>
>
> Currently, Public Good is the primary motivation. A currently null token
> implementation can be added to HL Indy and that could be used to create
> incentive. The Sovrin Foundation is at work determining how that might be
> used.
>
>
> 3. Since RBFT is the chosen consensus mechanism, what happens when more
> than 1/3 of the nodes turn malicious? Highly unlikely of course but
> assuming these nodes start to collude, etc, will the network come to a
> screeching halt? i.e., one is unable to issue claims, verify claims, etc
>
>
> I believe that is the case - the network could be slowed to a crawl and
> the processing of transactions would decrease. Note that this would only
> affect ledger transactions - reads and writes - and not so much
> peer-to-peer transactions, so some activities would be unaffected. However,
> even things like restarts of a server that has to refresh it's cache of
> ledger data would be impacted, as would revocation and checking revocation.
>
>
> 4. I like to explore a pan ASEAN decentralized identity solution where
> one's identity could be portable across the different ASEAN countries -- my
> driver license registered in Singapore can be used in Indonesia, for
> example. Can I assume that I need a Indy validator node in Indonesia as
> well? What are the technical setup required for a pan ASEAN/supra nation
> setup?
>
>
> You don't need a validator in any specific location, you just need access
> to the nodes that are in the network. You might want to have a validator
> else where for non-technical reasons, but there is no technical requirement.
>
>
> 5. Understand that privacy risk is mitigated through the use of unique
> pairwise DIDs with different trust anchors. pseudonym, that is. This is
> achieved through ed25519 cryptographic primitive. Is this idea/concept
> similar to public key private key relationship? Sort of mathematical
> relationship? Lastly, Is ed25519 quantum resistance?
>
>
> A bit of my expertise, but yes, ed25519 is a public/private key pair.
> Googling ed25519 quantum resistence and looking at the Wiki page suggests
> that it might be, but that's way out of my league. :-)
>

No public key crypto system that is based on the discrete log and factoring
primes is quantum resistant. All elliptic curves use the discrete log
problem. What this stems from is the fact that mathematicians know of two
algorithms that when implemented with quantum computers, they can be done
in a reasonable amount of time (days or less). Shor's algorithm can solve
the discrete log problem (g^x mod n, solve for x) and factoring problem (pq
= n, where p and q are primes) when implemented with quantum computers.
Shor's algorithm breaks all current public key crypto. Symmetric crypto
like AES encryption, Hashes like SHA256 are not affected by Shor's
algorithm. However, Grover's algorithm when implemented with quantum
computers does weaken symmetric cryptography. It doesn't solve any
particular problem, it reduces the search space by half, so 128 bits is
reduce to 64 bit security and 256 bits to 128 bits. Symmetric crypto
remains safe for keys at 256 bits or bigger and hashes at 512 bits or
bigger. When software says is quantum resistant, they might be correct if
they are using symmetric crypto with 256 bit keys and 512 bit hashes, but
not less nor if they use elliptic curves or RSA.

Cryptographers are currently investigating two leading algorithms that
would be quantum resistant (meaning there is no known method in current
computers or quantum that can solve them in a reasonable amount of time)

1- Lattices
2- Supersingular Isogeny Elliptic Curves.

I won't dive any deeper on those but you get the idea hopefully.

>
> To be sure, Indy is a great platform and I am keen to evangelise this
> platform. Hope someone can provide answers to the above questions.
>
> Thank you.
>
> Regards,
>
> Nathan Aw
> https://sg.linkedin.com/in/awnathan
>
> https://datatracker.ietf.org/meeting/103/materials/slides-103-dinrg-decentralized-identity-01
> https://www.hyperledger.org/news/speakersbureau
> https://erc725alliance.org/
> https://www.hyperledger.org/community/technical-ambassador
> https://www.meetup.com/BlockChain-Dapps-Technology/events/254556114/
>
> https://www.hyperledger.org/blog/2017/12/05/developer-showcase-series-nathan-aw-ntt-data
> https://www.meetup.com/Hyperledger-HK/events/248011521/
> https://blockchain.ieee.org/newsletter/editorial-board
>
> _._,_._,_
> Links:
> You receive all messages sent to this group.
>
> View/Reply Online (#265)
> <https://lists.hyperledger.org/g/indy/message/265> | Reply To Sender
> <?subject=Private:%20Re:%20%5BHyperledger%20Indy%5D%20Some%20Burning%20Questions%20on%20Decentralized%20Identity%2FSelf-Sovereign%20Identity%20-%20Please%20help%3F%20--%20Nathan%20Aw%20from%20Singapore>
> | Reply To Group
> <indy@lists.hyperledger.org?subject=Re:%20%5BHyperledger%20Indy%5D%20Some%20Burning%20Questions%20on%20Decentralized%20Identity%2FSelf-Sovereign%20Identity%20-%20Please%20help%3F%20--%20Nathan%20Aw%20from%20Singapore>
> | Mute This Topic <https://lists.hyperledger.org/mt/28147776/952312> | New
> Topic <https://lists.hyperledger.org/g/indy/post>
>
> Your Subscription <https://lists.hyperledger.org/g/indy/editsub/952312> | Contact
> Group Owner <indy+owner@lists.hyperledger.org> | Unsubscribe
> <https://lists.hyperledger.org/g/indy/unsub> [swcurran@cloudcompass.ca]
>
> _._,_._,_
>
>

-- 
Mike Lodder
Security Maven