Date   

Re: #fabric #configtxgen Configtxgen alternative #configtxgen #fabric

Jean-Gaël Dominé <jgdomine@...>
 

I know the cryptogen tool is not needed. I was just making a comparison between the two of them because I found the way to get rid of cryptogen but not configtxgen.

Do you have an example or a link showing how to create the genesis block through the SDK without configtxgen?

Thank you


Re: #fabric #configtxgen Configtxgen alternative #configtxgen #fabric

tangross@...
 

CA SDK can mostly replace cryptogen, except the CA admin registration. The creation of genesis block can be done by SDK, along with the use of Fabric CA. No need for cryptogen tool at all. 

On 23 Oct 2019, at 5:46 PM, Jean-Gaël Dominé <jgdomine@...> wrote:

Hi everyone,

I have some questions regarding the configtxgen tool. Lately, I spent some time replacing the cryptogen tool by using the CAs instead to generate all the certificates and keys because the tool is for development only.
However, it seems to me that the same thing could apply to the configtxgen tool but I did not find a way to do without it.
Some posts talk about the SDK providing methods to perform some similar actions but it seems that you still need this tool to generate some artifacts such as the genesis block.

So any insights on that matter?

Thank you


Re: How to manage the Multi-Version Concurrency Control (MVCC) in Fabric on time-critical applications

David Enyeart
 

Range queries use a variant of a sorted B-tree and the underlying data files will be in system cache, therefore it will be extremely performant to get the lowest/highest key in a range.


Dave Enyeart

"Mr.Phuwanai Thummavet" ---10/23/2019 05:58:13 AM---I understand your point. In the case of the auction system, nevertheless, how can I get the best cur

From: "Mr.Phuwanai Thummavet" <mr.thummavet@...>
To: Yacov Manevich <YACOVM@...>
Cc: fabric@...
Date: 10/23/2019 05:58 AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] How to manage the Multi-Version Concurrency Control (MVCC) in Fabric on time-critical applications
Sent by: fabric@...





I understand your point. In the case of the auction system, nevertheless, how can I get the best current price when I do transaction queries. Maybe I have to use the range-based queries to seek the best price every time there is a query? I think that would affect system performance if there are a lot of queries. I also concern about querying time in the case that the system gets massive adoption.

On Wed, Oct 23, 2019 at 4:21 PM Yacov Manevich <YACOVM@...> wrote:
    you don't have to write to the same key.

    You can have each voter / bidder commit to his vote / bid by writing to a separate key that corresponds to its identity, and in the end have all the voters / bidders reveal their votes / bids, and this will not create any MVCC conflicts.



    From:        
    "Mr.Phuwanai Thummavet" <mr.thummavet@...>
    To:        
    fabric@...
    Date:        
    10/23/2019 12:16 PM
    Subject:        
    [EXTERNAL] [Hyperledger Fabric] How to manage the Multi-Version Concurrency Control (MVCC) in Fabric on time-critical applications
    Sent by:        
    fabric@...




    Hi everyone,

    I know that the multi-version concurrency control (MVCC) is used to address double-spending problems in Fabric. However, the MVCC might become one of the most obstacles when designing time-critical applications such as auction and voting systems. On a voting system, for example, two voters commit to voting for the same candidate in the same block-time frame. This results in an invalid transaction for the 2nd voter according to the MVCC.

    My solution to such an issue was to use an off-chain messaging queue system to gather and categorize certain transaction requests from clients. Then, the batches of the categorized transactions were sent to a chaincode to invoke.

    Here are my questions:
    1.        Was my solution suitable for the above example? 
    2.        Does anyone have better solutions?
    3.        Is Hyperledger Fabric suitable for real-time applications such as auction and voting systems?

    Thanks.

    --
    Best Regards,
    Phuwanai Thummavet





--
Best Regards,
Phuwanai Thummavet
Blockchain Architect and Full-Stack Developer




Re: How to manage the Multi-Version Concurrency Control (MVCC) in Fabric on time-critical applications

Yacov
 

there are all kinds of auction types.... English auction, Dutch auction, etc. - you need first to specify exactly the use case and only afterwards ask how you do it with Fabric



From:        "Mr.Phuwanai Thummavet" <mr.thummavet@...>
To:        Yacov Manevich <YACOVM@...>
Cc:        fabric@...
Date:        10/23/2019 12:58 PM
Subject:        [EXTERNAL] Re: [Hyperledger Fabric] How to manage the Multi-Version Concurrency Control (MVCC) in Fabric on time-critical applications
Sent by:        fabric@...




