Skip to content

Commit

Permalink
ARC-81 rationale/test case/security
Browse files Browse the repository at this point in the history
  • Loading branch information
Tasos Bitsios committed Dec 16, 2024
1 parent 8de886c commit 3605662
Showing 1 changed file with 22 additions and 9 deletions.
31 changes: 22 additions & 9 deletions ARCs/arc-0081.md
Original file line number Diff line number Diff line change
Expand Up @@ -16,7 +16,7 @@ This ARC proposes a hashing identifier for checking the integrity of a set of co

## Motivation

Participation key material can be inadvertently mutated between their generation on a participating node and the wallet where the key registration transaction is signed. Currently, the only way for a node runner to be diligent about signing key registration transactions is to individually verify 176 base64 characters across 3 key fields, as well as the 3 numeric fields for validity and key dillution.
Participation key material can be inadvertently mutated between their generation on a participating node and the wallet where the key registration transaction is signed. Currently, the only way for a node runner to be diligent about signing key registration transactions is to individually verify 176 base64 characters across 3 key fields, as well as the 3 numeric fields for validity and key dilution.

An online keyreg transaction with incorrect partkey material can succeed, which would render the participating account silently delinquent: their registered participation keys would not correspond to the actual keypairs on the node.

Expand All @@ -39,27 +39,40 @@ The integrity hash is a shortened version of a SHA512_256 hash of the concatenat
- Note: this MUST NOT be omitted. When the first valid voting round is zero, an explicit uint64 zero value is expected.
- Implementation warning: this field can be missing in msgpack encoded keyreg transactions due to the `omitempty` behavior.
- last valid voting round (encoded as uint64, length: 8 bytes)
- key dillution (encoded as uint64, length: 8 bytes)
- key dilution (encoded as uint64, length: 8 bytes)
- its length MUST be exactly 184 bytes
- `sha512_256` refers to the SHA512_256 hashing function
- `subsstr(x, 0, 8)` refers to the "substring" function, i.e. returning the first 8 bytes of value `x`
- `base32_nopad` refers to the RFC 4648 base32 encoding function, but omitting the padding suffix characters (`=`)
- `substr(x, 0, 8)` refers to the "substring" function, i.e. returning the first 8 bytes of value `x`
- `base32_nopad` refers to the RFC 4648 base32 encoding function, without padding characters

## Rationale

TODO
- The key material to be hashed was chosen to uniquely identify the participation key
- SHA512_256 was chosen for its widespread availability alongside Algorand SDKs
- A truncated hash was chosen over using the full 32 bytes in order to improve the experience of comparing a hash exhaustively. In base32, 8 bytes encode to a 13-character string, vs. 32 bytes encoding to 52 characters.
- This choice was made while acknowledging that truncating the hash weakens its cryptographic strength significantly. This identifier is meant to be used as an error-detection checksum, not a cryptographically strong guarantee.

## Test Cases
## Test Case

Check failure on line 55 in ARCs/arc-0081.md

View workflow job for this annotation

GitHub Actions / ARC Walidator

body has extra section(s)

error[markdown-order-section]: body has extra section(s) --> ARCs/arc-0081.md | 55 | ## Test Case |

TODO
Participation key:

Account: OHQTAISSIGRGIGVN6TVJ6WYLBHFTUC437T4E2LRRXGWVNJ4GSZOXKPH7N4
Selection Key: e4kBLu7zXOorjLVzJHOiAn+IhOBsYBCqqHKaJCiCdJs=
Vote Key: WWHePYtNZ2T3sHkqdd/38EvoFWrnIKPrTo6xN/4T1l4=
State Proof Key: 1GdNPOck+t6yXvuXxrDEPKqgi4I2sTaNugV1kd5ksUW2G1U6x1FT0WR3aT3ZSSmbYoDt3cVrB3vIPJA8GkqSYg==
Vote First Valid: 3118965
Vote Last Valid: 4104516
Key Dilution: 993

Resulting integrity hash: JUKBSNRYTU4PU

## Reference Implementation

TODO
A reference implementation in Typescript is provided [here](../assets/arc-0081/src/index.ts).

## Security Considerations

TODO
The hash truncation involved in generating the integrity hash sacrifices cryptographic strength for ease of verification. It should not be considered a cryptographically strong identifier, but an error-detection checksum method.

## Copyright

Expand Down

0 comments on commit 3605662

Please sign in to comment.