[lsd0003] branch master updated: Fixed one more

[gnunet]

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 4a1f977  Fixed one more
4a1f977 is described below

commit 4a1f9772d43554a6402791222fc1bc574a6dad28
Author: Elias Summermatter <elias.summermatter@seccom.ch>
AuthorDate: Tue Jun 15 20:51:13 2021 +0200

    Fixed one more
---
 draft-summermatter-set-union.xml | 39 +++++++++++++--------------------------
 1 file changed, 13 insertions(+), 26 deletions(-)

diff --git a/draft-summermatter-set-union.xml b/draft-summermatter-set-union.xml
index 1643a7b..21e7c3c 100644
--- a/draft-summermatter-set-union.xml
+++ b/draft-summermatter-set-union.xml
@@ -406,7 +406,7 @@ hashSum |   HASHSUM   |   HASHSUM   |   HASHSUM   |    
HASHSUM  |  H..
 # OUTPUT:
 # value: salted key
 FUNCTION salt_key(key,ibf_salt):
-  s = ibf_salt % 64;
+  s = (ibf_salt * 7) modulo 64;
   /* rotate key */
   return (key >> s) | (key << (64 - s))
 
@@ -2852,10 +2852,6 @@ END FUNCTION
                         message, it is important to check that
                         not fewer elements have been received than the other 
peer has committed to
                         send at the beginning of the operation.
-                        <!-- FIXME: I don't see how the next sentence makes 
sense. If we got a FULL_DONE,
-                             and we still have differing sets, something is 
broken and re-doing it hardly
-                             makes sense, right? -->
-
                         If the sets differ (the FINAL CHECKSUM field in the 
<xref target="messages_full_done" format="title" />
                         message does not match to the sha-512 hash in our 
set), the operation has failed. This is a strong indicator
                         that something went wrong (eg. some hardware bug), 
this should never occur!
@@ -2908,20 +2904,18 @@ END FUNCTION
                     generating and transmitting an unlimited number of IBFs 
that all do not decode, or
                     to generate an IBF constructed to send the peers in an 
endless loop.
                     To prevent an endless loop in decoding, loop detection 
MUST be implemented.
-                    The first solution is to prevent decoding of more than a 
given number of elements.
-                    <!-- FIXME: this description is awkward. Needs to be 
discussed.
-                         I think you also do not mean 'hashes' but 'element 
IDs'. @Christian just omit the details
-                         i guess anybody can freely decide how to handle loops 
its just important that e protection is
-                         in place. Right?
-                         - Remove salt and save this in the hashmap
-                         - vorher gespreichert.
-                         - Beides machen
-                         - Nie mehr als MIN(anzahl buckets,total set grössen)
-                         -->
-                    A more robust solution is to implement an algorithm that 
detects a loop by
-                    analyzing past partially decoded IBFs. This can be achieved
-                    by saving the element IDs of all prior partly decoded IBFs 
element IDs in a hashmap and check
-                    for every inserted element ID, if it is already in the 
hashmap.
+                    A solution to prevent endless loop is to limit the number 
of elements decoded from an IBF.
+                    This limit is defined by the number of buckets in the IBF. 
It is not possible that more elements are decoded
+                    from an IBF than an IBF has buckets. If more elements than 
buckets are in an IBF it is not possible to
+                    get pure buckets.
+                    An additional check that should be implemented, is to 
store all element IDs
+                    that were prior decoded. When a new element ID is decoded 
from the IBF it should
+                    always be checked that no element ID is repeated.
+                    If the same element ID is decoded more than once, this is 
a strong indication
+                    for an invalid IBF and the operation MUST be aborted. 
Notice that the decoded
+                    element IDs are salted as described in <xref 
target="ibf_format_id_generation_pseudo_code" format="default" />
+                    so the described bit rotation needs to be reverted before 
the decoded element ID
+                    is stored and compared to the previous decoded element IDs.
                 </t>
                 <t>
                     If the IBF decodes more elements than are plausible, the
@@ -2934,8 +2928,6 @@ END FUNCTION
                     between the local and remote set size (Case the set 
difference is only in the set of
                     a single peer). The other peer's committed set sizes
                     is transmitted in the the <strong>Expecting IBF</strong> 
state.
-                    <!-- FIXME: be more precise about how to calculate those
-                         bounds from those inputs.  @Christan better? -->
                 </t>
 
                 <t>Security considerations for received messages:</t>
@@ -2984,7 +2976,6 @@ END FUNCTION
                             If the sets differ (the FINAL CHECKSUM field in 
the <xref target="messages_done" format="title" />
                             message does not match to the sha-512 hash in our 
set), the operation has failed. This is a strong indicator
                             that something went wrong (eg. some hardware bug), 
this should never occur!
-                            <!-- FIXME: again, how can this happen? Why should 
we really allow this? @Christian same point above if set changes while we 
synchronize-->
                         </t>
                         <t>
                             When a <em><xref target="messages_done" 
format="title" /></em> message is received the
@@ -3056,10 +3047,6 @@ END FUNCTION
                             elements received matches the number that the 
remote peer
                             originally committed to transmitting,
                             otherwise the operation MUST be terminated.
-                            <!-- FIXME: this is redundant, already covered by 
the new state, right? @Christian: ??? State-->
-                            After receiving the
-                            <em><xref target="messages_full_done" 
format="title" /></em> message, future elements MUST NOT be accepted.
-                            <!-- FIXME: again, how can this happen? Why should 
we really allow this?-->
                             If the sets differ (the FINAL CHECKSUM field in 
the <xref target="messages_full_done" format="title" />
                             message does not match to the sha-512 hash in our 
set), the operation has failed. This is a strong indicator
                             that something went wrong (eg. some hardware bug), 
this should never occur!

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