Privacy enabled causes payload string for example_02 to exceed 10Megabytes

[beaufort2015]

Using the codebase as of Friday March 11, 2016...

I have modified docker-compose-4-consensus-sieve.yml to enable 'privacy' by adding this statement to the environment clause for vp0-3

• OPENCHAIN_SECURITY_PRIVACY=true

And when I run the following behave script.

@chaincodeImagesUpToDate

Feature: lanching 4 peers As an openchain developer I want to be able to launch a bunch of peers

@doNotDecompose

@wip

Scenario Outline: chaincode example02 with 4 peers and 1 obcca, issue #567

    Given we compose "<ComposeFile>"
    And I wait "2" seconds
    And I register with CA supplying username "binhn" and secret "7avZQLwcUe9q" on peers:
         | vp0  |
    And I use the following credentials for querying peers:
         | peer |   username  |    secret    |
         | vp0  |  test_user0 | MS9qrN8hFjlE |
         | vp1  |  test_user1 | jGlNl6ImkuDo |
         | vp2  |  test_user2 | zMflqOKezFiA |
         | vp3  |  test_user3 | vWdLCE00vJy0 |

    When requesting "/chain" from "vp0"
    Then I should get a JSON response with "height" = "1"
    And I wait "32" seconds
    When I deploy chaincode "github.com/openblockchain/obc-peer/openchain/example/chaincode/chaincode_example02" with ctor "init" to "vp0"
         | arg1 |  arg2 | arg3 | arg4 |
         |  a   |  100  |  b   |  200 |
    Then I should have received a chaincode name
    Then I wait up to "<WaitTime>" seconds for transaction to be committed to peers:
        | vp0  | vp1 | vp2 | vp3 |

    When I query chaincode "example2" function name "query" with value "a" on peers:
        | vp0  | vp1 | vp2 | vp3 |
    Then I should get a JSON response from peers with "OK" = "100"
        | vp0  | vp1 | vp2 | vp3 |

    When I invoke chaincode "example2" function name "invoke" on "vp0"
        |arg1|arg2|arg3|
        | a  | b  | 20 |
    Then I should have received a transactionID
    Then I wait up to "30" seconds for transaction to be committed to peers:
        | vp0  | vp1 | vp2 | vp3 |

    When I query chaincode "example2" function name "query" with value "a" on peers:
        | vp0  | vp1 | vp2 | vp3 |
    Then I should get a JSON response from peers with "OK" = "80"
        | vp0  | vp1 | vp2 | vp3 |

Examples: Consensus Options
    |          ComposeFile                     |   WaitTime   |
    |   mcc-docker-compose-4-consensus-sieve.yml   |      30      |

And this setting does indeed sort of work. The chaincodeID value in the transaction is encrypted.

The issue is encryption of the payload value seems to have gone beserk. The length of the payload value went from <200 bytes to over 10 megabytes. Even zipped up, it is greater than 7 megabytes and thus is not attached. And the query fails big time after the block is added to the chain...

Mike Cox

[adecaro]

@beaufort2015, do you have logs?

[beaufort2015]

I will re-create Wednesday, have been on the road.... what I have at hand is the log of the process that prints out the blocks as they are seen on the event listener interface. And other than very large, it is not interesting to look at..

[beaufort2015]

OK.. I have 3 very large files for documentation.

vagrant@vagrant-ubuntu-trusty-64:/openchain/privacy-test-doc$ ll total 81128 drwxr-xr-x 1 vagrant vagrant 238 Mar 16 11:48 ./ drwxr-xr-x 1 vagrant vagrant 816 Mar 16 11:29 ../ -rw-r--r-- 1 vagrant vagrant 10508590 Mar 16 11:48 agent-log.txt -rw-r--r-- 1 vagrant vagrant 22207 Mar 16 11:31 behave-log.txt -rw-r--r-- 1 vagrant vagrant 2484 Mar 16 11:31 mcc02_peer_basic.feature -rw-r--r-- 1 vagrant vagrant 1373 Mar 16 11:30 mcc-docker-compose-4-consensus-sieve.yml -rw-r--r-- 1 vagrant vagrant 72529358 Mar 16 11:32 peer-vp0-log.txt

agent-log - contains the output of the envent listener when it sees the new block go by when the init() method is run. you will see the block twice... but the key issue is the size of the payload value

behave-log - contains the console log of running the behave script (i.e., mcc02_peer_basic.feature ) along with the script itself and the modified yaml file to enavle privacy (i.e. mcc-docker-compose-4-consensus-sieve.yml)

