TargetRandState Concern

[anthonyra]

blockchain-core/src/transactions/v2/blockchain_txn_poc_receipts_v2.erl

Line 221 in fe2a572

{Path, StartP} = get_path(POCVersion, Challenger, BlockTime, Entropy, Keys, Vars, OldLedger, Ledger, StartFT),

To check poc validity, we use the PoCOnionKeyHash which is first created with a validators heartbeat. This is submitted and selected by the CG. The originating validator then sees this OnionKeyHash (public key hash) being selected for PoC from the CG. It then generates the PoC. Later when checking if the PoC was valid, the PoCOnionKeyHash is used to validate ZoneRandState but the Keys supplied are never checked to match those for the submitted PoCOnionKeyHash. Which the private key is used to form the TargetRandState.

Without checking the PoCOnionKeyHash to the a re-hashed public key from the Keys, you could submit different Keys thus resulting in a deterministic TargetRandState for the PoC (potentially).

I feel that there should be a check between the PoCOnionKeyHash in the txn and the Keys submitted via the secret.

Secret = ?MODULE:secret(Txn),
Keys = libp2p_crypto:keys_from_bin(Secret),
#{public := OnionCompactKey, secret := {ecc_compact, POCPrivKey}} = Keys,
OnionHash = crypto:hash(sha256, libp2p_crypto:pubkey_to_bin(OnionCompactKey)),
case POCOnionKeyHash == OnionHash of
     true ->
             case blockchain_ledger_poc_v3:verify(PoC, Challenger, BlockHash) of
                    ...
                    {Path, StartP} = get_path(POCVersion, Challenger, BlockTime, Entropy, POCPrivKey, Vars, OldLedger, Ledger, StartFT),
             end;
     false ->
             {error, invalid_poc}
end

[andymck]

@anthonyra thanks for this. Validating the presented PocOnionKeyHash against the public key hash is good for correctness. Your suggestion also highlighted a wider weakness in that the txn is not verifying the key pair presented are actually a valid pair. I will address both in a PR shortly.

[andymck]

@anthonyra changes related to this merged here: #1312