I understand your point. In the case of the auction system, nevertheless, how can I get the best current price when I do transaction queries. Maybe I have to use the range-based queries to seek the best price every time there is a query? I think that would affect system performance if there are a lot of queries. I also concern about querying time in the case that the system gets massive adoption.


On Wed, Oct 23, 2019 at 4:21 PM Yacov Manevich <YACOVM@...> wrote:
you don't have to write to the same key.

You can have each voter / bidder commit to his vote / bid by writing to a separate key that corresponds to its identity, and in the end have all the voters / bidders reveal their votes / bids, and this will not create any MVCC conflicts.




From:        
"Mr.Phuwanai Thummavet" <mr.thummavet@...>
To:        
fabric@...
Date:        
10/23/2019 12:16 PM
Subject:        
[EXTERNAL] [Hyperledger Fabric] How to manage the Multi-Version Concurrency Control (MVCC) in Fabric on time-critical applications
Sent by:        
fabric@...




Hi everyone,

I know that the multi-version concurrency control (MVCC) is used to address double-spending problems in Fabric. However, the MVCC might become one of the most obstacles when designing time-critical applications such as auction and voting systems. On a voting system, for example, two voters commit to voting for the same candidate in the same block-time frame. This results in an invalid transaction for the 2nd voter according to the MVCC.

My solution to such an issue was to use an off-chain messaging queue system to gather and categorize certain transaction requests from clients. Then, the batches of the categorized transactions were sent to a chaincode to invoke.

Here are my questions:
1.        
Was my solution suitable for the above example? 
2.        
Does anyone have better solutions?
3.        
Is Hyperledger Fabric suitable for real-time applications such as auction and voting systems?

Thanks.

--
Best Regards,
Phuwanai Thummavet




--
Best Regards,
Phuwanai Thummavet
Blockchain Architect and Full-Stack Developer




[Conference] Attend Genesis DevCon - a blockchain developer conference, Bangalore

suzana.joel@...
 

Hi everyone,


I am Suzana Joel from IBC Media. Currently, we’re organizing Genesis DevCon - a blockchain developer conference on 24th & 25th of November at IISc in Bengaluru.


The objective of genesis DevCon is to educate & motivate developers to takeup blockchain development, by bringing in some of the brilliant minds from India & across the globe.


Event website: https://theibc.events/


At Genesis DevCon listen to these trailblazers


  1. Satya Lokam, Senior Researcher, Microsoft Research lab, India

  2. John deVadoss, Head, Development, NEO blockchain

  3. Dilip Krishnaswamy, Vice President- New Technology Initiatives, Reliance Jio Infocomm Ltd

  4. Yanislav Malahov, Founder, Aeternity

  5. Loi Luu, CEO & CoFounder, KyberNetwork

  6. Dr. Chang Ee-Chien, Associate professor,  National University of Singapore

  7. Manish Bhatia, Chief Technology Officer, Amazon India

  8. Shay Zluf, Core Developer, Prysmatic Labs, Israel

  9. Dumitrel Loghin, Research Fellow, National University of Singapore

  10. Pankaj S Dayama, Senior Researcher, IBM India Research Laboratory

  11. Debdeep Mukhopadhyay, Professor, Indian Institute of Technology, Kharagpur

  12. Hung Dang, Research Fellow, National University of Singapore

and 20 more


For the members of BangPypers we would like to offer an additional Rs. 250 off on early bird price of Rs. 1000.


Use the coupon code to get Rs. 250 off - GENESIS250


Book your early bird tickets now - https://in.explara.com/e/genesis-devcon--a-blockchain-developer-conference.


Some of the tech talk topics would be

  • Zero-knowledge proof

  • Sharding

  • Blockchain on low power nodes

  • Blockchain microservices

  • Blockchain & AI

  • Tech behind decentralized exchange

  • Ethereum 2.0

  • Smart contract security

  • ISO standards for blockchain solution

and 15 more


3 workshops

  • Blockchain 101 with an introduction to Solidity

  • How to deploy blockchain solutions

  • Legalities for setting up blockchain startups in India


Event details:

Date: 24 & 25 November 2019

Venue: Indian Institute of Science, Bengaluru


Book your tickets now - https://in.explara.com/e/genesis-devcon--a-blockchain-developer-conference


Use the coupon code to get Rs. 250 off - GENESIS250


Looking forward to seeing you for Genesis Devcon 2019. Feel free to get in touch with me in case you have any queries. 


Regards,

Suzana Joel

IBC Media 


