From d0eecbac79d5789c0a8a82c95a646657418a3461 Mon Sep 17 00:00:00 2001 From: David Enyeart Date: Tue, 22 Oct 2019 09:19:24 -0400 Subject: [PATCH] [FAB-16885] Doc usage of salt for private data Document the usage of salt for protecting private data. Change-Id: I004d83f451a2d468f0b43aaf6ffaf61f56fd56b9 Signed-off-by: David Enyeart (cherry picked from commit c0fa06dd5ddfb8d1f0016720bd5f267a1066c2b8) --- docs/source/private-data-arch.rst | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/docs/source/private-data-arch.rst b/docs/source/private-data-arch.rst index add71a93db4..b8a89e40b33 100644 --- a/docs/source/private-data-arch.rst +++ b/docs/source/private-data-arch.rst @@ -190,6 +190,19 @@ data), to chaincode invocation on the peer. The chaincode can retrieve the ``transient`` field by calling the `GetTransient() API `_. This ``transient`` field gets excluded from the channel transaction. +Protecting private data content +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +If the private data is relatively simple and predictable (e.g. transaction dollar +amount), channel members who are not authorized to the private data collection +could try to guess the content of the private data via brute force hashing of +the domain space, in hopes of finding a match with the private data hash on the +chain. Private data that is predictable should therefore include a random "salt" +that is concatenated with the private data key and included in the private data +value, so that a matching hash cannot realistically be found via brute force. +The random "salt" can be generated at the client side (e.g. by sampling a secure +psuedo-random source) and then passed along with the private data in the transient +field at the time of chaincode invocation. + Access control for private data ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~