aboutsummaryrefslogtreecommitdiff
path: root/draft-summermatter-set-union.xml
diff options
context:
space:
mode:
Diffstat (limited to 'draft-summermatter-set-union.xml')
-rw-r--r--draft-summermatter-set-union.xml39
1 files 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..
406# OUTPUT: 406# OUTPUT:
407# value: salted key 407# value: salted key
408FUNCTION salt_key(key,ibf_salt): 408FUNCTION salt_key(key,ibf_salt):
409 s = ibf_salt % 64; 409 s = (ibf_salt * 7) modulo 64;
410 /* rotate key */ 410 /* rotate key */
411 return (key >> s) | (key << (64 - s)) 411 return (key >> s) | (key << (64 - s))
412 412
@@ -2852,10 +2852,6 @@ END FUNCTION
2852 message, it is important to check that 2852 message, it is important to check that
2853 not fewer elements have been received than the other peer has committed to 2853 not fewer elements have been received than the other peer has committed to
2854 send at the beginning of the operation. 2854 send at the beginning of the operation.
2855 <!-- FIXME: I don't see how the next sentence makes sense. If we got a FULL_DONE,
2856 and we still have differing sets, something is broken and re-doing it hardly
2857 makes sense, right? -->
2858
2859 If the sets differ (the FINAL CHECKSUM field in the <xref target="messages_full_done" format="title" /> 2855 If the sets differ (the FINAL CHECKSUM field in the <xref target="messages_full_done" format="title" />
2860 message does not match to the sha-512 hash in our set), the operation has failed. This is a strong indicator 2856 message does not match to the sha-512 hash in our set), the operation has failed. This is a strong indicator
2861 that something went wrong (eg. some hardware bug), this should never occur! 2857 that something went wrong (eg. some hardware bug), this should never occur!
@@ -2908,20 +2904,18 @@ END FUNCTION
2908 generating and transmitting an unlimited number of IBFs that all do not decode, or 2904 generating and transmitting an unlimited number of IBFs that all do not decode, or
2909 to generate an IBF constructed to send the peers in an endless loop. 2905 to generate an IBF constructed to send the peers in an endless loop.
2910 To prevent an endless loop in decoding, loop detection MUST be implemented. 2906 To prevent an endless loop in decoding, loop detection MUST be implemented.
2911 The first solution is to prevent decoding of more than a given number of elements. 2907 A solution to prevent endless loop is to limit the number of elements decoded from an IBF.
2912 <!-- FIXME: this description is awkward. Needs to be discussed. 2908 This limit is defined by the number of buckets in the IBF. It is not possible that more elements are decoded
2913 I think you also do not mean 'hashes' but 'element IDs'. @Christian just omit the details 2909 from an IBF than an IBF has buckets. If more elements than buckets are in an IBF it is not possible to
2914 i guess anybody can freely decide how to handle loops its just important that e protection is 2910 get pure buckets.
2915 in place. Right? 2911 An additional check that should be implemented, is to store all element IDs
2916 - Remove salt and save this in the hashmap 2912 that were prior decoded. When a new element ID is decoded from the IBF it should
2917 - vorher gespreichert. 2913 always be checked that no element ID is repeated.
2918 - Beides machen 2914 If the same element ID is decoded more than once, this is a strong indication
2919 - Nie mehr als MIN(anzahl buckets,total set grössen) 2915 for an invalid IBF and the operation MUST be aborted. Notice that the decoded
2920 --> 2916 element IDs are salted as described in <xref target="ibf_format_id_generation_pseudo_code" format="default" />
2921 A more robust solution is to implement an algorithm that detects a loop by 2917 so the described bit rotation needs to be reverted before the decoded element ID
2922 analyzing past partially decoded IBFs. This can be achieved 2918 is stored and compared to the previous decoded element IDs.
2923 by saving the element IDs of all prior partly decoded IBFs element IDs in a hashmap and check
2924 for every inserted element ID, if it is already in the hashmap.
2925 </t> 2919 </t>
2926 <t> 2920 <t>
2927 If the IBF decodes more elements than are plausible, the 2921 If the IBF decodes more elements than are plausible, the
@@ -2934,8 +2928,6 @@ END FUNCTION
2934 between the local and remote set size (Case the set difference is only in the set of 2928 between the local and remote set size (Case the set difference is only in the set of
2935 a single peer). The other peer's committed set sizes 2929 a single peer). The other peer's committed set sizes
2936 is transmitted in the the <strong>Expecting IBF</strong> state. 2930 is transmitted in the the <strong>Expecting IBF</strong> state.
2937 <!-- FIXME: be more precise about how to calculate those
2938 bounds from those inputs. @Christan better? -->
2939 </t> 2931 </t>
2940 2932
2941 <t>Security considerations for received messages:</t> 2933 <t>Security considerations for received messages:</t>
@@ -2984,7 +2976,6 @@ END FUNCTION
2984 If the sets differ (the FINAL CHECKSUM field in the <xref target="messages_done" format="title" /> 2976 If the sets differ (the FINAL CHECKSUM field in the <xref target="messages_done" format="title" />
2985 message does not match to the sha-512 hash in our set), the operation has failed. This is a strong indicator 2977 message does not match to the sha-512 hash in our set), the operation has failed. This is a strong indicator
2986 that something went wrong (eg. some hardware bug), this should never occur! 2978 that something went wrong (eg. some hardware bug), this should never occur!
2987 <!-- FIXME: again, how can this happen? Why should we really allow this? @Christian same point above if set changes while we synchronize-->
2988 </t> 2979 </t>
2989 <t> 2980 <t>
2990 When a <em><xref target="messages_done" format="title" /></em> message is received the 2981 When a <em><xref target="messages_done" format="title" /></em> message is received the
@@ -3056,10 +3047,6 @@ END FUNCTION
3056 elements received matches the number that the remote peer 3047 elements received matches the number that the remote peer
3057 originally committed to transmitting, 3048 originally committed to transmitting,
3058 otherwise the operation MUST be terminated. 3049 otherwise the operation MUST be terminated.
3059 <!-- FIXME: this is redundant, already covered by the new state, right? @Christian: ??? State-->
3060 After receiving the
3061 <em><xref target="messages_full_done" format="title" /></em> message, future elements MUST NOT be accepted.
3062 <!-- FIXME: again, how can this happen? Why should we really allow this?-->
3063 If the sets differ (the FINAL CHECKSUM field in the <xref target="messages_full_done" format="title" /> 3050 If the sets differ (the FINAL CHECKSUM field in the <xref target="messages_full_done" format="title" />
3064 message does not match to the sha-512 hash in our set), the operation has failed. This is a strong indicator 3051 message does not match to the sha-512 hash in our set), the operation has failed. This is a strong indicator
3065 that something went wrong (eg. some hardware bug), this should never occur! 3052 that something went wrong (eg. some hardware bug), this should never occur!