------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
This message and any files or text attached to it are intended only for the recipients named above, contain information that is confidential or privileged. If you are not an intended recipient, you must not read, copy, use or disclose this communication. Please also notify the sender by replying to this message, and then delete all copies of it from your system.


Re: How to manage the Multi-Version Concurrency Control (MVCC) in Fabric on time-critical applications

Mr.Phuwanai Thummavet
 

I understand your point. In the case of the auction system, nevertheless, how can I get the best current price when I do transaction queries. Maybe I have to use the range-based queries to seek the best price every time there is a query? I think that would affect system performance if there are a lot of queries. I also concern about querying time in the case that the system gets massive adoption.


On Wed, Oct 23, 2019 at 4:21 PM Yacov Manevich <YACOVM@...> wrote:
you don't have to write to the same key.

You can have each voter / bidder commit to his vote / bid by writing to a separate key that corresponds to its identity, and in the end have all the voters / bidders reveal their votes / bids, and this will not create any MVCC conflicts.



From:        "Mr.Phuwanai Thummavet" <mr.thummavet@...>
To:        fabric@...
Date:        10/23/2019 12:16 PM
Subject:        [EXTERNAL] [Hyperledger Fabric] How to manage the Multi-Version Concurrency Control (MVCC) in Fabric on time-critical applications
Sent by:        fabric@...




Hi everyone,

I know that the multi-version concurrency control (MVCC) is used to address double-spending problems in Fabric. However, the MVCC might become one of the most obstacles when designing time-critical applications such as auction and voting systems. On a voting system, for example, two voters commit to voting for the same candidate in the same block-time frame. This results in an invalid transaction for the 2nd voter according to the MVCC.

My solution to such an issue was to use an off-chain messaging queue system to gather and categorize certain transaction requests from clients. Then, the batches of the categorized transactions were sent to a chaincode to invoke.

Here are my questions:
1.        Was my solution suitable for the above example? 
2.        Does anyone have better solutions?
3.        Is Hyperledger Fabric suitable for real-time applications such as auction and voting systems?

Thanks.

--
Best Regards,
Phuwanai Thummavet





--
Best Regards,
Phuwanai Thummavet
Blockchain Architect and Full-Stack Developer


#fabric #configtxgen Configtxgen alternative #configtxgen #fabric

Jean-Gaël Dominé <jgdomine@...>
 

Hi everyone,

I have some questions regarding the configtxgen tool. Lately, I spent some time replacing the cryptogen tool by using the CAs instead to generate all the certificates and keys because the tool is for development only.
However, it seems to me that the same thing could apply to the configtxgen tool but I did not find a way to do without it.
Some posts talk about the SDK providing methods to perform some similar actions but it seems that you still need this tool to generate some artifacts such as the genesis block.

So any insights on that matter?

Thank you


Re: How to manage the Multi-Version Concurrency Control (MVCC) in Fabric on time-critical applications

Yacov
 

you don't have to write to the same key.

You can have each voter / bidder commit to his vote / bid by writing to a separate key that corresponds to its identity, and in the end have all the voters / bidders reveal their votes / bids, and this will not create any MVCC conflicts.



From:        "Mr.Phuwanai Thummavet" <mr.thummavet@...>
To:        fabric@...
Date:        10/23/2019 12:16 PM
Subject:        [EXTERNAL] [Hyperledger Fabric] How to manage the Multi-Version Concurrency Control (MVCC) in Fabric on time-critical applications
Sent by:        fabric@...




Hi everyone,

I know that the multi-version concurrency control (MVCC) is used to address double-spending problems in Fabric. However, the MVCC might become one of the most obstacles when designing time-critical applications such as auction and voting systems. On a voting system, for example, two voters commit to voting for the same candidate in the same block-time frame. This results in an invalid transaction for the 2nd voter according to the MVCC.

My solution to such an issue was to use an off-chain messaging queue system to gather and categorize certain transaction requests from clients. Then, the batches of the categorized transactions were sent to a chaincode to invoke.

Here are my questions:
1.        Was my solution suitable for the above example? 
2.        Does anyone have better solutions?
3.        Is Hyperledger Fabric suitable for real-time applications such as auction and voting systems?

Thanks.

--
Best Regards,
Phuwanai Thummavet




How to manage the Multi-Version Concurrency Control (MVCC) in Fabric on time-critical applications

Mr.Phuwanai Thummavet
 

Hi everyone,