peer-vp0-log - contains the output of the docker history command for vp0 container.

I created the parts using the command on my Mac: :/Users/mccox/Downloads/obc-work -> zip -r -s 9m archive.zip privacy-test-doc/ adding: privacy-test-doc/ (stored 0%) adding: privacy-test-doc/agent-log.txt (deflated 24%) adding: privacy-test-doc/behave-log.txt (deflated 84%) adding: privacy-test-doc/mcc-docker-compose-4-consensus-sieve.yml (deflated 78%) adding: privacy-test-doc/mcc02_peer_basic.feature (deflated 62%) adding: privacy-test-doc/peer-vp0-log.txt (deflated 58%) :/Users/mccox/Downloads/obc-work -> ll a* -rw-r--r-- 1 mccox staff 9437184 Mar 16 07:53 archive.z01 -rw-r--r-- 1 mccox staff 9437184 Mar 16 07:52 archive.z02 -rw-r--r-- 1 mccox staff 9437184 Mar 16 07:53 archive.z03 -rw-r--r-- 1 mccox staff 9437184 Mar 16 07:53 archive.z04 -rw-r--r-- 1 mccox staff 1030890 Mar 16 07:53 archive.zip :/Users/mccox/Downloads/obc-work ->

I did not issue docker logs command against all peers and all chaincode containers.

I had to postpend '.ZIP' to the file names to get this tool to accept the file type, simply remove it to reassemble. Do not try to unzip as is.

archive.z01.ZIP archive.z02.ZIP archive.z03.ZIP archive.z04.ZIP archive.zip.ZIP

Hopefully you can re-assemble the parts..

[beaufort2015]

Is anyone going to look at these logs?

Here is the interesting part of the peer vp0 log... starting with line number 1620

