Hi all, While Instantiating the chaincode I am getting following Error 2019-10-29 13:14:40.559 UTC [msp.identity] Sign -> DEBU 04a Sign: plaintext: 0ADE080A6708031A0C08C0F6E0ED0510...30300A000A0465736

#fabric #fabricca #fabric-ca #fabric-chaincode #fabric-questions

Thanks for replying Yacov and Senthil. You're right that since the introduction of private data, Fabric recommends that private data be salted to avoid dictionary attacks. As this thread makes clear n

#fabric-chaincode #ssl #fabric #fabric-questions #fabric-dstorage

PrivateData is marketed as a data privacy solution in Hyperledger Fabric. Unfortunately, this is just another serious security hole somehow went under the radar, and all projects using this function a

#fabric-chaincode #ssl #fabric #fabric-questions #fabric-dstorage

Hi Ivan. If you have a chaincode that requires more than 1 organization to endorse the transaction, you need the execution of both chaincodes to produce the same results, so the hashes of the private

#fabric-chaincode #ssl #fabric #fabric-questions #fabric-dstorage

Hi Ivan, Thank you for bringing this. We have discussed about including salt in the private data design document

#fabric-chaincode #ssl #fabric #fabric-questions #fabric-dstorage

thanks for reply but I think you guys are down playing the seriousness of this issue. if u add salt then the salt must be passed to others so others can validate. to avoid others to launch dictionary

#fabric-chaincode #ssl #fabric #fabric-questions #fabric-dstorage

I think you might have missed one of the points on how you can actually pass in a salt value to all endorsing peers. Proposal (endorsement) requests have a "transient" field which can be used. The val

#fabric-chaincode #ssl #fabric #fabric-questions #fabric-dstorage

Hey Ivan. Private data is disseminated in a point to point manner among peers even now. The peers that posses the private data, send the peers that don't (but are eligible of receiving it) the hash pr

#fabric-chaincode #ssl #fabric #fabric-questions #fabric-dstorage

I am trying to setup fabric network using external-ca and so I have to register and enroll certs for all the peers and clients and for registration of certificates LDAP server is being used. After gen

#fabric-ca #fabric-chaincode #raft

Thanks again Ivan for pointing out the documentation hole - here's the doc update that describes how private data is secured: https://hyperledger-fabric.readthedocs.io/en/latest/private-data-arch.html

#fabric-chaincode #ssl #fabric #fabric-questions #fabric-dstorage

Lemons into lemonade. Thanks David and others who turned this from flame war kindling to a positive outcome. Brian

#fabric-chaincode #ssl #fabric #fabric-questions #fabric-dstorage

Hi Ivan. > you try to argue that the salted hash on the public chain is a proof that some data is "valid". this itself is a terrible argument because hashes (unlike digital signature, homomorphic encr

#fabric-chaincode #ssl #fabric #fabric-questions #fabric-dstorage

Hi Yacov, thanks for your reply, let me clarify the jargon here so more people can understand pre-image: data itself and its salt first of all, I appreciate you agree that another point 2 point connec

#fabric-chaincode #ssl #fabric #fabric-questions #fabric-dstorage

I don't think that's a valid example for private data - Private data can only prevent your actually ID from being read by other unauthorized parties, as for whether that ID is valid or not, it's reall

#fabric-chaincode #ssl #fabric #fabric-questions #fabric-dstorage

Hey Ivan, Correct me if I'm wrong, but it seems you are thinking that the private data as implemented is flawed, and that the requirement to salt the data to secure it defeats the purpose of having th

#fabric-chaincode #ssl #fabric #fabric-questions #fabric-dstorage

Hi Alexandre, Yacov Thanks for your reply and I appreciate the discussion. my hands are tight now so I will give my full response later today: Yes, my point is private data design maybe flawed in two

#fabric-chaincode #ssl #fabric #fabric-questions #fabric-dstorage

Your second point is not specific to private data. Agreement on input data needs to be part of the application design, regardless of whether it is a private data scenario or not. For example the smart

#fabric-chaincode #ssl #fabric #fabric-questions #fabric-dstorage

Dave, Yacov, and Alex Seems that the general response to this scenario is “this is an application design problem and should be solved by chaincode” But my argument here is that chaincode design can’t

#fabric-chaincode #ssl #fabric #fabric-questions #fabric-dstorage

You are essentially suggesting to add a warning that private data content can't be known by non-members of the collection. That is the whole point of private data and anybody considering an implementa

#fabric-chaincode #ssl #fabric #fabric-questions #fabric-dstorage

Hi Ivan, As far as I know, Blockchain/DLT platform itself does not claim to find fake data. However, one may build an application using blockchain to find fake data. An example from real-world -- http

#fabric-chaincode #ssl #fabric #fabric-questions #fabric-dstorage