I know that the multi-version concurrency control (MVCC) is used to address double-spending problems in Fabric. However, the MVCC might become one of the most obstacles when designing time-critical applications such as auction and voting systems. On a voting system, for example, two voters commit to voting for the same candidate in the same block-time frame. This results in an invalid transaction for the 2nd voter according to the MVCC.

My solution to such an issue was to use an off-chain messaging queue system to gather and categorize certain transaction requests from clients. Then, the batches of the categorized transactions were sent to a chaincode to invoke.

Here are my questions:
  1. Was my solution suitable for the above example? 
  2. Does anyone have better solutions?
  3. Is Hyperledger Fabric suitable for real-time applications such as auction and voting systems?

Thanks.

--
Best Regards,
Phuwanai Thummavet


Re: Major security hole in Hyperledger Fabric - Private Data is not private #fabric-chaincode #ssl #fabric #fabric-questions #fabric-dstorage

Yacov
 

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 encryption) is not something that others can verify when the data (hash) it put on public chain.

No, that's not what I am arguing.
I said: , and the receiving peers validate the hash pre-images indeed correspond to the hashes on the public block
which means that they do just that - ensure that the hash pre-image of the private data corresponds to the hash in the public block.

That's what private data is - a means for several organizations to send each other information without putting it on the blockchain, but still bind the data to the blockchain for non repudiation of the fact that the data was put there (not of any other world / business facts as in your example).


> first of all, I appreciate you agree that another point 2 point connection must be established between orgs to pass the salt and the image itself, anything on chain can be used to launch pre-image/dictionary attack

Well, but this is already what is done now. This is how private data works in Fabric:
  • You (as the user) have the ability to put on the blockchain hashes of salted data.
  • The data is disseminated in a secure point to point connection between peers that are eligible of receiving the data.


- Yacov




From:        "Ivan Ch" <acizlan@...>
To:        fabric@...
Date:        10/23/2019 05:59 AM
Subject:        [EXTERNAL] Re: [Hyperledger Fabric] Major security hole in Hyperledger Fabric - Private Data is not private #fabric #fabric-questions #fabric-dstorage #database #dstorage #dstorage-fabric #fabric-chaincode #ssl
Sent by:        fabric@...




Hi Yacov,

thanks for your reply, let me clarify the jargon here so more people can understand

pre-image:
data itself and its salt
"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 pre-images, and the receiving peers validate the hash pre-images indeed correspond to the hashes on the public block.

I don't see any technical obstacle that prevents you to add a salt per collection name for a given transaction, that will be concatenated to the computation of the hash of the key and the value for the said collection.The salt can be part of the data element that is generated at the time of chaincode invocation, and will be passed along with the private data itself."

first of all, I appreciate you agree that another point 2 point connection must be established between orgs to pass the salt and the image itself, anything on chain can be used to launch pre-image/dictionary attack

of course there is no technical obstacle to create salt, but the issue here is that it creates a false sense that data is private and can be validated. let me explain:

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 encryption) is not something that others can verify when the data (hash) it put on public chain.

here is an example:
my national ID is "1234567", but I am a bad guy and want others to believe that my national ID number is "7654321". so I put the false hash(salt, "7654321") on chain, and then send pre-images (salt, "7654321")  to whoever I want to convince. Since nobody can verify the hash(salt, "7654321")  when the hash was put on chain without prior knowledge of the data, an adversary can use the claims about private data functionality to trick people to believe forged data.

my point is that the claims about private data mislead people to believe this feature will either help to orgs to protect data or validate a pre-existing data, but neither is true and can be easily used by an adversary to decode data (if there is no salt or salt is known) or to trick people believe in wrong data like the sample above.















Re: Major security hole in Hyperledger Fabric - Private Data is not private #fabric-chaincode #ssl #fabric #fabric-questions #fabric-dstorage

Jay Guo
 

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 really up to your application to decide. If someone is simply allowed to put arbitrary data on chain without proving it, I'd say that's a problem with application design, instead of Private Data in Fabric.

Hopefully this makes sense
- J

On Wed, Oct 23, 2019 at 10:59 AM Ivan Ch <acizlan@...> wrote:
Hi Yacov, 

thanks for your reply, let me clarify the jargon here so more people can understand

pre-image: data itself and its salt
"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 pre-images, and the receiving peers validate the hash pre-images indeed correspond to the hashes on the public block.

I don't see any technical obstacle that prevents you to add a salt per collection name for a given transaction, that will be concatenated to the computation of the hash of the key and the value for the said collection.
The salt can be part of the data element that is generated at the time of chaincode invocation, and will be passed along with the private data itself."
first of all, I appreciate you agree that another point 2 point connection must be established between orgs to pass the salt and the image itself, anything on chain can be used to launch pre-image/dictionary attack