1620 11:21:38.618 [crypto] Deploy -> INFO 64c^[[0m Initializing client [binhn]...done! 1621 ^[[36m11:21:38.618 [devops] Deploy -> DEBU 64d^[[0m Creating secure transaction bb540edfc1ee2ac0f5e2ec6000677f4cd1c6728046d5e32dede7fea11a42f86a6 943b76a8f9154f4792032551ed320871ff7b7076047e4184292e01e3421889c 1622 ^[[36m11:21:38.622 [crypto] encryptTx -> DEBU 64e^[[0m [client.binhn] confidentiality protocol version [1.2] 1623 ^[[36m11:21:38.622 [crypto] encryptTx -> DEBU 64f^[[0m [client.binhn] Using confidentiality protocol version 1.2 1624 ^[[36m11:21:38.626 [crypto] encryptTxVersion1_2 -> DEBU 650^[[0m [client.binhn] Message to Validator: [04 ed 4a 92 04 76 64 38 ed dd 0c c4 55 a7 8d a2 b4 50 b4 c6 26 a2 e5 eb 6c 9f 32 f7 f2 38 05 6e 7a 74 cc 63 e3 d8 be 3d 67 a7 90 b3 27 a6 2b 62 66 05 b7 de 0f be 51 e2 1f 1b 75 ed 85 e5 c 5 5b 40 67 87 be c8 08 32 34 c8 7d f5 93 fb 95 d9 e3 c1 8c 1c 05 fd c8 58 c8 6d ce 29 25 60 80 88 19 b7 3b 7f 30 f4 fe 7b 91 71 8d 4e 77 23 09 52 85 5f f1 56 8b a8 7a 4f af e2 3b 20 bd b6 2b df 96 16 9b 88 aa 2b 86 df 49 4f 70 81 10 8d 40 db fc 56 4e 89 f4 75 b1 39 2a 60 74 1f 1f 06 3c ef f6 36 ef 3f c2 a0 8d c7 15 39 00 c5 4d 86 1d 35 46 71 0e 32 f5 02 63 47 14 12 87 c2 cd f8 96 7e 4e 36 ae 7f ca bf 79 33 1c d6 42 cb e8 09 3b f1 f 3 d6 2a cc 77 74 91 52 9e 76 76 e6 98 10 e0 1f ef 8b aa 44 28 e1 b7 1f 38 d2 b5 65 52 49 ee 77 ad c8 2f 33 9f 6f 2e 94 6a 49 79 fa 24 ce 0f ad 94 08 a2 77 78 2b d7 a2 52 67 89 91 f6 d8 b2 dd 14 b4] 1625 ^[[36m11:21:38.691 [crypto] newChaincodeDeployUsingTCert -> DEBU 651^[[0m [client.binhn] Appending certificate [30 82 01 c2 30 82 01 68 a0 03 02 01 02 02 01 01 30 0a 06 08 2a 86 48 ce 3d 04 03 03 30 29 31 0b 30 09 06 03 55 04 06 13 02 55 53 31 0c 30 0a 06 03 55 04 0a 13 03 49 42 4d 31 0c 3 0 0a 06 03 55 04 03 13 03 74 63 61 30 1e 17 0d 31 36 30 33 31 36 31 31 32 30 33 38 5a 17 0d 31 36 30 36 31 34 31 31 32 30 33 38 5a 30 2b 31 0b 30 09 06 03 55 04 06 13 02 55 53 31 0c 30 0a 06 03 55 04 0a 13 03 49 42 4d 31 0e 30 0c 06 03 55 04 03 13 05 62 69 6e 68 6e 30 59 30 13 06 07 2a 86 48 ce 3d 02 01 06 08 2a 86 48 ce 3d 03 01 07 03 42 00 04 c8 49 67 97 fb 56 63 b6 a6 65 f4 cf 3a e8 74 6e 32 c5 11 74 52 f7 e2 49 96 a5 df 03 c9 5 b aa ca 62 c6 6a 82 27 d4 00 9e fc 0a 4e 2f 00 94 a4 2b bc 0c 97 99 47 e0 3f 84 7e 49 a1 da cf ed 42 d8 a3 7f 30 7d 30 0e 06 03 55 1d 0f 01 01 ff 04 04 03 02 07 80 30 0c 06 03 55 1d 13 01 01 ff 04 02 30 00 30 0d 06 03 55 1d 0e 04 06 04 04 01 02 03 04 30 0f 06 03 55 1d 23 04 08 30 06 80 04 01 02 03 04 30 3d 06 06 2a 03 04 05 06 07 01 01 ff 04 30 84 15 03 0d 0e 59 73 d8 1d 8d 81 a3 1e f0 3f cd c9 55 01 cc 16 1f 5f 0f 16 82 79 48 fa 9 8 a5 2c b6 b7 3f d4 ba a6 ed 17 d0 1c 58 5a 0f 98 22 71 30 0a 06 08 2a 86 48 ce 3d 04 03 03 03 48 00 30 45 02 21 00 84 6e f5 92 a4 6e ab 68 26 b9 a6 cb d7 98 e4 13 ad ab bd fb 89 ed 4c b7 db 99 f1 07 ac 6c bc 89 02 20 07 6d 22 eb 2f f5 91 dd 7f ee 18 bb ca 72 a2 29 77 74 66 d9 83 00 30 0a 7c 13 e9 1a 75 4a cf a7].

The next line starts with: 1626 ^[[36m11:21:38.693 [crypto] newChaincodeDeployUsingTCert -> DEBU 652^[[0m [client.binhn] Signing tx [08 01 12 c8 02....

This line of trace data is 23641834 characters long according to vim

The next line starts with: 1627 ^[[36m11:21:38.838 [crypto] sign -> DEBU 653^[[0m [client.binhn] Signing message [08 01 12 c8 02 04 c7 c8 9d ....

This line of trace data is 23641815 characters long..

Here is the method that seems to create the havoc:

func (client _clientImpl) newChaincodeDeployUsingTCert(chaincodeDeploymentSpec *obc.ChaincodeDeploymentSpec, uuid string, tCert tCert, nonce []byte) (_obc.Transaction, error) { // Create a new transaction tx, err := client.createDeployTx(chaincodeDeploymentSpec, uuid, nonce) if err != nil { client.error("Failed creating new deploy transaction [%s].", err.Error()) return nil, err }

// Sign the transaction

// Append the certificate to the transaction
client.debug("Appending certificate [% x].", tCert.GetCertificate().Raw)
tx.Cert = tCert.GetCertificate().Raw

// Sign the transaction and append the signature
// 1. Marshall tx to bytes
rawTx, err := proto.Marshal(tx)
if err != nil {
    client.error("Failed marshaling tx [%s].", err.Error())
    return nil, err
}

// 2. Sign rawTx and check signature
client.debug("Signing tx [% x].", rawTx)
rawSignature, err := tCert.Sign(rawTx)
if err != nil {
    client.error("Failed creating signature [%s].", err.Error())
    return nil, err
}

// 3. Append the signature
tx.Signature = rawSignature

client.debug("Appending signature: [% x]", rawSignature)

return tx, nil

}

Someone needs to investigate and fix....

[srderson]

@adecaro please investigate