[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0003] branch master updated: Fixed some stuff
|
From: |
gnunet |
|
Subject: |
[lsd0003] branch master updated: Fixed some stuff |
|
Date: |
Sat, 23 Jan 2021 13:36:45 +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 90c4bf1 Fixed some stuff
90c4bf1 is described below
commit 90c4bf1f53a952919f814d1d1b6307db0e357611
Author: Elias Summermatter <elias.summermatter@seccom.ch>
AuthorDate: Sat Jan 23 13:35:51 2021 +0100
Fixed some stuff
---
draft-summermatter-set-union.xml | 324 ++++++++++++++++++++++++++-------------
1 file changed, 221 insertions(+), 103 deletions(-)
diff --git a/draft-summermatter-set-union.xml b/draft-summermatter-set-union.xml
index 1eb7a0d..8e30e09 100644
--- a/draft-summermatter-set-union.xml
+++ b/draft-summermatter-set-union.xml
@@ -81,7 +81,7 @@
Our primary envisioned application domain is the
distribution of revocation messages in the GNU Name
- System (GNS) <!-- TODO: citate:
https://git.gnunet.org/bibliography.git/plain/docs/gns2014wachs.pdf -->. In GNS,
+ System (GNS) <xref target="GNUNET" format="default" />. In GNS,
key revocation messages are usually flooded across the
peer-to-peer overlay network to all connected peers
whenever a key is revoked. However, as peers may be
@@ -96,8 +96,8 @@
in this specification are Byzantine fault-tolerant
bulletin boards, like those required in some secure
multiparty computations. A well-known example for
- secure multiparty computations are <!-- TODO: citate:
https://git.gnunet.org/bibliography.git/plain/docs/ba_dold_voting_24aug2014.pdf
--> various E-voting
- protocols which
+ secure multiparty computations are various E-voting
+ protocols <xref target="CryptographicallySecureVoting"
format="default"/> which
use a bulletin board to share the votes and intermediate
computational results. We note that for such systems,
the set reconciliation protocol is merely a component of
@@ -125,7 +125,7 @@
is one major choice to be made, which is between sending the
full set of elements, or just sending the elements that differ.
In the latter case, our design is basically a concrete
- implementation of a proposal by Eppstein. <!-- TODO: citate:
https://www.ics.uci.edu/~eppstein/pubs/EppGooUye-SIGCOMM-11.pdf -->
+ implementation of a proposal by Eppstein.<xref target="Eppstein"
format="default" />
</t>
<t>
@@ -382,9 +382,9 @@ hashSum | HASHSUM | HASHSUM | HASHSUM |
HASHSUM | H..
+-------------+-------------+-------------+-------------+
count | 0 | 0 | 0 | 0 |
+-------------+-------------+-------------+-------------+
- idSum | 0000 | 0000 | 0000 | 0000 |
+ idSum | 0x0000 | 0x0000 | 0x0000 | 0x0000 |
+-------------+-------------+-------------+-------------+
-hashSum | 0000 | 0000 | 0000 | 0000 |
+hashSum | 0x0000 | 0x0000 | 0x0000 | 0x0000 |
+-------------+-------------+-------------+-------------+
]]></artwork>
</figure>
@@ -395,9 +395,9 @@ hashSum | 0000 | 0000 | 0000 |
0000 |
+-------------+-------------+-------------+-------------+
count | 0 | 1 | 0 | 1 |
+-------------+-------------+-------------+-------------+
- idSum | 0000 | 0x0102 | 0000 | 0x0102 |
+ idSum | 0x0000 | 0x0102 | 0x0000 | 0x0102 |
+-------------+-------------+-------------+-------------+
-hashSum | 0000 | 0x4242 | 0000 | 0x4242 |
+hashSum | 0x0000 | 0x4242 | 0x0000 | 0x4242 |
+-------------+-------------+-------------+-------------+
]]></artwork>
</figure>
@@ -408,9 +408,9 @@ hashSum | 0000 | 0x4242 | 0000 |
0x4242 |
+-------------+-------------+-------------+-------------+
count | 1 | 2 | 0 | 1 |
+-------------+-------------+-------------+-------------+
- idSum | 0x0304 | 0x0206 | 0000 | 0x0102 |
+ idSum | 0x0304 | 0x0206 | 0x0000 | 0x0102 |
+-------------+-------------+-------------+-------------+
-hashSum | 0101 | 0x4343 | 0000 | 0x4242 |
+hashSum | 0x0101 | 0x4343 | 0x0000 | 0x4242 |
+-------------+-------------+-------------+-------------+
]]></artwork>
</figure>
@@ -433,9 +433,9 @@ hashSum | 0101 | 0x4343 | 0000 |
0x4242 |
+-------------+-------------+-------------+-------------+
count | 1 | 2 | 0 | 1 |
+-------------+-------------+-------------+-------------+
- idSum | 0x0304 | 0x0206 | 0000 | 0x0102 |
+ idSum | 0x0304 | 0x0206 | 0x0000 | 0x0102 |
+-------------+-------------+-------------+-------------+
-hashSum | 0x0101 | 0x4343 | 0000 | 0x4242 |
+hashSum | 0x0101 | 0x4343 | 0x0000 | 0x4242 |
+-------------+-------------+-------------+-------------+
]]></artwork>
</figure>
@@ -446,9 +446,9 @@ hashSum | 0x0101 | 0x4343 | 0000 |
0x4242 |
+-------------+-------------+-------------+-------------+
count | 0 | 1 | 0 | 1 |
+-------------+-------------+-------------+-------------+
- idSum | 0000 | 0x0102 | 0000 | 0x0102 |
+ idSum | 0x0000 | 0x0102 | 0x0000 | 0x0102 |
+-------------+-------------+-------------+-------------+
-hashSum | 0000 | 0x4242 | 0000 | 0x4242 |
+hashSum | 0x0000 | 0x4242 | 0x0000 | 0x4242 |
+-------------+-------------+-------------+-------------+
]]></artwork>
</figure>
@@ -530,9 +530,9 @@ hashSum | 0000 | 0x4242 | 0000 |
0x4242 |
+-------------+-------------+-------------+-------------+
count | 1 | 2 | 0 | 1 |
+-------------+-------------+-------------+-------------+
- idSum | 0x0304 | 0x0206 | 0000 | 0x0102 |
+ idSum | 0x0304 | 0x0206 | 0x0000 | 0x0102 |
+-------------+-------------+-------------+-------------+
-hashSum | 0x0101 | 0x4343 | 0000 | 0x4242 |
+hashSum | 0x0101 | 0x4343 | 0x0000 | 0x4242 |
+-------------+-------------+-------------+-------------+
]]></artwork>
</figure>
@@ -546,9 +546,9 @@ hashSum | 0x0101 | 0x4343 | 0000 |
0x4242 |
+-------------+-------------+-------------+-------------+
count | 0 | 1 | 0 | 1 |
+-------------+-------------+-------------+-------------+
- idSum | 0000 | 0x0102 | 0000 | 0x0102 |
+ idSum | 0x0000 | 0x0102 | 0x0000 | 0x0102 |
+-------------+-------------+-------------+-------------+
-hashSum | 0000 | 0x4242 | 0000 | 0x4242 |
+hashSum | 0x0000 | 0x4242 | 0x0000 | 0x4242 |
+-------------+-------------+-------------+-------------+
]]></artwork>
</figure>
@@ -563,9 +563,9 @@ hashSum | 0000 | 0x4242 | 0000 |
0x4242 |
+-------------+-------------+-------------+-------------+
count | 0 | 0 | 0 | 0 |
+-------------+-------------+-------------+-------------+
- idSum | 0000 | 0000 | 0000 | 0000 |
+ idSum | 0x0000 | 0x0000 | 0x0000 | 0x0000 |
+-------------+-------------+-------------+-------------+
-hashSum | 0000 | 0000 | 0000 | 0000 |
+hashSum | 0x0000 | 0x0000 | 0x0000 | 0x0000 |
+-------------+-------------+-------------+-------------+
]]></artwork>
</figure>
@@ -603,9 +603,9 @@ hashSum | 0000 | 0000 | 0000 |
0000 |
+-------------+-------------+-------------+-------------+
count | 1 | 2 | 0 | 1 |
+-------------+-------------+-------------+-------------+
- idSum | 0x0304 | 0x0206 | 0000 | 0x0102 |
+ idSum | 0x0304 | 0x0206 | 0x0000 | 0x0102 |
+-------------+-------------+-------------+-------------+
-hashSum | 0x0101 | 0x4343 | 0x0000 | 0x4242 |
+hashSum | 0x0101 | 0x4343 | 0x0000 | 0x4242 |
+-------------+-------------+-------------+-------------+
]]></artwork>
</figure>
@@ -616,9 +616,9 @@ hashSum | 0x0101 | 0x4343 | 0x0000 |
0x4242 |
+-------------+-------------+-------------+-------------+
count | 0 | 1 | 1 | 1 |
+-------------+-------------+-------------+-------------+
- idSum | 0000 | 0x0102 | 0x1345 | 0x0102 |
+ idSum | 0x0000 | 0x0102 | 0x1345 | 0x0102 |
+-------------+-------------+-------------+-------------+
-hashSum | 0000 | 0x4242 | 0x5050 | 0x4242 |
+hashSum | 0x0000 | 0x4242 | 0x5050 | 0x4242 |
+-------------+-------------+-------------+-------------+
]]></artwork>
</figure>
@@ -629,9 +629,9 @@ hashSum | 0000 | 0x4242 | 0x5050 |
0x4242 |
+-------------+-------------+-------------+-------------+
count | 1 | 1 | -1 | 0 |
+-------------+-------------+-------------+-------------+
- idSum | 0000 | 0x0304 | 0x1345 | 0000 |
+ idSum | 0x0304 | 0x0304 | 0x1345 | 0x0000 |
+-------------+-------------+-------------+-------------+
-hashSum | 0x0101 | 0x0101 | 0x5050 | 0000 |
+hashSum | 0x0101 | 0x0101 | 0x5050 | 0x0000 |
+-------------+-------------+-------------+-------------+
]]></artwork>
</figure>
@@ -641,7 +641,6 @@ hashSum | 0x0101 | 0x0101 | 0x5050 |
0000 |
removed by the set difference operation (bit-4).
</t>
</section>
-
</section>
<section anchor="ibf_format" numbered="true" toc="default">
@@ -691,8 +690,117 @@ hashSum | 0x0101 | 0x0101 | 0x5050 |
0000 |
also again a reasonable size for many CPU
architectures.
</t>
+ <section anchor="ibf_format_id_generation" numbered="true"
toc="default">
+ <name>ID Calculation</name>
+ <t>
+ The ID is generated as 64-bit output from a <relref
section="2" target="RFC5869" displayFormat="of">HKDF construction</relref>
+ with HMAC-SHA512 as XTR and HMAC-SHA256 as PRF and
salt is set to the unsigned 64-bit equivalent of 0.
+ The output is then truncated to 64-bit.
+ Its important that the elements can be redistributed
over the buckets in case the IBF does not
+ decode, that's why the ID is salted with a random salt
given in the SALT field of this message.
+ Salting is done by calculation the a random salt
modulo 64 (using only the lowest 6-bits of the salt)
+ and do a bitwise right rotation of output of KDF by
the 6-bit salts numeric representation.
+ </t>
+ <t>
+ Representation in pseudocode:
+ </t>
+ <figure anchor="ibf_format_id_generation_pseudo_code">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+# INPUTS:
+# key: Pre calculated and truncated key from id_calculation function
+# ibf_salt: Salt of the IBF
+# OUTPUT:
+# value: salted key
+FUNCTION salt_key(key,ibf_salt):
+ s = ibf_salt % 64;
+ k = key
+
+ /* rotate ibf key */
+ k = (k >> s) | (k << (64 - k))
+ return key
+
+
+# INPUTS:
+# element: Element to calculated id from.
+# salt: Salt of the IBF
+# OUTPUT:
+# value: the ID of the element
+
+FUNCTION id_calculation (element,ibf_salt):
+ salt = 0
+ XTR=HMAC-SHA256
+ PRF=HMAC-SHA256
+ key = HKDF(XTR, PRF, salt, element)
+ key = key modulo 2^64 // Truncate
+ return salt_key(key,ibf_salt)
+
+
+ ]]></artwork>
+ </figure>
+ </section>
+ <section anchor="ibf_format_bucket_identification"
numbered="true" toc="default">
+ <name>Mapping Function</name>
+ <t>
+ The mapping function M as described above in the
figure <xref target="bf_mapping_function_math" format="default" />
+ decides in which buckets the ID and HASH have to be
binary XORed to. In practice
+ there the following algorithm is used:
+ </t>
+ <t>
+ The first index is simply the HASH modulo the IBF
size. The second
+ index is calculated by creating a new 64-bit value by
shifting the 32-bit
+ value left and setting the lower 32-bit to the number
of indexes already processed. From the
+ resulting 64-bit value a CRC32 checksum is created the
second index is now the modulo of the
+ CRC32 output this is repeated until the predefined
amount indexes is generated.
+ In the case a index is hit twice, which would mean
this bucket could not get pure again,
+ the second hit is just skipped and the next iteration
is used as.
+ </t>
+ <figure
anchor="ibf_format_bucket_identification_pseudo_code">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+# INPUTS:
+# key: Is the ID of the element calculated in the id_calculation function
above.
+# number_of_buckets_per_element: Pre-defined count of buckets elements are
inserted into
+# ibf_size: the size of the ibf (count of buckets)
+# OUTPUT:
+# dst: Array with bucket IDs to insert ID and HASH
+
+FUNCTION get_bucket_id (key, number_of_buckets_per_element, ibf_size)
+ bucket = CRC32(key)
+
+ i = 0
+ filled = 0
+ WHILE filled < number_of_buckets_per_element
+
+ element_already_in_bucket = false
+ j = 0
+ WHILE j < filled
+ IF dst[j] == bucket modulo ibf_size THEN
+ element_already_in_bucket = true
+ ENDIF
+ j++
+ ENDWHILE
+
+ IF !element_already_in_bucket THEN
+ dst[filled++] = bucket modulo ibf_size
+ ENDIF
+
+ x = (bucket << 32) | i
+ bucket = CRC32(x)
+
+ i++
+ ENDWHILE
+ return dst
+ ]]></artwork>
+ </figure>
+ </section>
+ <section anchor="ibf_format_HASH_calculation" numbered="true"
toc="default">
+ <name>HASH calculation</name>
+ <t>
+ The HASH is calculated by calculating the CRC32
checksum of the 64-bit ID value
+ which returns a 32-bit value.
+ </t>
</section>
</section>
+ </section>
<section anchor="se" numbered="true" toc="default">
<name>Strata Estimator</name>
@@ -1056,7 +1164,6 @@ hashSum | 0x0101 | 0x0101 | 0x5050 |
0000 |
/ /
/ /
]]></artwork>
- <!-- <postamble>which is a very simple
example.</postamble>-->
</figure>
<t>where:</t>
<dl>
@@ -1121,7 +1228,6 @@ hashSum | 0x0101 | 0x0101 | 0x5050 |
0000 |
/ /
/ /
]]></artwork>
- <!-- <postamble>which is a very simple
example.</postamble>-->
</figure>
<t>where:</t>
<dl>
@@ -1161,67 +1267,17 @@ hashSum | 0x0101 | 0x0101 | 0x5050 |
0000 |
32768 divided by the BUCKET_SIZE which is
13-byte (104-bit).
</t>
<t>
- The ID is generated as 64-bit output form a
KDF (HMAC-SHA512 as XTR and HMAC-SHA256 as PRF,
- the output from SHA-512 is then truncated to
64 bits, salt of the KDF is always set to = 0).
- Its important that the elements can be
redistributed over the buckets in case the IBF does not
- decode, that's why the ID is salted with a
random salt given in the SALT field of this message.
- Salting is done by calculation the a random
salt modulo 64 (using only the lowest 6-bits of the salt)
- and do a bitwise right rotation of output of
KDF by the 6-bit salts numeric representation. To
- get the IDSUM field all IDs who hit a bucket
are added up with a binary XOR operation.
+ To get the IDSUM field, all IDs who hit a
bucket are added up with a binary XOR operation.
+ See <xref target="ibf_format_id_generation"
format="title" /> for details about ID generation.
</t>
<t>
- The HASH is calculated by calculating the
CRC32 checksum of the 64-bit ID value
- which returns a 32-bit value. To get the
HASHSUM field all IDs are added
- up with a binary XOR operation.
-
+ The calculation of the HASHSUM field is done
accordingly to the calculation of the IDSUM field:
+ all HASHes are added up with a binary XOR
operation.
+ The HASH value is calculated as described in
detail in section <xref target="ibf_format_HASH_calculation" format="title" />.
</t>
<t>
- To decide in which buckets the ID and HASH
have to be added up there is the following
- algorithm used: The first index is simply the
HASH modulo the IBF size. The second
- index is calculated by creating a new 64-bit
value by shifting the 32-bit
- value left and setting the lower 32-bit to the
number of indexes already processed. From the
- resulting 64-bit value a CRC32 checksum is
created the second index is now the modulo of the
- CRC32 output this is repeated until the
predefined amount indexes is generated.
- In the case a index is hit twice, which would
mean this bucket could not get pure again,
- the second hit is just skipped and the next
iteration is used as.
-
- <!-- @Christian: I dont have a clue how this
is done... The code is very hard to read can you explain the
- salt_key function in
gnunet-service-set_union.c file
-
- CG: Eh, you should really read in setu/, not
in set/. Alas, this function is the same.
-
- The goal of salt_key is to modify a given IBF
key based on the salt (so we
- end up with different material depending on
the salt). We only use the
- lowest 6 bits of the salt (hopefully enough!):
-
- int s = salt % 64;
- uint64_t x = k_in->key_val; // that's the
real input: at 64 bit value
-
- /* rotate ibf key */
- x = (x >> s) | (x << (64 - s)); // We simply
to a bit rotation by 's'
- k_out->key_val = x; // That's the final
output.
-
- In some languages, this would simply be:
- result = (input <<< salt); // bit
rotation operator
-
- @Christian and the ibf_insert_into (why
exponentiation? ^=) in the ibf.c
-
- CG: ^= is XOR in C (A ^=B; is basically "A :=
A XOR B"), _not_ exponentiation!
-
- The only thing i found out was that the
Hashsum in the current implementation is calculated with CRC32.
-
- Not just. We take the 64-bit ID value. First,
using 'CRC32' to compute
- a 32-byte value. Take that modulo % buckets
to get a bucket index.
- Then shift the 32 bits high, or with 'i'
(loop!) to set 32 low bits,
- and again CRC32 to compute the next bucket.
*IF* this formula returns
- the same bucket twice, skip (so we guarantee
hash_num disjoint buckets).
- Note that the code had a bug, pushing a fix
now:
-
- if (dst[j] == bucket)
- must be
- if (dst[j] == bucket % ibf->size)
-
- -->
+ The algorithm to find the correct bucket in
which the ID and the HASH have to be added
+ is described in detail in section <xref
target="ibf_format_bucket_identification" format="title" />.
</t>
<!--
@@ -1306,7 +1362,6 @@ hashSum | 0x0101 | 0x0101 | 0x5050 |
0000 |
/ /
/ /
]]></artwork>
- <!-- <postamble>which is a very simple
example.</postamble>-->
</figure>
<t>where:</t>
<dl>
@@ -1374,7 +1429,6 @@ hashSum | 0x0101 | 0x0101 | 0x5050 |
0000 |
/ /
/ /
]]></artwork>
- <!-- <postamble>which is a very simple
example.</postamble>-->
</figure>
<t>where:</t>
<dl>
@@ -1423,7 +1477,6 @@ hashSum | 0x0101 | 0x0101 | 0x5050 |
0000 |
| IBF KEY |
+-----+-----+-----+-----+-----+-----+-----+-----+
]]></artwork>
- <!-- <postamble>which is a very simple
example.</postamble>-->
</figure>
<t>where:</t>
<dl>
@@ -1470,7 +1523,6 @@ hashSum | 0x0101 | 0x0101 | 0x5050 |
0000 |
/ /
/ /
]]></artwork>
- <!-- <postamble>which is a very simple
example.</postamble>-->
</figure>
<t>where:</t>
<dl>
@@ -1519,7 +1571,6 @@ hashSum | 0x0101 | 0x0101 | 0x5050 |
0000 |
| HASH
+-----+-----+-----+-----+
]]></artwork>
- <!-- <postamble>which is a very simple
example.</postamble>-->
</figure>
<t>where:</t>
<dl>
@@ -1563,7 +1614,6 @@ hashSum | 0x0101 | 0x0101 | 0x5050 |
0000 |
| MSG SIZE | MSG TYPE |
+-----+-----+-----+-----+
]]></artwork>
- <!-- <postamble>which is a very simple
example.</postamble>-->
</figure>
<t>where:</t>
<dl>
@@ -1605,7 +1655,6 @@ hashSum | 0x0101 | 0x0101 | 0x5050 |
0000 |
| MSG SIZE | MSG TYPE |
+-----+-----+-----+-----+
]]></artwork>
- <!-- <postamble>which is a very simple
example.</postamble>-->
</figure>
<t>where:</t>
<dl>
@@ -1652,7 +1701,6 @@ hashSum | 0x0101 | 0x0101 | 0x5050 |
0000 |
/ /
/ /
]]></artwork>
- <!-- <postamble>which is a very simple
example.</postamble>-->
</figure>
<t>where:</t>
<dl>
@@ -1726,7 +1774,6 @@ hashSum | 0x0101 | 0x0101 | 0x5050 |
0000 |
/ /
/ /
]]></artwork>
- <!-- <postamble>which is a very simple
example.</postamble>-->
</figure>
<t>where:</t>
<dl>
@@ -1828,11 +1875,6 @@ Type | Name | References |
Description
570 | SETU_P2P_FULL_DONE | [This.I-D] | All elements in full
synchronization mode have been send is done.
571 | SETU_P2P_FULL_ELEMENT | [This.I-D] | Send an actual element in
full synchronization mode.
-
-
-
-
-
]]></artwork>
</figure>
</section>
@@ -1877,6 +1919,49 @@ Type | Name | References |
Description
</front>
</reference>
+ <reference anchor="CryptographicallySecureVoting"
target="https://git.gnunet.org/bibliography.git/plain/docs/ba_dold_voting_24aug2014.pdf";>
+ <front>
+ <title>Cryptographically Secure, DistributedElectronic
Voting</title>
+ <author initials="F." surname="Dold" fullname="Florian
Dold">
+ <organization>Technische Universität
München</organization>
+ </author>
+ </front>
+ </reference>
+
+
+ <reference anchor="GNUNET"
target="https://git.gnunet.org/bibliography.git/plain/docs/gns2014wachs.pdf";>
+ <front>
+ <title>A Censorship-Resistant, Privacy-Enhancing andFully
Decentralized Name System</title>
+ <author initials="M." surname="Wachs" fullname="Matthias
Wachs">
+ <organization>Technische Universität
München</organization>
+ </author>
+ <author initials="M." surname="Schanzenbach"
fullname="Martin Schanzenbach">
+ <organization>Technische Universität
München</organization>
+ </author>
+ <author initials="C." surname="Grothoff"
fullname="Christian Grothoff">
+ <organization>Technische Universität
München</organization>
+ </author>
+ </front>
+ </reference>
+
+ <reference anchor="Eppstein"
target="https://doi.org/10.1145/2018436.2018462";>
+ <front>
+ <title>What’s the Difference? Efficient Set Reconciliation
without Prior Context</title>
+ <author initials="D." surname="Eppstein" fullname="David
Eppstein">
+ <organization>U.C. Irvine</organization>
+ </author>
+ <author initials="M." surname="Goodrich" fullname="Michael
T. Goodrich">
+ <organization>U.C. Irvine</organization>
+ </author>
+ <author initials="F." surname="Uyeda" fullname="Frank
Uyeda">
+ <organization>U.C. San Diego</organization>
+ </author>
+ <author initials="G." surname="Varghese" fullname="George
Varghese">
+ <organization>U.C. San Diego</organization>
+ </author>
+ </front>
+ </reference>
+
<reference anchor="GNS"
target="https://doi.org/10.1007/978-3-319-12280-9_9";>
<front>
<title>A Censorship-Resistant, Privacy-Enhancing and Fully
Decentralized Name System</title>
@@ -2007,8 +2092,41 @@ Type | Name | References |
Description
</front>
</reference>-->
</references>
- <!-- Change Log
- v00 2017-07-23 MS Initial version
- -->
+ <section anchor="test_vectors" numbered="true" toc="default">
+ <name>Test Vectors</name>
+ <section anchor="test_vectors_map_function" numbered="true"
toc="default">
+ <name>Map Function</name>
+ <t>
+ INPUTS:
+ </t>
+ <t>
+ key: 0xFFFFFFFFFFFFFFFF (64-bit)<br/>
+ number_of_buckets_per_element: 3<br/>
+ ibf_size: 300
+ </t>
+ <t>
+ OUTPUT:
+ </t>
+ <t>
+ ["222","32","10"]
+ </t>
+ </section>
+ <section anchor="test_vectors_id_function" numbered="true"
toc="default">
+ <name>ID Calculation Function</name>
+ <t>
+ INPUTS:
+ </t>
+ <t>
+ element: 0xadadadadadadadad
+ ibf_salt 0x3F (6-bit)
+ </t>
+ <t>
+ OUTPUT:
+ </t>
+ <t>
+ 0xFFFFFFFFFFFFFFFF
+ </t>
+ </section>
+ </section>
</back>
</rfc>
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [lsd0003] branch master updated: Fixed some stuff,
gnunet <=