of course there is no technical obstacle to create salt, but the issue here is that it creates a false sense that data is private and can be validated. let me explain:

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 encryption) is not something that others can verify when the data (hash) it put on public chain.

here is an example: my national ID is "1234567", but I am a bad guy and want others to believe that my national ID number is "7654321". so I put the false hash(salt, "7654321") on chain, and then send pre-images (salt, "7654321")  to whoever I want to convince. Since nobody can verify the hash(salt, "7654321")  when the hash was put on chain without prior knowledge of the data, an adversary can use the claims about private data functionality to trick people to believe forged data.

my point is that the claims about private data mislead people to believe this feature will either help to orgs to protect data or validate a pre-existing data, but neither is true and can be easily used by an adversary to decode data (if there is no salt or salt is known) or to trick people believe in wrong data like the sample above.












Re: Major security hole in Hyperledger Fabric - Private Data is not private #fabric-chaincode #ssl #fabric #fabric-questions #fabric-dstorage

Ivan Ch <acizlan@...>
 

Hi Yacov, 

thanks for your reply, let me clarify the jargon here so more people can understand

pre-image: data itself and its salt
"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 pre-images, and the receiving peers validate the hash pre-images indeed correspond to the hashes on the public block.

I don't see any technical obstacle that prevents you to add a salt per collection name for a given transaction, that will be concatenated to the computation of the hash of the key and the value for the said collection.
The salt can be part of the data element that is generated at the time of chaincode invocation, and will be passed along with the private data itself."
first of all, I appreciate you agree that another point 2 point connection must be established between orgs to pass the salt and the image itself, anything on chain can be used to launch pre-image/dictionary attack

of course there is no technical obstacle to create salt, but the issue here is that it creates a false sense that data is private and can be validated. let me explain:

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 encryption) is not something that others can verify when the data (hash) it put on public chain.

here is an example: my national ID is "1234567", but I am a bad guy and want others to believe that my national ID number is "7654321". so I put the false hash(salt, "7654321") on chain, and then send pre-images (salt, "7654321")  to whoever I want to convince. Since nobody can verify the hash(salt, "7654321")  when the hash was put on chain without prior knowledge of the data, an adversary can use the claims about private data functionality to trick people to believe forged data.

my point is that the claims about private data mislead people to believe this feature will either help to orgs to protect data or validate a pre-existing data, but neither is true and can be easily used by an adversary to decode data (if there is no salt or salt is known) or to trick people believe in wrong data like the sample above.












Re: Major security hole in Hyperledger Fabric - Private Data is not private #fabric-chaincode #ssl #fabric #fabric-questions #fabric-dstorage

Brian Behlendorf <bbehlendorf@...>
 

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

Brian

On 10/22/19 8:28 AM, David Enyeart wrote:

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#protecting-private-data-content


Dave Enyeart

"David Enyeart" ---10/21/2019 11:03:49 AM---Thanks for replying Yacov and Senthil. You're right that since the introduction of private data, Fa

From: "David Enyeart" <enyeart@...>
To: "Senthil Nathan" <cendhu@...>
Cc: Ivan Ch <acizlan@...>, fabric@...
Date: 10/21/2019 11:03 AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Major security hole in Hyperledger Fabric - Private Data is not private #fabric #fabric-questions #fabric-dstorage #database #dstorage #dstorage-fabric #fabric-chaincode #ssl
Sent by: fabric@...





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 not everybody knows about the private data solution design considerations. I've opened Jira issue https://jira.hyperledger.org/browse/FAB-16885 to enhance the documentation with these considerations.


Dave Enyeart

"Senthil Nathan" ---10/21/2019 09:58:56 AM---Hi Ivan, Thank you for bringing this. We have discussed about including salt in

From:
"Senthil Nathan" <cendhu@...>
To:
Ivan Ch <acizlan@...>
Cc:
fabric@...
Date:
10/21/2019 09:58 AM
Subject:
[EXTERNAL] Re: [Hyperledger Fabric] Major security hole in Hyperledger Fabric - Private Data is not private #fabric #fabric-questions #fabric-dstorage #database #dstorage #dstorage-fabric #fabric-chaincode #ssl
Sent by:
fabric@...




Hi Ivan,

    Thank you for bringing this. We have discussed about including salt in the private data design document --
