zecfoundation
/
reddsa
mirror of https://github.com/ZcashFoundation/reddsa.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

add missing checks 

Co-authored-by: teor <teor@riseup.net>
This commit is contained in:
Alfredo Garcia 2021-06-01 09:30:53 -03:00 committed by Deirdre Connolly
parent c0688b0fe4
commit 00190de7c6
1 changed files with 6 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
rfcs/0001-messages.md
View File

@ -261,12 +261,14 @@ The following rules must be implemented:
- Each jubjub type must be validated during deserialization.
- `share_commitments`:
- Length must be less than or equal to `MAX_SIGNER_PARTICIPANT_ID`.
- Lenght must be at least `MIN_SIGNERS` (`2` signers).
- Length must be at least `MIN_SIGNERS` (`2` signers).
- Duplicate `ParticipantId`s are invalid. This is implicit in the use of `BTreeMap` during serialization, but must be checked during deserialization.
- Commitments must be serialized in ascending numeric `ParticipantId` order. This is the order of `BTreeMap.iter` during serialization, but must be checked during deserialization.
- `signing_commitments`:
- Length must be less than or equal to `MAX_SIGNER_PARTICIPANT_ID`.
- Signing packages that contain duplicate `ParticipantId`s are invalid. This is implicit in the use of `BTreeMap`.
- Signing packages must serialize in ascending numeric `ParticipantId` order. This is the order of `BTreeMap.iter`.
- Length must be at least `MIN_THRESHOLD` (`2` required signers).
- Signing packages that contain duplicate `ParticipantId`s are invalid. This is implicit in the use of `BTreeMap` during serialization, but must be checked during deserialization.
- Signing packages must serialize in ascending numeric `ParticipantId` order. This is the order of `BTreeMap.iter` during serialization, but must be checked during deserialization..
- `message`: signed messages have a protocol-specific length limit. For Zcash, that limit is the maximum network protocol message length: `2^21` bytes (2 MB).
## Serialization/Deserialization
@ -377,6 +379,7 @@ The following are a few things this RFC is not considering:
- This is particularly important for `SigningPackage`s, which only need a threshold of participants to continue.
- Messages larger than 4 GB are not supported on 32-bit platforms.
- Implementations should validate that message lengths are lower than a protocol-specific maximum length, then allocate message memory.
- Implementations should distinguish between FROST messages from different signature schemes using implementation-specific mechanisms.
### State-Based Validation