diff options
Diffstat (limited to 'draft-schanzen-r5n.xml')
-rw-r--r-- | draft-schanzen-r5n.xml | 123 |
1 files changed, 58 insertions, 65 deletions
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml index 9e7dd1a..200f28d 100644 --- a/draft-schanzen-r5n.xml +++ b/draft-schanzen-r5n.xml | |||
@@ -19,6 +19,7 @@ | |||
19 | <!ENTITY RFC8032 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8032.xml"> | 19 | <!ENTITY RFC8032 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8032.xml"> |
20 | <!ENTITY RFC8126 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8126.xml"> | 20 | <!ENTITY RFC8126 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8126.xml"> |
21 | <!ENTITY RFC8174 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml"> | 21 | <!ENTITY RFC8174 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml"> |
22 | <!ENTITY RFC8324 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8324.xml"> | ||
22 | <!ENTITY I-D.schanzen-gns PUBLIC '' "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.schanzen-gns.xml"> | 23 | <!ENTITY I-D.schanzen-gns PUBLIC '' "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.schanzen-gns.xml"> |
23 | ]> | 24 | ]> |
24 | <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> | 25 | <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> |
@@ -445,7 +446,6 @@ Connectivity | |Underlay| |Underlay| | |||
445 | When the connection attempt is successful, information on the new | 446 | When the connection attempt is successful, information on the new |
446 | peer is offered through the <tt>PEER_CONNECTED</tt> signal. | 447 | peer is offered through the <tt>PEER_CONNECTED</tt> signal. |
447 | </dd> | 448 | </dd> |
448 | If PEER_CONNECT and put in routing table, then HOLD --> | ||
449 | <dt> | 449 | <dt> |
450 | <tt>HOLD(P)</tt> | 450 | <tt>HOLD(P)</tt> |
451 | </dt> | 451 | </dt> |
@@ -641,14 +641,6 @@ Connectivity | |Underlay| |Underlay| | |||
641 | of <tt>HELLO</tt>s. | 641 | of <tt>HELLO</tt>s. |
642 | </t> | 642 | </t> |
643 | <t> | 643 | <t> |
644 | <!-- FIXME REPL_LVL unclear, RF_SIZE unclear. Sections like this make me wonder how | ||
645 | we can avoid using prose to specify message creation. | ||
646 | REPL_LVL: For hello it is 4 => RECOMMENDED to 4 | ||
647 | RF_SIZE: Specified in HELLO block as connected peers = |E|. | ||
648 | RF: All peers I am already connected to should be included in the RF BF | ||
649 | XQUERY: => nil | ||
650 | Flags? FindApproximate | ||
651 | --> | ||
652 | To discover peers for its routing table, a peer will initiate <tt>GetMessage</tt> requests | 644 | To discover peers for its routing table, a peer will initiate <tt>GetMessage</tt> requests |
653 | <xref target="p2p_get"/> asking for blocks of type <tt>HELLO</tt> using its own peer address as | 645 | <xref target="p2p_get"/> asking for blocks of type <tt>HELLO</tt> using its own peer address as |
654 | <tt>QUERY_HASH</tt>. | 646 | <tt>QUERY_HASH</tt>. |
@@ -678,12 +670,13 @@ Connectivity | |Underlay| |Underlay| | |||
678 | already in the routing table, it must cache it as long as that peer is in its routing table | 670 | already in the routing table, it must cache it as long as that peer is in its routing table |
679 | (or until the <tt>HELLO</tt> expires) and serve it in response to | 671 | (or until the <tt>HELLO</tt> expires) and serve it in response to |
680 | GET requests for <tt>HELLO</tt> blocks (see <xref target="p2p_get_processing"/>). | 672 | GET requests for <tt>HELLO</tt> blocks (see <xref target="p2p_get_processing"/>). |
673 | This behaviour makes it unnecessary to initiate dedicated <tt>PutMessages</tt> containing | ||
674 | <tt>HELLO</tt> blocks by the implementation. | ||
681 | </t> | 675 | </t> |
682 | </section> | 676 | </section> |
683 | <section anchor="routing_bloomfilter"> | 677 | <section anchor="routing_bloomfilter"> |
684 | <name>Peer Bloom Filter</name> | 678 | <name>Peer Bloom Filter</name> |
685 | <t> | 679 | <t> |
686 | <!-- FIXME HArdcoded to 128 bytes = L/8 --> | ||
687 | As DHT <tt>GetMessage</tt>s and <tt>PutMessage</tt>s traverse a random path through the network for the | 680 | As DHT <tt>GetMessage</tt>s and <tt>PutMessage</tt>s traverse a random path through the network for the |
688 | first N hops, it is essential that routing loops are avoided. | 681 | first N hops, it is essential that routing loops are avoided. |
689 | This peer Bloom filter is constant in size at <tt>L=1024</tt> buckets (128 bytes) and | 682 | This peer Bloom filter is constant in size at <tt>L=1024</tt> buckets (128 bytes) and |
@@ -1302,8 +1295,11 @@ BEGIN | |||
1302 | is in the future. If the signature is invalid, the message is discarded. | 1295 | is in the future. If the signature is invalid, the message is discarded. |
1303 | </li> | 1296 | </li> |
1304 | <li> | 1297 | <li> |
1305 | The <tt>HELLO</tt> information is cached in the routing table until it expires, | 1298 | The information contained in the <tt>HelloMessage</tt> can be used to synthesize a |
1306 | the peer is removed from the routing table, or the information is replaced by another message from the peer. | 1299 | block of type <tt>HELLO</tt> (<xref target="hello_block"/>). |
1300 | The block is cached in the routing table until it expires, | ||
1301 | the peer is removed from the routing table, or the information is replaced by another message | ||
1302 | from the peer. | ||
1307 | The implementation <bcp14>SHOULD</bcp14> instruct the Underlay to connect to all now available addresses | 1303 | The implementation <bcp14>SHOULD</bcp14> instruct the Underlay to connect to all now available addresses |
1308 | using <tt>TRY_CONNECT</tt> in order to make the underlay aware of alternative addresses for this connection and | 1304 | using <tt>TRY_CONNECT</tt> in order to make the underlay aware of alternative addresses for this connection and |
1309 | to maintain optimal connectivity. | 1305 | to maintain optimal connectivity. |
@@ -1510,8 +1506,10 @@ BEGIN | |||
1510 | <li> | 1506 | <li> |
1511 | If the local peer is the closest peer | 1507 | If the local peer is the closest peer |
1512 | (cf. <tt>IsClosestPeer(SELF, BLOCK_KEY, PeerFilter)</tt>) or the <tt>DemultiplexEverywhere</tt> | 1508 | (cf. <tt>IsClosestPeer(SELF, BLOCK_KEY, PeerFilter)</tt>) or the <tt>DemultiplexEverywhere</tt> |
1513 | flag ist set, the message <bcp14>MUST</bcp14> | 1509 | flag ist set, the message <bcp14>SHOULD</bcp14> |
1514 | be stored locally in the block storage if possible. | 1510 | be stored locally in the block storage if possible. |
1511 | The implementation <tt>MAY</tt> choose not store the block if external factors or configurations | ||
1512 | prevent this, such as limited (alottted) disk space. | ||
1515 | </li> | 1513 | </li> |
1516 | <li> | 1514 | <li> |
1517 | If the <tt>BTYPE</tt> of the message indicates a <tt>HELLO</tt> block, the | 1515 | If the <tt>BTYPE</tt> of the message indicates a <tt>HELLO</tt> block, the |
@@ -1522,8 +1520,9 @@ BEGIN | |||
1522 | connection to the peer indicated in the <tt>HELLO</tt> block using | 1520 | connection to the peer indicated in the <tt>HELLO</tt> block using |
1523 | the address information | 1521 | the address information |
1524 | from the <tt>HELLO</tt> block and the Underlay function <tt>TRY_CONNECT</tt>. | 1522 | from the <tt>HELLO</tt> block and the Underlay function <tt>TRY_CONNECT</tt>. |
1525 | The implementation <bcp14>MUST</bcp14> instruct the Underlay to connect to all provided addresses | 1523 | The implementation <bcp14>MUST</bcp14> instruct the Underlay to try to connect to all |
1526 | using <tt>TRY_CONNECT</tt> in order to make the underlay aware of multiple addresses for this connection. | 1524 | provided addresses using <tt>TRY_CONNECT</tt> in order to make the underlay aware of |
1525 | multiple addresses for this connection. | ||
1527 | When a connection is established, the signal <tt>PEER_CONNECTED</tt> will cause | 1526 | When a connection is established, the signal <tt>PEER_CONNECTED</tt> will cause |
1528 | the peer to be added to the respective k-bucket of the routing table (<xref target="routing"/>). | 1527 | the peer to be added to the respective k-bucket of the routing table (<xref target="routing"/>). |
1529 | </li> | 1528 | </li> |
@@ -1700,21 +1699,25 @@ BEGIN | |||
1700 | </li> | 1699 | </li> |
1701 | <li> | 1700 | <li> |
1702 | <t> | 1701 | <t> |
1703 | If the local peer is the closest peer | 1702 | The local peer <bcp14>MUST</bcp14> try to produce a reply in any of the following cases: |
1704 | (cf. <tt>IsClosestPeer (SELF, QueryHash, PeerFilter)</tt>) or the | 1703 | (1) If the local peer is the closest peer |
1705 | <tt>DemultiplexEverywhere</tt> flag is set, a reply | 1704 | (cf. <tt>IsClosestPeer (SELF, QueryHash, PeerFilter)</tt>, or (2) |
1706 | <bcp14>MUST</bcp14> be produced (if one is available) using the following | 1705 | if the <tt>DemultiplexEverywhere</tt> flag is set, or (3) |
1706 | if the local peer is not the closest and the <tt>GetRequest</tt> was answered previously | ||
1707 | resulting in a cached reply (<xref target="p2p_result_processing"/>). | ||
1708 | </t> | ||
1709 | <t> | ||
1710 | The reply is produced (if one is available) using the following | ||
1707 | steps: | 1711 | steps: |
1708 | </t> | 1712 | </t> |
1709 | <ol type="%c)"> | 1713 | <ol type="%c)"> |
1710 | <!-- FIXME it seems to me as if some blocks need to be "synthesized", e.g. | ||
1711 | HELLOs from HelloMessages... this needs to be specified.--> | ||
1712 | <li> | 1714 | <li> |
1713 | If the <tt>BTYPE</tt> does not indicate a request for a <tt>HELLO</tt> block or | 1715 | If the <tt>BTYPE</tt> does not indicate a request for a <tt>HELLO</tt> block or |
1714 | <tt>ANY</tt>, | 1716 | <tt>ANY</tt>, |
1715 | the implementation <bcp14>MUST</bcp14> only consider blocks in the local block storage. | 1717 | the implementation <bcp14>MUST</bcp14> only consider blocks in the local block storage |
1716 | Otherwise, the implementation <bcp14>MUST</bcp14> only consider its own <tt>HELLO</tt> and | 1718 | and previously cached <tt>ResultMessage</tt>s. |
1717 | the <tt>HELLO</tt>s it has cached for the peers in its routing table as blocks. | 1719 | Otherwise, the implementation <bcp14>MUST</bcp14> only consider its own addresses and |
1720 | the addresses it has cached for the peers in its routing table. | ||
1718 | </li> | 1721 | </li> |
1719 | <li> | 1722 | <li> |
1720 | If <tt>FLAGS</tt> indicate a <tt>FindApproximate</tt> request, | 1723 | If <tt>FLAGS</tt> indicate a <tt>FindApproximate</tt> request, |
@@ -1725,16 +1728,19 @@ BEGIN | |||
1725 | with a <tt>BLOCK_KEY</tt> that matches the <tt>QUERY_HASH</tt> exactly and that is | 1728 | with a <tt>BLOCK_KEY</tt> that matches the <tt>QUERY_HASH</tt> exactly and that is |
1726 | not filtered by the <tt>RESULT_BF</tt>. | 1729 | not filtered by the <tt>RESULT_BF</tt>. |
1727 | </li> | 1730 | </li> |
1731 | <li> | ||
1732 | Any resulting (synthesized) block <bcp14>MUST</bcp14> be encapsulated in a | ||
1733 | <tt>ResultMessage</tt>. | ||
1734 | The cached or created <tt>ResultMessage</tt> <bcp14>SHOULD</bcp14> be transmitted to the | ||
1735 | neighbor from which the request was received. | ||
1736 | </li> | ||
1728 | </ol> | 1737 | </ol> |
1729 | <t> | 1738 | <t> |
1730 | The resulting block, if any, <bcp14>MUST</bcp14> be encapsulated in a | 1739 | Implementations <bcp14>MAY</bcp14> not to reply if they are resource-constrained. |
1731 | <tt>ResultMessage</tt> and <bcp14>SHOULD</bcp14> be transmitted to the | 1740 | However, <tt>ResultMessage</tt>s <bcp14>MUST</bcp14> be given the |
1732 | neighbor from which the request was received. | 1741 | highest priority among competing transmissions. |
1733 | Implementations <bcp14>MAY</bcp14> drop messages if they are resource-constrained. | ||
1734 | However, <tt>ResultMessage</tt>s <bcp14>MUST</bcp14> be given the | ||
1735 | highest priority among competing transmissions. | ||
1736 | </t> | 1742 | </t> |
1737 | <t> | 1743 | <t> |
1738 | If the <tt>BTYPE</tt> is supported and <tt>ValidateBlockReply</tt> for the given | 1744 | If the <tt>BTYPE</tt> is supported and <tt>ValidateBlockReply</tt> for the given |
1739 | query has yielded a status of <tt>FILTER_LAST</tt>, processing | 1745 | query has yielded a status of <tt>FILTER_LAST</tt>, processing |
1740 | <bcp14>MUST</bcp14> end and not continue with forwarding of | 1746 | <bcp14>MUST</bcp14> end and not continue with forwarding of |
@@ -1756,6 +1762,9 @@ BEGIN | |||
1756 | to, <tt>SEND(P, GetMessageP)</tt> is called. Here, <tt>GetMessageP</tt> | 1762 | to, <tt>SEND(P, GetMessageP)</tt> is called. Here, <tt>GetMessageP</tt> |
1757 | is the original message with the updated fields for <tt>HOPCOUNT</tt> (incremented | 1763 | is the original message with the updated fields for <tt>HOPCOUNT</tt> (incremented |
1758 | by 1), <tt>PEER_BF</tt> and <tt>RESULT_FILTER</tt>. | 1764 | by 1), <tt>PEER_BF</tt> and <tt>RESULT_FILTER</tt>. |
1765 | <!-- FIXME: For how long? what exactly must be stored? --> | ||
1766 | The implementation <tt>MUST</tt> cache the originator peer address and the | ||
1767 | <tt>GetMessage</tt> in order to correctly process any <tt>ResultMessage</tt>s. | ||
1759 | </li> | 1768 | </li> |
1760 | </ol> | 1769 | </ol> |
1761 | </section> | 1770 | </section> |
@@ -1951,8 +1960,6 @@ BEGIN | |||
1951 | does not have to match the <tt>QUERY_HASH</tt>. | 1960 | does not have to match the <tt>QUERY_HASH</tt>. |
1952 | </li> | 1961 | </li> |
1953 | <li> | 1962 | <li> |
1954 | <!-- FIXME: Discuss: Changed from MUST to SHOULD -- | ||
1955 | same change as above - MSC --> | ||
1956 | If the <tt>BTYPE</tt> of the message indicates a <tt>HELLO</tt> block, the | 1963 | If the <tt>BTYPE</tt> of the message indicates a <tt>HELLO</tt> block, the |
1957 | peer <bcp14>SHOULD</bcp14> be considered for the local routing | 1964 | peer <bcp14>SHOULD</bcp14> be considered for the local routing |
1958 | table by using the peer address computed from the block using<tt>DeriveBlockKey</tt>. | 1965 | table by using the peer address computed from the block using<tt>DeriveBlockKey</tt>. |
@@ -2015,13 +2022,12 @@ BEGIN | |||
2015 | </t> | 2022 | </t> |
2016 | </li> | 2023 | </li> |
2017 | <li> | 2024 | <li> |
2018 | <!-- FIXME: If that is the case, then this also needs to be in the | 2025 | Finally, the implementation <bcp14>SHOULD</bcp14> cache |
2019 | processing of GetMessage: I think we shoul dmove this to some | 2026 | <tt>ResultMessage</tt>s in order to provide already seen replies to |
2020 | performance considerations instead. | 2027 | future <tt>GetMessage</tt>s. |
2021 | => same formulation as for PUT to store if possible (MUST) | 2028 | The implementation <bcp14>MAY</bcp14> choose not no cache any or |
2022 | usr 1-to-1--> | 2029 | a limited number of <tt>ResultMessage</tt>s for reasons such as resource |
2023 | Finally, the implementation <bcp14>MAY</bcp14> choose to | 2030 | limitations. |
2024 | cache data from <tt>ResultMessage</tt>s. | ||
2025 | </li> | 2031 | </li> |
2026 | </ol> | 2032 | </ol> |
2027 | </section> | 2033 | </section> |
@@ -2291,26 +2297,12 @@ BEGIN | |||
2291 | <dt>SetupResultFilter(FilterSize, Mutator) -> RF</dt> | 2297 | <dt>SetupResultFilter(FilterSize, Mutator) -> RF</dt> |
2292 | <dd> | 2298 | <dd> |
2293 | <t> | 2299 | <t> |
2294 | <!-- FIXME: I do not understand this. Isn't the element set E known | ||
2295 | for <tt>HELLO</tt> blocks? Isn't it H_ADDRS XOR MUTATOR? | ||
2296 | E => conected peers in routing table | ||
2297 | K => is 16 | ||
2298 | --> | ||
2299 | The RESULT_FILTER for <tt>HELLO</tt> blocks is implemented using a | 2300 | The RESULT_FILTER for <tt>HELLO</tt> blocks is implemented using a |
2300 | Bloom filter following the definition from <xref target="bloom_filters"/> | 2301 | Bloom filter following the definition from <xref target="bloom_filters"/> |
2301 | and consists of a variable number of buckets <tt>L</tt>. | 2302 | and consists of a variable number of buckets <tt>L</tt>. |
2302 | <tt>L</tt> depends on the number of elements <tt>|E|</tt> known to be filtered at the | 2303 | <tt>L</tt> depends on the number of connected peers <tt>|E|</tt> known to |
2303 | initiator. | 2304 | the peer creating a <tt>HELLO</tt> block from its own addresses: |
2304 | <!-- FIXME: Minimum space for used for what? There is no example given anywhere in the | 2305 | <tt>L</tt> is set to the minimum of |
2305 | spec how this becomes relevant. Again, this is not some abstract block, | ||
2306 | but specifically a <tt>HELLO</tt> (see above). | ||
2307 | E is the number of currently connected peers (neighbors)! | ||
2308 | E is no really ever 0 so the following sentence should be amended. | ||
2309 | --> | ||
2310 | If <tt>|E|</tt> is zero, the size <tt>L</tt> is set to 32 bits to provide some minimum | ||
2311 | space (to be used by peers when forwarding the request after | ||
2312 | returning local results). | ||
2313 | Otherwise, <tt>L</tt> is set to the minimum of | ||
2314 | 2<sup>18</sup> bits (2<sup>15</sup> bytes) and the lowest power | 2306 | 2<sup>18</sup> bits (2<sup>15</sup> bytes) and the lowest power |
2315 | of 2 that is strictly larger than <tt>2*K*|E|</tt> bits (<tt>K*|E|/4</tt> bytes). | 2307 | of 2 that is strictly larger than <tt>2*K*|E|</tt> bits (<tt>K*|E|/4</tt> bytes). |
2316 | </t> | 2308 | </t> |
@@ -2538,12 +2530,12 @@ BEGIN | |||
2538 | control such as <xref target="RFC6940"/> which, like R<sup>5</sup>N, provides | 2530 | control such as <xref target="RFC6940"/> which, like R<sup>5</sup>N, provides |
2539 | a peer-to-peer (P2P) signaling protocol with extensible routing and topology | 2531 | a peer-to-peer (P2P) signaling protocol with extensible routing and topology |
2540 | mechanisms. | 2532 | mechanisms. |
2541 | <!-- FIXME: Can we give examples here? | 2533 | Some decentralized applications such as the GNU Name System (<xref target="I-D.schanzen-gns"/>) |
2542 | Centralization DNS roots fixed through GNS. | 2534 | require a more open system that enables ad-hoc participation and other means to prevent common |
2543 | --> | 2535 | attacks on P2P overlays. |
2544 | Some decentralized applications require a more open system that | 2536 | GNS, for example, would be in conflict with its goals of providing a solution to the issues of a |
2545 | enables ad-hoc participation and other means to prevent common attacks | 2537 | "Single Hierarchy with a Centrally Controlled Root" and "Distribution and Management of Root Servers" |
2546 | on P2P overlays. | 2538 | in DNS as raised in <xref target="RFC8324"/>. |
2547 | </t> | 2539 | </t> |
2548 | </section> | 2540 | </section> |
2549 | </section> | 2541 | </section> |
@@ -2600,7 +2592,7 @@ BEGIN | |||
2600 | Served", as described in <xref target="RFC8126"/>. | 2592 | Served", as described in <xref target="RFC8126"/>. |
2601 | GANA created the registry as follows: | 2593 | GANA created the registry as follows: |
2602 | </t> | 2594 | </t> |
2603 | <!-- FIXME changed GNS Reference to This.I-D because we either need to define it here | 2595 | <!-- NOTE: changed GNS Reference to This.I-D because we either need to define it here |
2604 | or in the GNS RFC. And I think here is better or in a separate document | 2596 | or in the GNS RFC. And I think here is better or in a separate document |
2605 | => not in here. Use separate document for NAMERECORD draft. | 2597 | => not in here. Use separate document for NAMERECORD draft. |
2606 | -MSC --> | 2598 | -MSC --> |
@@ -2609,8 +2601,8 @@ BEGIN | |||
2609 | Number| Name | References | Description | 2601 | Number| Name | References | Description |
2610 | ------+----------------+------------+------------------------- | 2602 | ------+----------------+------------+------------------------- |
2611 | 0 ANY [This.I-D] Reserved | 2603 | 0 ANY [This.I-D] Reserved |
2612 | 11 GNS_NAMERECORD [This.I-D] Block for GNS records | ||
2613 | 13 DHT_HELLO [This.I-D] Address data for a peer | 2604 | 13 DHT_HELLO [This.I-D] Address data for a peer |
2605 | |||
2614 | Contact: r5n-registry@gnunet.org | 2606 | Contact: r5n-registry@gnunet.org |
2615 | ]]></artwork> | 2607 | ]]></artwork> |
2616 | </figure> | 2608 | </figure> |
@@ -2702,6 +2694,7 @@ Type | Name | References | Description | |||
2702 | &RFC6940; | 2694 | &RFC6940; |
2703 | &RFC8126; | 2695 | &RFC8126; |
2704 | &RFC8174; | 2696 | &RFC8174; |
2697 | &RFC8324; | ||
2705 | &I-D.schanzen-gns; | 2698 | &I-D.schanzen-gns; |
2706 | 2699 | ||
2707 | <reference anchor="ed25519" target="http://link.springer.com/chapter/10.1007/978-3-642-23951-9_9"><front><title>High-Speed High-Security Signatures</title><author initials="D." surname="Bernstein" fullname="Daniel Bernstein"><organization>University of Illinois at Chicago</organization></author><author initials="N." surname="Duif" fullname="Niels Duif"><organization>Technische Universiteit Eindhoven</organization></author><author initials="T." surname="Lange" fullname="Tanja Lange"><organization>Technische Universiteit Eindhoven</organization></author><author initials="P." surname="Schwabe" fullname="Peter Schwabe"><organization>National Taiwan University</organization></author><author initials="B." surname="Yang" fullname="Bo-Yin Yang"><organization>Academia Sinica</organization></author><date year="2011"/></front></reference> | 2700 | <reference anchor="ed25519" target="http://link.springer.com/chapter/10.1007/978-3-642-23951-9_9"><front><title>High-Speed High-Security Signatures</title><author initials="D." surname="Bernstein" fullname="Daniel Bernstein"><organization>University of Illinois at Chicago</organization></author><author initials="N." surname="Duif" fullname="Niels Duif"><organization>Technische Universiteit Eindhoven</organization></author><author initials="T." surname="Lange" fullname="Tanja Lange"><organization>Technische Universiteit Eindhoven</organization></author><author initials="P." surname="Schwabe" fullname="Peter Schwabe"><organization>National Taiwan University</organization></author><author initials="B." surname="Yang" fullname="Bo-Yin Yang"><organization>Academia Sinica</organization></author><date year="2011"/></front></reference> |