gnunet-svn
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lsd0003] branch master updated: Added more pseudocode


From: gnunet
Subject: [lsd0003] branch master updated: Added more pseudocode
Date: Mon, 15 Mar 2021 12:10:02 +0100

This is an automated email from the git hooks/post-receive script.

elias-summermatter pushed a commit to branch master
in repository lsd0003.

The following commit(s) were added to refs/heads/master by this push:
     new 38a4beb  Added more pseudocode
38a4beb is described below

commit 38a4bebe86570c1ec5f179f7e3bc1979a7048ece
Author: Elias Summermatter <elias.summermatter@seccom.ch>
AuthorDate: Mon Mar 15 12:08:19 2021 +0100

    Added more pseudocode
---
 draft-summermatter-set-union.xml | 134 ++++++++++++++++++++++++++++++++-------
 1 file changed, 110 insertions(+), 24 deletions(-)

diff --git a/draft-summermatter-set-union.xml b/draft-summermatter-set-union.xml
index 2f778ce..54e64be 100644
--- a/draft-summermatter-set-union.xml
+++ b/draft-summermatter-set-union.xml
@@ -2256,7 +2256,7 @@ FUNCTION validate_messages_full_element_init(client_id, 
remote_setsize, local_se
                         element is a valid element, no element is resized more 
than once and
                         not more or less elements are received as the other 
peer has committed
                         to in the beginning of the operation. Detail 
pseudocode implementation
-                        can be found in <xref 
target="security_states_expecting_ibf" format="title" />
+                        can be found in <xref 
target="security_states_expecting_ibf" format="title" />.
                         <!-- IMPLEMENT: Is this check already implemented?-->
                         </t>
                     </dd>
@@ -2409,7 +2409,7 @@ FUNCTION 
validate_messages_elements(element_message,demand_msg_store)
                         <figure 
anchor="security_states_active_decoding_demand_code">
                             <artwork name="" type="" align="left" 
alt=""><![CDATA[
 FUNCTION validate_messages_demand(demand_message,offer_msg_store)
-    IF is_undefined(store)
+    IF is_undefined(demand_msg_store)
         demand_msg_store = createStore()
     ENDIF
 
@@ -2510,9 +2510,33 @@ FUNCTION validate_messages_done(messages_done, 
offer_msg_store, demand_msg_store
                             <!-- IMPLEMENT: Terminate if in check expect se 
state for a max size difference is exceeded -->
                         </t>
                         <t>
-                            In case of compressed strata estimators the 
decompression algorithm has to
+                            In case of compressed strata estimators the 
decompression algorithm needs to
                             be protected against decompression memory 
corruption (memory overflow).
                         </t>
+                        <figure anchor="security_states_expect_se_se_code">
+                            <artwork name="" type="" align="left" 
alt=""><![CDATA[
+FUNCTION validate_messages_se(message_se, remote_setsize, local_setsize)
+
+    # Check that se decoded successfully if not return -1
+    set_diff = decode_se(message_se)
+    IF set_diff < 0
+        return FALSE
+    ENDIF
+
+    # Check that set difference cant be larger than local + remote setsize
+    IF set_diff > (remote_setsize + local_setsize)
+        return FALSE
+    ENDIF
+
+    # Check for max plausible set size as defined on use case basis (can be 
infinite)
+    plausible_setsize = getMaxPlausibleSetSize()
+    IF set_diff > plausible_setsize
+        return FALSE
+    ENDIF
+
+    return TRUE
+                                     ]]></artwork>
+                        </figure>
                     </dd>
                 </dl>
             </section>
@@ -2522,22 +2546,32 @@ FUNCTION validate_messages_done(messages_done, 
offer_msg_store, demand_msg_store
                 <dl>
                     <dt><xref target="messages_full_element" format="title" 
/></dt>
                     <dd>
-                        The peer in <strong>Full Receiving</strong> state 
needs to check
-                        that exactly the number of elements is received from 
the remote peer as
-                        he initially committed too. If the remote peer 
transmits less or
-                        more elements the operation MUST be terminated.
+                        <t>
+                            The peer in <strong>Full Receiving</strong> state 
needs to check
+                            that exactly the number of elements is received 
from the remote peer as
+                            he initially committed too. If the remote peer 
transmits less or
+                            more elements the operation MUST be terminated.
+                        </t>
+                        <t>
+                            Pseudocode for implementation described in section 
<xref target="security_states_expecting_ibf" format="title" />.
+                        </t>
                     </dd>
                     <dt><xref target="messages_full_done" format="title" 
/></dt>
                     <dd>
-                        When the full done message is received from the remote 
peer all
-                        elements that the remote peer has committed to needs 
to be received
-                        otherwise the operation MUST be terminated. After 
receiving the
-                        full done message no future elements should be 
accepted.
-                        <!-- FIXME: Check that after full done in full 
receiving no elements can be received anymore! Additional state? -->
-                        The 512-bit hash of the complete reconciled set 
contained in
-                        the full done message is required to ensures that both 
sets are truly identical. If
-                        the sets differ a resynchronisation is required. The 
count of possible
-                        resynchronisation MUST be limited to prevent resource 
exhaustion attacks.
+                        <t>
+                            When the full done message is received from the 
remote peer all
+                            elements that the remote peer has committed to 
needs to be received
+                            otherwise the operation MUST be terminated. After 
receiving the
+                            full done message no future elements should be 
accepted.
+                            <!-- FIXME: Check that after full done in full 
receiving no elements can be received anymore! Additional state? -->
+                            The 512-bit hash of the complete reconciled set 
contained in
+                            the full done message is required to ensures that 
both sets are truly identical. If
+                            the sets differ a resynchronisation is required. 
The count of possible
+                            resynchronisation MUST be limited to prevent 
resource exhaustion attacks.
+                        </t>
+                        <t>
+                            Pseudocode for implementation described in section 
<xref target="security_states_full_sending" format="title" />.
+                        </t>
                     </dd>
                 </dl>
             </section>
@@ -2547,17 +2581,47 @@ FUNCTION validate_messages_done(messages_done, 
offer_msg_store, demand_msg_store
                 <dl>
                     <dt><xref target="messages_ibf" format="title" /></dt>
                     <dd>
-                        In case an IBF message is received by the peer a 
active/passive role switch
-                        is initiated by the active decoding remote peer. In 
this instance the peer should
-                        wait for all open offers and demands to be fulfilled 
to prevent
-                        retransmission before switching into active decoding 
operation mode.
-                        A switch into active decoding mode should only be 
permitted for
-                        a predefined number of times as described in the top 
section
-                        of the security section.
-                        <!-- IMPLEMENT: What does happen here in the code? -->
+                        <t>
+                            In case an IBF message is received by the peer a 
active/passive role switch
+                            is initiated by the active decoding remote peer. 
In this instance the peer should
+                            wait for all open offers and demands to be 
fulfilled to prevent
+                            retransmission before switching into active 
decoding operation mode.
+                            A switch into active decoding mode should only be 
permitted for
+                            a predefined number of times as described in the 
top section
+                            of the security section.
+                            <!-- IMPLEMENT: What does happen here in the code? 
-->
+                        </t>
+                        <figure 
anchor="security_states_passive_decoding_ibf_code">
+                            <artwork name="" type="" align="left" 
alt=""><![CDATA[
+FUNCTION validate_messages_ibf(message_ibf, offer_msg_store, demand_msg_store, 
element_msg_store)
+
+    # Check that all offers have been received
+    IF ! isStoreComplete(offer_msg_store)
+        return FALSE
+    ENDIF
+
+    # Check that all demands have been received
+    IF ! isStoreComplete(demand_msg_store)
+        return FALSE
+    ENDIF
+
+    # Check that all elements have been received
+    IF ! isStoreComplete(element_msg_store)
+        return FALSE
+    ENDIF
+
+    # Check that not more active/passive switches are done as configured
+    IF getNumberRollSwitches() > getMaxNumberRollSwitches()
+        return FALSE
+    ENDIF
+
+    return TRUE
+                                     ]]></artwork>
+                        </figure>
                     </dd>
                     <dt><xref target="messages_inquiry" format="title" /></dt>
                     <dd>
+                        <t>
                         A check needs to be in place that prevents receiving a 
inquiry
                         for an element multiple times or more inquiries than 
are plausible.
                         The amount of inquiries that is plausible can be 
estimated by considering
@@ -2566,6 +2630,28 @@ FUNCTION validate_messages_done(messages_done, 
offer_msg_store, demand_msg_store
                         by real world limitations.
                         To implement this restrictions a list with all 
received inquiries
                         should be stored and new inquiries should be checked 
against.
+                        </t>
+                        <figure 
anchor="security_states_passive_decoding_inquiry_code">
+                            <artwork name="" type="" align="left" 
alt=""><![CDATA[
+FUNCTION validate_messages_inquiry(inquiry_message, set_diff)
+
+    IF is_undefined(inquiry_msg_store)
+        inquiry_msg_store = createStore()
+    ENDIF
+
+    # Store message to prevent double sending of messages
+    IF ! addMessageToStore(inquiry_msg_store, inquiry_message)
+        return FALSE
+    ENDIF
+
+    # Check that not more inquiries are received as estimated
+    IF set_diff < getNumberOfMessage(inquiry_msg_store)
+        return FALSE
+    ENDIF
+
+    return TRUE
+                                     ]]></artwork>
+                        </figure>
                     </dd>
                     <dt><xref target="messages_demand" format="title" /></dt>
                     <dd>

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]