Go through and check that all cryptography assumptions in the design are implemented in the code.

[aeyakovenko]

Problem

A large distributed team working asynchronously on a complex codebase may miss some things that everyone would think are obvious.

Proposed Solution

Go through important cryptography assumptions in the design and verify they are implemented in the code. File issues if integration or unit tests are missing.

TX signature checks

• Don’t vote on blocks with failed signatures
• sigverify can run asynchronously with replay stage, but needs to mark the block as verified before replay votes

• Entry verify fails if signature verification fails (ledger/src/entry.rs)

Validator Signature checks

• before voting on a block

• entry verify fails: ledger/src/entry.rs

• before forwarded to the leader

• core/src/banking_stage.rs filter_valid_packets_for_forwarding only forwards valid transactions

Leader TX Signature Checks

• before forwarded

• core/src/banking_stage.rs filter_valid_packets_for_forwarding only forwards valid transactions

• when received from a validator

• core/src/tpu.rs, forwarded tx sockets send their transactions to the TransactionSigVerifier

• after read from gossip

• core/src/cluster_info_vote_listener.rs calls sigverify::ed25519_verify_cpu(&msgs)

• after read from transaction packet queue

• core/src/tpu.rs transaction sockets send their data to TransactionSigVerifier

PoH Verification

• PoH is verified before voting on a block

• entry verify fails: ledger/src/entry.rs

Gossip CRDS Values

• before adding value into the crds
• before pushing messages forward

• CrdsValue::verify calls signature verify. ClusterInfo handle_packets calls verify on all received values. This prevents them from entering the push queue.

Turbine

• shreds are signed by the leader before broadcast

• shred.rs entries_to_data_shreds shreds are signed. Same in entries_to_coding_shreds

• shreds are verified by the validator before retransmit

• shreds that fail the leaders shred signature check are marked for discard. Retransmit is skipped. Currently handled by recv_window in window_service

• repair requests are signed and verified

• signed in ledger/src/shred.rs in entries_to_data_shreds and entries_to_coding_shreds

• repaired shreds are verified

• TVU receives the repair responses and they are pushed to the ShredSigVerifier before the retransmit stage.

BankHash

• all modified accounts are merkle hashed into the bank hash

• accounts.rs bank_hash_info_at is the hash of all the accounts committed for the slot. It’s scans the account storage for all the AppendVecs for the slot and computes the commit merkle. Bank’s hash_internal_state function picks up that value when the bank is frozen, and its stored in bank.hash. All votes contain bank.hash

Snapshots

• full account set and all the bank specific state is signed for the snapshot, mostly tracking in [Draft] snapshot bank fields protection #8185

tag: @mvines @garious

[ryoqun]

• ... bank specific state is signed for the snapshot

@aeyakovenko This is not fully currently implemented: #8185 I havn't gotten hands on it due to imminent snapshot issues.

[aeyakovenko]

@garious Seems like we should have a cryptography security doc in the design that goes over all the signatures and how they are used.

[ryoqun]

Sorry a bit late; but I've just came up with; I know these are pretty obvious and may overlap with existing check points, but just in case

These are what I'd would peek into if I'd determined to steal million SOLs ever. ;)

Genesis hash

• Is genesis hash is really chained to the actual corresponding ledger?

Poh

• Is Poh hash is really changed according to inserted TX signatures?
• When inserting, there should be no bogus TXes?
• When validating in parallel with GPU, swapping entries causes verification error? I mean, the entire PoH linkage/integrity is ensured?

TX

• Sighed TXs becomes invalid with tampered recent_blockhash?

Hashing/Signature coverage

The hashing and signing covers the following data structures exactly with no less and no more? When extra data is prepended/appended by tampering from an untrusted stream, it rejects the extra outright?

• TX
• GenesisConfig
• Shred
• Account data (only hashing applies)

[ryoqun]

• Also, is our depending crypto crates are working correctly at the currently-depended version? Is its results checked against other impls like OpenSSL, NaCL? And Cargo.lock can detect and loudly reject to build further if encountered bad crate hash?

[ryoqun]

• Also, our release tarball is signed by the offline keypair somehow or is it a reproducible build?

[ryoqun]

• ... And Cargo.lock can detect and loudly reject to build further if encountered bad crate hash?

• Also, our release tarball is signed by the offline keypair somehow or is it a reproducible build?

I'm slowly moving this by way of #9180.

[ryoqun]

related: https://medium.com/chorus-one/reisen-hood-prince-of-crypto-thieves-72e3bb5866d1

also: #10431

[ryoqun]

firstly, i audited those versioned tx mechanism. it seems it's correctly sanitizing/sig-verifying/pre-compiling things for both banking /replaying codepath.