https://docs.google.com/document/d/1ShrgrYPWLznZSZrl5cnvmFq9LtLJ3tYUxjv9GN6rxuI/edit?usp=sharing
(please refer to section 2.6 Additional Consideration -- Salt Consideration).
We do have a JIRA for the same as well -- https://jira.hyperledger.org/browse/FAB-5101 but didn't implement
it as we have decided to leave it to the user for now (also for simplicity & flexibility).

    The salt to the data can always be added by the client which submits the transaction proposal. For example,
in the following JSON content, there can be an additional field called salt and the user can add any random data
to avoid a dictionary attack.
{"menu": {
"id": "file",
"value": "File",
"popup": {
  "menuitem": [
    {"value": "New", "onclick": "CreateNewDoc()"},
    {"value": "Open", "onclick": "OpenDoc()"},
    {"value": "Close", "onclick": "CloseDoc()"}
  ]
}

"salt": 88d4266fd4e6338d13b845fcf289579d209c897823b9217da3e161936f031589

}}


The same can be done for the keys too, not just values. As far as I know, many developers who use private data
follow this approach. I agree that a few might be unaware of this. As Yacov mentioned, we should add this approach
to our doc.

Regards,
Senthil

On Mon, Oct 21, 2019 at 6:51 PM Ivan Ch <acizlan@...> wrote:
      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 are at risk.  

      It amazes me that nobody had mentioned this before so I guess I better point this out now before more damages are being done.  

      The logic behind Privated data is simple, it put data in a local embedded data store and put a hash of that data on blockchain.  

      The issue is that cryptographic hash is not an encryption mechanism, same data hashed by anyone using the same hashing algorithm will always get you the same hash! This is exactly what hash functions are designed for, and that’s why we use hash in digital signature to allow anyone to validate signed data.   However, this also means that anyone can “decrypt” the data behind the hash by launching dictionary attack.  

      Hashing is cheap, the cost of each hash on a normal laptop cpu core is about 3 microseconds, basically I can create 1 billion candidate result hashes within one hour on a single laptop cpu, and check if they match to the hashes on hyperledger fabric DLT.   And I am just talking about using a single cpu on my laptop, not even 50% of its processing power  

      Why is it dangerous? Because if an attacker is connected to a blockchain system, the attacker likely know the range of the data being hashed (for example, hashed data could be trade ID, item name, bank name, address, cell phone number), so you can easily create dictionary attack to get the true data behind the hash.  

      How about adding salt to each data to be hashed? Well, that’s one thing Hyperledger Fabric didn’t do.   To their defense, hyperledger didn’t implement salt because it is difficult to pass salts to counter parties. You can’t use DLT to pass salt value to counter parties because attackers would see it, so you have to create another p2p connection with counter party and send it over.

      If you already have p2p connection with all the counter parties, what’s the point of using blockchain in the first place? just send your data over! It’s just scary that so many people are using this security hole and put their data in de facto clear text.  

      Sure, if the hashed data is so big then it would harder to perform dictionary attack, but you better be very careful before using this feature because any mis-use will result in data leak, it is sad so many people actually believe this is a problem solver









-- 
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf


Re: Major security hole in Hyperledger Fabric - Private Data is not private #fabric-chaincode #ssl #fabric #fabric-questions #fabric-dstorage

David Enyeart
 

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#protecting-private-data-content


Dave Enyeart

"David Enyeart" ---10/21/2019 11:03:49 AM---Thanks for replying Yacov and Senthil. You're right that since the introduction of private data, Fa

From: "David Enyeart" <enyeart@...>
To: "Senthil Nathan" <cendhu@...>
Cc: Ivan Ch <acizlan@...>, fabric@...
Date: 10/21/2019 11:03 AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Major security hole in Hyperledger Fabric - Private Data is not private #fabric #fabric-questions #fabric-dstorage #database #dstorage #dstorage-fabric #fabric-chaincode #ssl
Sent by: fabric@...





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 not everybody knows about the private data solution design considerations. I've opened Jira issue https://jira.hyperledger.org/browse/FAB-16885 to enhance the documentation with these considerations.


Dave Enyeart

"Senthil Nathan" ---10/21/2019 09:58:56 AM---Hi Ivan, Thank you for bringing this. We have discussed about including salt in

From:
"Senthil Nathan" <cendhu@...>
To:
Ivan Ch <acizlan@...>
Cc:
fabric@...
Date:
10/21/2019 09:58 AM
Subject:
[EXTERNAL] Re: [Hyperledger Fabric] Major security hole in Hyperledger Fabric - Private Data is not private #fabric #fabric-questions #fabric-dstorage #database #dstorage #dstorage-fabric #fabric-chaincode #ssl
Sent by:
fabric@...




