From 00190de7c6d2da99a4b1fc8e31a22dcd8e290535 Mon Sep 17 00:00:00 2001 From: Alfredo Garcia Date: Tue, 1 Jun 2021 09:30:53 -0300 Subject: [PATCH] add missing checks Co-authored-by: teor --- rfcs/0001-messages.md | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/rfcs/0001-messages.md b/rfcs/0001-messages.md index 5c9c441e..d130451b 100644 --- a/rfcs/0001-messages.md +++ b/rfcs/0001-messages.md @@ -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