Score:0

How such so called Merkle pre image are computed?

in flag

I’ve just encountered the following source code which is used as an authentication mechanism where the bytes32 leaf is the hashed action to authenticate :

/**
 * @dev These functions deal with verification of Merkle trees (hash trees),
 */
library MerkleProof {
    /**
     * @dev Returns true if a `leaf` can be proved to be a part of a Merkle tree
     * defined by `root`. For this, a `proof` must be provided, containing
     * sibling hashes on the branch from the leaf to the root of the tree. Each
     * pair of leaves and each pair of pre-images are assumed to be sorted.
     */
    function verify(bytes32[] memory proof, bytes32 leaf) internal pure {
        bytes32 computedHash = leaf;

        for (uint256 i = 0; i < proof.length; i++) {
            bytes32 proofElement = proof[i];

            if (computedHash <= proofElement) {
                // Hash(current computed hash + current element of the proof)
                computedHash = keccak256(abi.Pack(computedHash, proofElement));
            } else {
                // Hash(current element of the proof + current computed hash)
                computedHash = keccak256(abiPack(proofElement, computedHash));
            }
        }

        // Check if the computed hash (root) is equal to the provided root
        assert(computedHash == 0xc8500f8e2fcf3c9a32880e1b973fb28acc88be35787a8abcf9981b2b65dbdeb5);
    }
}

Normally, as it’s written, it would be easy to just compute 0xc8500f8e2fcf3c9a32880e1b973fb28acc88be35787a8abcf9981b2b65dbdeb5 valid for only one run using a secret leaf.
But this isn’t how it is used as the User who created this was able to authenticate for several leafs showing up such as using

merkleProof
bytes32[]
0x27977cb9a27fe48eacb9809791189627c3d42c327a133994adcc26ffe6fbd7c6
0x42a3a3163d7993d10d2d6fa154137d15b803e4771db48e03a9a066f41a2a037c
0xb4d9ebe7a56eaf823ec05d5f0ee1e08bc4917b2c00c6af40c6696d960b480580
0xf911550a25e43a18f238b55c8f61b672ec94acc6e9290960d8b12e0f535841a5
0x525d5bbffdd54cfa075c8c346bc56695486c7cba273c8e861b111935b898ba4e
0xbff59fe6953c761a7ba4499e4645967c9dd6410f0e80a87a85e96ab884a1023a
0x5a0610d9246b3955e3e459d82276ac8aa69069180e114bdb497ad8a7cddb3055
0x65cadf58b21e7e8f908b2528c5b300ee5ca43773669117184328676086cc1359
0x42cbbb624022596ee2aa0d869e8221782eec9f8c3487e17275613efbd614535c
0x43ed4ccb42398c917f6457be68a70b7db629e4120d4f51fa2045e4ae0022929a
0x221a4d89152f92618462ec2541b0b00c991625dce5166422670285ad1a5e37e4
0x181fca872c4698abf8c3e3a4b8705aea87051365a447d4b6ebcaf31c390b0880
0x66544fe813712a87d879c4b5ac6e374c5825044f8d60006d896e275e91fe3380
0x8f9599fdbc83862cb0feef1ace9ef17f66de28456af3be32a504dd050a1fd06a
0xb6f5484cc7b6323b30777fb0d5091bcfedd6ce0fbe5e159fa55766dc5e52a3a6
0x065fac43945e3ad3233b9ea36bd857a5f8b895a4d9436d2d84dfc6ee0bf761f0
0x7ee288dbeb891db482d495d13101e25f5efe250f1e53df20a329717b01f91134
0xdb2d94e778166bcbacf53ba7b9d34046fbf18943170ec79565b21c5d8499e490

or

merkleProof
bytes32[]
0x61a15081e2ed951092e2c3f1a660115c898dc65587a1429f289d9fefcc3733db
0xa2352823200685a085191ae962a2febb5d1c21f87fb2a721231a95cd54befba6
0x81d1618aeb427189f6d10ac65febc20032f866b670c6ce24ba81f58d07be8e64
0xab0b0909f5c4e99d9df1f4db02a602f40ca9c6f9307e13cd2c079c4cf7857755
0xdd9a04c9643b86672d5c6b41de3ab5e7be8af504ed3c4a590b415526abf29b92
0x5dc2e9451acb9794743c46fbaf6c886c083ce6a1a70627348bf9a5667627862d
0x8163ad6a22786e670fc838b8616ed87c4c16c5bccf75e1eb210be40f186b5c37
0x9020eeb5b847771ffebf1aa285de2563d231f0311d997ca0bde86a75572c728e
0x352266c127b9f0819ba51396bd61aaa7933f62384570cbdbe278468a016beb4d
0xc1fed80c0d54c5fa950582cc2d2404a2c52f649775f81c210cea3660bd3d1606
0xd333207a53d07ca2ca424c73a2e37ae26aac8ce862505fc6e729fe09589a6eff
0xd0da005f3ca9dea5bb791b82dbc34914e3ec70edc71ea49bc32fd04b06b68186
0x75321389bfadf0641313e0e8eef8257418ae596da57d46920d7796eaf2539a22
0x1506546f7e41b28d226e27037b533ab6850d9dd5d899d2f4b1bc8e72601bdc42
0xd5e600b0ff793547824f1056e9573400b28cb9ad822e705761ef2687d9206e11
0x335a4bbb9d0d484fedb3710c00155d55e011b2d28d4d03da9b1f3fc4a8d59f72
0x4e08bb6b91a529a32255dbe645bfc0a7f4cd36a6c19565e7a436fd34d038432a
0xdb2d94e778166bcbacf53ba7b9d34046fbf18943170ec79565b21c5d8499e490

but how so those sets of proofs (they are many of them) that are used as pre‑image against a leaf are computed ? Is there a key or something else ?
When I Google about Merkle proofs I only find information about ever growing Merkle Trees, where a piece of specific information references a previous hash which can be later referenced as a new hash. I’m meaning something not related to the ability to find pre‑image at will like this.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.