Hi Ivan,

    Thank you for bringing this. We have discussed about including salt in the private data design document --
https://docs.google.com/document/d/1ShrgrYPWLznZSZrl5cnvmFq9LtLJ3tYUxjv9GN6rxuI/edit?usp=sharing
(please refer to section 2.6 Additional Consideration -- Salt Consideration).
We do have a JIRA for the same as well -- https://jira.hyperledger.org/browse/FAB-5101 but didn't implement
it as we have decided to leave it to the user for now (also for simplicity & flexibility).

    The salt to the data can always be added by the client which submits the transaction proposal. For example,
in the following JSON content, there can be an additional field called salt and the user can add any random data
to avoid a dictionary attack.
{"menu": {
"id": "file",
"value": "File",
"popup": {
  "menuitem": [
    {"value": "New", "onclick": "CreateNewDoc()"},
    {"value": "Open", "onclick": "OpenDoc()"},
    {"value": "Close", "onclick": "CloseDoc()"}
  ]
}

"salt": 88d4266fd4e6338d13b845fcf289579d209c897823b9217da3e161936f031589

}}


The same can be done for the keys too, not just values. As far as I know, many developers who use private data
follow this approach. I agree that a few might be unaware of this. As Yacov mentioned, we should add this approach
to our doc.

Regards,
Senthil

On Mon, Oct 21, 2019 at 6:51 PM Ivan Ch <acizlan@...> wrote:
      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 are at risk.  

      It amazes me that nobody had mentioned this before so I guess I better point this out now before more damages are being done.  

      The logic behind Privated data is simple, it put data in a local embedded data store and put a hash of that data on blockchain.  

      The issue is that cryptographic hash is not an encryption mechanism, same data hashed by anyone using the same hashing algorithm will always get you the same hash! This is exactly what hash functions are designed for, and that’s why we use hash in digital signature to allow anyone to validate signed data.   However, this also means that anyone can “decrypt” the data behind the hash by launching dictionary attack.  

      Hashing is cheap, the cost of each hash on a normal laptop cpu core is about 3 microseconds, basically I can create 1 billion candidate result hashes within one hour on a single laptop cpu, and check if they match to the hashes on hyperledger fabric DLT.   And I am just talking about using a single cpu on my laptop, not even 50% of its processing power  

      Why is it dangerous? Because if an attacker is connected to a blockchain system, the attacker likely know the range of the data being hashed (for example, hashed data could be trade ID, item name, bank name, address, cell phone number), so you can easily create dictionary attack to get the true data behind the hash.  

      How about adding salt to each data to be hashed? Well, that’s one thing Hyperledger Fabric didn’t do.   To their defense, hyperledger didn’t implement salt because it is difficult to pass salts to counter parties. You can’t use DLT to pass salt value to counter parties because attackers would see it, so you have to create another p2p connection with counter party and send it over.

      If you already have p2p connection with all the counter parties, what’s the point of using blockchain in the first place? just send your data over! It’s just scary that so many people are using this security hole and put their data in de facto clear text.  

      Sure, if the hashed data is so big then it would harder to perform dictionary attack, but you better be very careful before using this feature because any mis-use will result in data leak, it is sad so many people actually believe this is a problem solver









Re: TCerts function in Fabric CA #fabric-ca

Gari Singh <garis@...>
 

We have an open task to remove all of that code from Fabric CA.
I'm planning to remove it in 2.0

-----------------------------------------
Gari Singh
Distinguished Engineer, CTO - IBM Blockchain
IBM Middleware
550 King St
Littleton, MA 01460
Cell: 978-846-7499
garis@...
-----------------------------------------

-----fabric@... wrote: -----
To: fabric@...
From: "Jeehoon Lim"
Sent by: fabric@...
Date: 10/22/2019 12:04AM
Subject: [EXTERNAL] [Hyperledger Fabric] TCerts function in Fabric CA #fabric-ca

Hi all,


I've read some docs that Transaction Certificates(TCerts) are not supported - replaced by Idemix - from Fabric 1.x .

