diff options
Diffstat (limited to 'draft-summermatter-set-union.xml')
-rw-r--r-- | draft-summermatter-set-union.xml | 39 |
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 |
408 | FUNCTION salt_key(key,ibf_salt): | 408 | FUNCTION 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! |