But there are still remain TCerts related codes in the latest release of fabric-ca.
( https://github.com/hyperledger/fabric-ca/blob/master/lib/servertcert.go )
And it also has some commit history in this year.

Is Fabric CA still support TCerts, or the code is something like wings of chicken?

Regards,
Jeehoon Lim


Re: Major security hole in Hyperledger Fabric - Private Data is not private #fabric-chaincode #ssl #fabric #fabric-questions #fabric-dstorage

Yacov
 

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 pre-images, and the receiving peers validate the hash pre-images indeed correspond to the hashes on the public block.

I don't see any technical obstacle that prevents you to add a salt per collection name for a given transaction, that will be concatenated to the computation of the hash of the key and the value for the said collection.
The salt can be part of the data element that is generated at the time of chaincode invocation, and will be passed along with the private data itself.

I don't agree that point to point connections defeat the purpose of the Blockchain, as the all this point to point data that is kept off-chain can be easily and efficiently verified if needed since its value is bound to the public blocks.

- Yacov.



From:        "Ivan Ch" <acizlan@...>
To:        fabric@...
Date:        10/22/2019 12:23 PM
Subject:        [EXTERNAL] Re: [Hyperledger Fabric] Major security hole in Hyperledger Fabric - Private Data is not private #fabric #fabric-questions #fabric-dstorage #database #dstorage #dstorage-fabric #fabric-chaincode #ssl
Sent by:        fabric@...




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 attack, u must (in ur implementation)force peers to use private point2point connections to send the hash, otherwise u may create another security hole.

plus, forcing p2p connection among participants would literally destroy the purpose of blockchain.

this functionality need to change its name to something like "chain hash" to save others falsely believe this is a data privacy functionality. i know there must be marketing concerns calling it "private data", but u guys need to be responsible






Re: Major security hole in Hyperledger Fabric - Private Data is not private #fabric-chaincode #ssl #fabric #fabric-questions #fabric-dstorage

Gari Singh <garis@...>
 

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 value of this field can be extracted in chaincode and used to salt the data. It is never persisted in the actual ledger itself.

-----------------------------------------
Gari Singh
Distinguished Engineer, CTO - IBM Blockchain
IBM Middleware
550 King St
Littleton, MA 01460
Cell: 978-846-7499
garis@...
-----------------------------------------

-----fabric@... wrote: -----
To: fabric@...
From: "Ivan Ch"
Sent by: fabric@...
Date: 10/22/2019 05:23AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Major security hole in Hyperledger Fabric - Private Data is not private #fabric #fabric-questions #fabric-dstorage #database #dstorage #dstorage-fabric #fabric-chaincode #ssl

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 attack, u must (in ur implementation)force peers to use private point2point connections to send the hash, otherwise u may create another security hole.

plus, forcing p2p connection among participants would literally destroy the purpose of blockchain.

this functionality need to change its name to something like "chain hash" to save others falsely believe this is a data privacy functionality. i know there must be marketing concerns calling it "private data", but u guys need to be responsible


Re: Major security hole in Hyperledger Fabric - Private Data is not private #fabric-chaincode #ssl #fabric #fabric-questions #fabric-dstorage

Ivan Ch <acizlan@...>
 

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 attack, u must (in ur implementation)force peers to use private point2point connections to send the hash, otherwise u may create another security hole. 

plus, forcing p2p connection among participants would literally destroy the purpose of blockchain. 

this functionality need to change its name to something like "chain hash" to save others falsely believe this is a data privacy functionality. i know there must be marketing concerns calling it "private data", but u guys need to be responsible



Error while registering peer and client certs using LDAP server #fabric-ca #fabric-chaincode #raft

trinayanbhatt1@...
 

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 generating everything and starting the network there is some issue with chaincode instantiation as although the chaincode container gets up but still while listing for the chaincode on the peers the result set is empty. After checking for the peer and orderer logs:

peer logs :

warning: isn't eligible for channel testchannel : implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 1 of the 'Readers' sub-policies to be satisfied

error:  [blocksProvider] DeliverBlocks -> ERRO 4488e [testchannel] Got error &{FORBIDDEN}
           [blocksProvider] DeliverBlocks -> ERRO 4488f [testchannel] Wrong statuses threshold passed, stopping block provider

orderer logs:

[common.deliver] deliverBlocks -> WARN 263d [channel: testchannel] Client authorization revoked for deliver request from xx.xx.xx.xx:38880: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 1 of the 'Readers' sub-policies to be satisfied: permission denied

What I interpret from this is that the admin certificates and the peer certificates have some issue as they are being registered using LDAP where there is no option to define id-type for the identity.

Can anyone help to resolve this issue?


Re: kafka name change (fabric 1.1)

soumya nayak <soumyarjnnayak@...>
 

Hi Alok.

Check this JIRA 

https://jira.hyperledger.org/browse/FAB-7352

Regards,
Soumya

4441 - 4460 of 11422