[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0003] branch master updated: Rearanget the code
|
From: |
gnunet |
|
Subject: |
[lsd0003] branch master updated: Rearanget the code |
|
Date: |
Thu, 19 Nov 2020 16:30:04 +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 7254645 Rearanget the code
7254645 is described below
commit 7254645f5040df95cccc84d8f0350cd88be22845
Author: Elias Summermatter <elias.summermatter@seccom.ch>
AuthorDate: Thu Nov 19 16:29:58 2020 +0100
Rearanget the code
---
draft-summermatter-set-union.xml | 753 ++++++++++++++++++++-------------------
1 file changed, 382 insertions(+), 371 deletions(-)
diff --git a/draft-summermatter-set-union.xml b/draft-summermatter-set-union.xml
index b8825bd..65fa749 100644
--- a/draft-summermatter-set-union.xml
+++ b/draft-summermatter-set-union.xml
@@ -1,23 +1,23 @@
<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent" [
-<!ENTITY RFC1034 PUBLIC ''
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml";>
-<!ENTITY RFC1035 PUBLIC ''
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml";>
-<!ENTITY RFC2119 PUBLIC ''
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml";>
-<!ENTITY RFC2782 PUBLIC ''
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2782.xml";>
-<!ENTITY RFC3629 PUBLIC ''
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml";>
-<!ENTITY RFC3686 PUBLIC ''
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3686.xml";>
-<!ENTITY RFC3826 PUBLIC ''
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3826.xml";>
-<!ENTITY RFC3912 PUBLIC ''
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3912.xml";>
-<!ENTITY RFC5869 PUBLIC ''
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5869.xml";>
-<!ENTITY RFC5890 PUBLIC ''
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5890.xml";>
-<!ENTITY RFC5891 PUBLIC ''
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5891.xml";>
-<!ENTITY RFC6781 PUBLIC ''
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6781.xml";>
-<!ENTITY RFC6895 PUBLIC ''
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6895.xml";>
-<!ENTITY RFC6979 PUBLIC ''
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6979.xml";>
-<!ENTITY RFC7748 PUBLIC ''
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.7748.xml";>
-<!ENTITY RFC8032 PUBLIC ''
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.8032.xml";>
-<!ENTITY RFC8126 PUBLIC ''
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.8126.xml";>
-]>
+ <!ENTITY RFC1034 PUBLIC ''
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml";>
+ <!ENTITY RFC1035 PUBLIC ''
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml";>
+ <!ENTITY RFC2119 PUBLIC ''
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml";>
+ <!ENTITY RFC2782 PUBLIC ''
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2782.xml";>
+ <!ENTITY RFC3629 PUBLIC ''
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml";>
+ <!ENTITY RFC3686 PUBLIC ''
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3686.xml";>
+ <!ENTITY RFC3826 PUBLIC ''
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3826.xml";>
+ <!ENTITY RFC3912 PUBLIC ''
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3912.xml";>
+ <!ENTITY RFC5869 PUBLIC ''
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5869.xml";>
+ <!ENTITY RFC5890 PUBLIC ''
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5890.xml";>
+ <!ENTITY RFC5891 PUBLIC ''
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5891.xml";>
+ <!ENTITY RFC6781 PUBLIC ''
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6781.xml";>
+ <!ENTITY RFC6895 PUBLIC ''
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6895.xml";>
+ <!ENTITY RFC6979 PUBLIC ''
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6979.xml";>
+ <!ENTITY RFC7748 PUBLIC ''
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.7748.xml";>
+ <!ENTITY RFC8032 PUBLIC ''
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.8032.xml";>
+ <!ENTITY RFC8126 PUBLIC ''
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.8126.xml";>
+ ]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes" ?>
@@ -25,101 +25,103 @@
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
-<rfc xmlns:xi="http://www.w3.org/2001/XInclude"; category="info"
docName="draft-schanzen-gns-01" ipr="trust200902" obsoletes="" updates=""
submissionType="IETF" xml:lang="en" version="3">
- <!-- xml2rfc v2v3 conversion 2.26.0 -->
- <front>
- <title abbrev="Set Union">
- Byzantine Fault Tolerant Set Reconciliation
- </title>
- <seriesInfo name="Internet-Draft" value="draft-summermatter-set-union-01"/>
- <author fullname="Elias Summermatter" initials="E." surname="Summermatter">
- <organization>.</organization>
- <address>
- <postal>
- <street>Brunnmattstrasse 44</street>
- <city>Bern</city>
- <code>3007</code>
- <country>CH</country>
- </postal>
- <email>elias.summermatter@seccom.ch</email>
- </address>
- </author>
- <author fullname="Christian Grothoff" initials="C." surname="Grothoff">
- <organization>Berner Fachhochschule</organization>
- <address>
- <postal>
- <street>Hoeheweg 80</street>
- <city>Biel/Bienne</city>
- <code>2501</code>
- <country>CH</country>
- </postal>
- <email>grothoff@gnunet.org</email>
- </address>
- </author>
+<rfc category="info" docName="draft-schanzen-gns-01" ipr="trust200902"
+ obsoletes="" updates="" submissionType="IETF" xml:lang="en" version="3">
+ <!-- xml2rfc v2v3 conversion 2.26.0 -->
+ <front>
+ <title abbrev="Set Union">
+ Byzantine Fault Tolerant Set Reconciliation
+ </title>
+ <seriesInfo name="Internet-Draft"
value="draft-summermatter-set-union-01"/>
+ <author fullname="Elias Summermatter" initials="E."
surname="Summermatter">
+ <organization>.</organization>
+ <address>
+ <postal>
+ <street>Brunnmattstrasse 44</street>
+ <city>Bern</city>
+ <code>3007</code>
+ <country>CH</country>
+ </postal>
+ <email>elias.summermatter@seccom.ch</email>
+ </address>
+ </author>
+ <author fullname="Christian Grothoff" initials="C." surname="Grothoff">
+ <organization>Berner Fachhochschule</organization>
+ <address>
+ <postal>
+ <street>Hoeheweg 80</street>
+ <city>Biel/Bienne</city>
+ <code>2501</code>
+ <country>CH</country>
+ </postal>
+ <email>grothoff@gnunet.org</email>
+ </address>
+ </author>
- <!-- Meta-data Declarations -->
- <area>General</area>
- <workgroup>Independent Stream</workgroup>
- <keyword>name systems</keyword>
- <abstract>
- <t>This document contains a protocol specification for Byzantine
fault-tolerant
- Set Reconciliation.</t>
- </abstract>
- </front>
- <middle>
- <section anchor="introduction" numbered="true" toc="default">
- <name>Introduction</name>
- <t>
- --- TEXT HERE ---
- </t>
- <t>
- This document defines the normative wire format of resource records,
resolution processes,
- cryptographic routines and security considerations for use by
implementors.
- SETU requires a bidirectional secure communication channel between the
two parties.
- Specification of the communication channel is out of scope of this
document.
- </t>
- <t>
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
- NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
- "OPTIONAL" in this document are to be interpreted as described
- in <xref target="RFC2119"/>.
- </t>
- <t>
+ <!-- Meta-data Declarations -->
+ <area>General</area>
+ <workgroup>Independent Stream</workgroup>
+ <keyword>name systems</keyword>
+ <abstract>
+ <t>This document contains a protocol specification for Byzantine
fault-tolerant
+ Set Reconciliation.
+ </t>
+ </abstract>
+ </front>
+ <middle>
+ <section anchor="introduction" numbered="true" toc="default">
+ <name>Introduction</name>
+ <t>
+ --- TEXT HERE ---
+ </t>
+ <t>
+ This document defines the normative wire format of resource
records, resolution processes,
+ cryptographic routines and security considerations for use by
implementors.
+ SETU requires a bidirectional secure communication channel
between the two parties.
+ Specification of the communication channel is out of scope of
this document.
+ </t>
+ <t>
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
+ NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described
+ in<xref target="RFC2119"/>.
+ </t>
+ <t>
- </t>
- </section>
+ </t>
+ </section>
- <section anchor="modeofoperation" numbered="true" toc="default">
- <name>Mode of operation</name>
- <section anchor="modeofoperation_full-sync-client-with-bigger-set"
numbered="true" toc="default">
- <name>Full sync mode</name>
+ <section anchor="modeofoperation" numbered="true" toc="default">
+ <name>Mode of operation</name>
+ <section anchor="modeofoperation_full-sync-client-with-bigger-set"
numbered="true" toc="default">
+ <name>Full sync mode</name>
+ </section>
+ <section anchor="modeofoperation_individual-elements"
numbered="true" toc="default">
+ <name>Individual element sync mode</name>
+ </section>
+ <section anchor="modeofoperation_combined-mode" numbered="true"
toc="default">
+ <name>Combined mode</name>
+ </section>
</section>
- <section anchor="modeofoperation_individual-elements" numbered="true"
toc="default">
- <name>Individual element sync mode</name>
- </section>
- <section anchor="modeofoperation_combined-mode" numbered="true"
toc="default">
- <name>Combined mode</name>
- </section>
- </section>
- <section anchor="messages" numbered="true" toc="default">
- <name>Messages</name>
+ <section anchor="messages" numbered="true" toc="default">
+ <name>Messages</name>
- <section anchor="messages_operation_request" numbered="true"
toc="default">
- <name>Operation Request</name>
+ <section anchor="messages_operation_request" numbered="true"
toc="default">
+ <name>Operation Request</name>
- <section anchor="messages_operation_request_description"
numbered="true" toc="default">
- <name>Description</name>
- <t>
- Some description what this messages does
- </t>
- </section>
- <section anchor="messages_operation_request_structure"
numbered="true" toc="default">
- <name>Structure</name>
+ <section anchor="messages_operation_request_description"
numbered="true" toc="default">
+ <name>Description</name>
+ <t>
+ Some description what this messages does
+ </t>
+ </section>
+ <section anchor="messages_operation_request_structure"
numbered="true" toc="default">
+ <name>Structure</name>
- <figure anchor="figure_gnsrecord">
- <artwork name="" type="" align="left" alt=""><![CDATA[
+ <figure anchor="figure_gnsrecord">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| EXPIRATION |
@@ -131,299 +133,308 @@
/ /
/ /
]]></artwork>
- <!-- <postamble>which is a very simple
example.</postamble>-->
- </figure>
- <t>where:</t>
- <dl>
- <dt>EXPIRATION</dt>
- <dd>
- denotes the absolute 64-bit expiration date of the record.
- In microseconds since midnight (0 hour), January 1, 1970 in
network
- byte order.
- </dd>
- <dt>DATA SIZE</dt>
- <dd>
- denotes the 32-bit size of the DATA field in bytes and in
network byte
- order.
- </dd>
- <dt>TYPE</dt>
- <dd>
- is the 32-bit resource record type. This type can be one of
the GNS resource
- records as defined in or a DNS record
- type as defined in <xref target="RFC1035" /> or any of the
- complementary standardized DNS resource record types. This
value must be
- stored in network byte order. Note that values
- below 2^16 are reserved for allocation via IANA (<xref
target="RFC6895" />),
- while values above 2^16 are allocated by the
- GNUnet Assigned Numbers Authority <xref target="GANA" />.
- </dd>
- <dt>FLAGS</dt>
- <dd>
- is a 32-bit resource record flags field (see below).
- </dd>
- <dt>DATA</dt>
- <dd>
- the variable-length resource record data payload. The
contents are defined
- by the
- respective type of the resource record.
- </dd>
- </dl>
- <t>
- Flags indicate metadata surrounding the resource record. A flag
- value of 0 indicates that all flags are unset. The following
- illustrates the flag distribution in the 32-bit flag value of a
- resource record:</t>
- <figure anchor="figure_flag">
- <artwork name="" type="" align="left" alt=""><![CDATA[
+ <!-- <postamble>which is a very simple
example.</postamble>-->
+ </figure>
+ <t>where:</t>
+ <dl>
+ <dt>EXPIRATION</dt>
+ <dd>
+ denotes the absolute 64-bit expiration date of the
record.
+ In microseconds since midnight (0 hour), January
1, 1970 in network
+ byte order.
+ </dd>
+ <dt>DATA SIZE</dt>
+ <dd>
+ denotes the 32-bit size of the DATA field in bytes
and in network byte
+ order.
+ </dd>
+ <dt>TYPE</dt>
+ <dd>
+ is the 32-bit resource record type. This type can
be one of the GNS resource
+ records as defined in or a DNS record
+ type as defined in
+ <xref target="RFC1035"/>
+ or any of the
+ complementary standardized DNS resource record
types. This value must be
+ stored in network byte order. Note that values
+ below 2^16 are reserved for allocation via IANA
(<xref target="RFC6895"/>),
+ while values above 2^16 are allocated by the
+ GNUnet Assigned Numbers Authority<xref
target="GANA"/>.
+ </dd>
+ <dt>FLAGS</dt>
+ <dd>
+ is a 32-bit resource record flags field (see
below).
+ </dd>
+ <dt>DATA</dt>
+ <dd>
+ the variable-length resource record data payload.
The contents are defined
+ by the
+ respective type of the resource record.
+ </dd>
+ </dl>
+ <t>
+ Flags indicate metadata surrounding the resource
record. A flag
+ value of 0 indicates that all flags are unset. The
following
+ illustrates the flag distribution in the 32-bit flag
value of a
+ resource record:
+ </t>
+ <figure anchor="figure_flag">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
... 5 4 3 2 1 0
------+--------+--------+--------+--------+--------+
/ ... | SHADOW | EXPREL | SUPPL | PRIVATE| / |
------+--------+--------+--------+--------+--------+
]]></artwork>
- <!-- <postamble>which is a very simple
example.</postamble>-->
- </figure>
- <t>
- where:
- </t>
- <dl>
- <dt>SHADOW</dt>
- <dd>
- If this flag is set, this record should be ignored by
resolvers unless all (other)
- records of the same record type have expired. Used to allow
zone publishers to
- facilitate good performance when records change by allowing
them to put future
- values of records into the DHT. This way, future values can
propagate and may be
- cached before the transition becomes active.
- </dd>
- <dt>EXPREL</dt>
- <dd>
- The expiration time value of the record is a relative time
(still in microseconds)
- and not an absolute time. This flag should never be
encountered by a resolver
- for records obtained from the DHT, but might be present when
a resolver looks up
- private records of a zone hosted locally.
- </dd>
- <dt>
- SUPPL
- </dt>
- <dd>
- This is a supplemental record. It is provided in addition to
the
- other records. This flag indicates that this record is not
explicitly
- managed alongside the other records under the respective name
but
- may be useful for the application. This flag should only be
encountered
- by a resolver for records obtained from the DHT.
- </dd>
- <dt>PRIVATE</dt>
- <dd>
- This is a private record of this peer and it should thus not
be
- published in the DHT. Thus, this flag should never be
encountered by
- a resolver for records obtained from the DHT.
- Private records should still be considered just like
- regular records when resolving labels in local zones.
- </dd>
- </dl>
- </section>
- </section>
- </section>
+ <!-- <postamble>which is a very simple
example.</postamble>-->
+ </figure>
+ <t>
+ where:
+ </t>
+ <dl>
+ <dt>SHADOW</dt>
+ <dd>
+ If this flag is set, this record should be ignored
by resolvers unless all (other)
+ records of the same record type have expired. Used
to allow zone publishers to
+ facilitate good performance when records change by
allowing them to put future
+ values of records into the DHT. This way, future
values can propagate and may be
+ cached before the transition becomes active.
+ </dd>
+ <dt>EXPREL</dt>
+ <dd>
+ The expiration time value of the record is a
relative time (still in microseconds)
+ and not an absolute time. This flag should never
be encountered by a resolver
+ for records obtained from the DHT, but might be
present when a resolver looks up
+ private records of a zone hosted locally.
+ </dd>
+ <dt>
+ SUPPL
+ </dt>
+ <dd>
+ This is a supplemental record. It is provided in
addition to the
+ other records. This flag indicates that this
record is not explicitly
+ managed alongside the other records under the
respective name but
+ may be useful for the application. This flag
should only be encountered
+ by a resolver for records obtained from the DHT.
+ </dd>
+ <dt>PRIVATE</dt>
+ <dd>
+ This is a private record of this peer and it
should thus not be
+ published in the DHT. Thus, this flag should never
be encountered by
+ a resolver for records obtained from the DHT.
+ Private records should still be considered just
like
+ regular records when resolving labels in local
zones.
+ </dd>
+ </dl>
+ </section>
+ </section>
+ </section>
- <section anchor="states" numbered="true" toc="default">
- <name>States</name>
- <section anchor="state_expect-se" numbered="true" toc="default">
- <name>Expect Strata Estimator</name>
- <section anchor="state_expect-se_description" numbered="true"
toc="default">
- <name>Description</name>
- <t>
- Some description what this state does
- </t>
- </section>
- <section anchor="state_expect-se_supported-messages"
numbered="true" toc="default">
- <name>Supported/Unsupported Messages</name>
- </section>
- </section>
- </section>
+ <section anchor="states" numbered="true" toc="default">
+ <name>States</name>
+ <section anchor="state_expect-se" numbered="true" toc="default">
+ <name>Expect Strata Estimator</name>
+ <section anchor="state_expect-se_description" numbered="true"
toc="default">
+ <name>Description</name>
+ <t>
+ Some description what this state does
+ </t>
+ </section>
+ <section anchor="state_expect-se_supported-messages"
numbered="true" toc="default">
+ <name>Supported/Unsupported Messages</name>
+ </section>
+ </section>
+ </section>
- <section anchor="security" numbered="true" toc="default">
- <name>Security Considerations</name>
- <section anchor="security_crypto" numbered="true" toc="default">
- <name>BLAH</name>
- <t>
- Bulub.
- </t>
- </section>
- </section>
+ <section anchor="security" numbered="true" toc="default">
+ <name>Security Considerations</name>
+ <section anchor="security_crypto" numbered="true" toc="default">
+ <name>BLAH</name>
+ <t>
+ Bulub.
+ </t>
+ </section>
+ </section>
- <section anchor="gana" numbered="true" toc="default">
- <name>GANA Considerations</name>
- <t>
- GANA is requested to amend the "GNUnet Message Type" registry
- as follows:
- </t>
- <figure anchor="figure_purposenums">
- <artwork name="" type="" align="left" alt=""><![CDATA[
+ <section anchor="gana" numbered="true" toc="default">
+ <name>GANA Considerations</name>
+ <t>
+ GANA is requested to amend the "GNUnet Message Type" registry
+ as follows:
+ </t>
+ <figure anchor="figure_purposenums">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
Type | Name | References | Description
--------+-----------------+------------+--------------------------
42 | SETU_IBF_BLAH | [This.I-D] | text here
]]></artwork>
- </figure>
- </section>
- <!-- gana -->
- </middle>
- <back>
- <references>
- <name>Normative References</name>
+ </figure>
+ </section>
+ <!-- gana -->
+ </middle>
+ <back>
+ <references>
+ <name>Normative References</name>
- &RFC1034;
- &RFC1035;
- &RFC2782;
- &RFC2119;
- &RFC3629;
- &RFC3686;
- &RFC3826;
- &RFC3912;
- &RFC5869;
- &RFC5890;
- &RFC5891;
- &RFC6781;
- &RFC6895;
- &RFC6979;
- &RFC7748;
- &RFC8032;
- &RFC8126;
+ &RFC1034;
+ &RFC1035;
+ &RFC2782;
+ &RFC2119;
+ &RFC3629;
+ &RFC3686;
+ &RFC3826;
+ &RFC3912;
+ &RFC5869;
+ &RFC5890;
+ &RFC5891;
+ &RFC6781;
+ &RFC6895;
+ &RFC6979;
+ &RFC7748;
+ &RFC8032;
+ &RFC8126;
- <reference anchor="GANA" target="https://gana.gnunet.org/";>
- <front>
- <title>GNUnet Assigned Numbers Authority (GANA)</title>
- <author><organization>GNUnet e.V.</organization>
- </author>
- <date month="April" year="2020" />
- </front>
- </reference>
+ <reference anchor="GANA" target="https://gana.gnunet.org/";>
+ <front>
+ <title>GNUnet Assigned Numbers Authority (GANA)</title>
+ <author>
+ <organization>GNUnet e.V.</organization>
+ </author>
+ <date month="April" year="2020"/>
+ </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>
- <author initials="M." surname="Wachs" fullname="Matthias Wachs">
- <organization>Technische Universität München</organization>
- </author>
+ <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>
+ <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="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>
- <date year="2014"/>
- </front>
- </reference>
- <reference anchor="R5N"
target="https://doi.org/10.1109/ICNSS.2011.6060022";>
- <front>
- <title>R5N: Randomized recursive routing for restricted-route
networks</title>
- <author initials="N. S." surname="Evans" fullname="Nathan S. Evans">
- <organization>Technische Universität München</organization>
- </author>
+ <author initials="C." surname="Grothoff"
+ fullname="Christian Grothoff">
+ <organization>Technische Universität
München</organization>
+ </author>
+ <date year="2014"/>
+ </front>
+ </reference>
+ <reference anchor="R5N"
target="https://doi.org/10.1109/ICNSS.2011.6060022";>
+ <front>
+ <title>R5N: Randomized recursive routing for
restricted-route networks</title>
+ <author initials="N. S." surname="Evans" fullname="Nathan
S. Evans">
+ <organization>Technische Universität
München</organization>
+ </author>
- <author initials="C." surname="Grothoff"
- fullname="Christian Grothoff">
- <organization>Technische Universität München</organization>
- </author>
- <date year="2011"/>
- </front>
- </reference>
+ <author initials="C." surname="Grothoff"
+ fullname="Christian Grothoff">
+ <organization>Technische Universität
München</organization>
+ </author>
+ <date year="2011"/>
+ </front>
+ </reference>
- <reference anchor="Argon2"
target="https://datatracker.ietf.org/doc/draft-irtf-cfrg-argon2/";>
- <front>
- <title>The memory-hard Argon2 password hash and proof-of-work
function</title>
- <author initials="A." surname="Biryukov" fullname="Alex Biryukov">
- <organization>University of Luxembourg</organization>
- </author>
+ <reference anchor="Argon2"
target="https://datatracker.ietf.org/doc/draft-irtf-cfrg-argon2/";>
+ <front>
+ <title>The memory-hard Argon2 password hash and
proof-of-work function</title>
+ <author initials="A." surname="Biryukov" fullname="Alex
Biryukov">
+ <organization>University of Luxembourg</organization>
+ </author>
- <author initials="D." surname="Dinu" fullname="Daniel Dinu">
- <organization>University of Luxembourg</organization>
- </author>
+ <author initials="D." surname="Dinu" fullname="Daniel
Dinu">
+ <organization>University of Luxembourg</organization>
+ </author>
- <author initials="D." surname="Khovratovich"
- fullname="Dmitry Khovratovich">
- <organization>ABDK Consulting</organization>
- </author>
- <author initials="S." surname="Josefsson"
- fullname="Simon Josefsson">
- <organization>SJD AB</organization>
- </author>
- <date year="2020" month="March"/>
- <abstract>
- <t>
- This document describes the Argon2 memory-hard function for
- password hashing and proof-of-work applications. We provide an
- implementer-oriented description with
- test vectors. The purpose is to simplify adoption of Argon2 for
- Internet protocols. This document is a product of the Crypto Forum
Research Group (CFRG)
- in the IRTF.
- </t>
- </abstract>
- </front>
- </reference>
- <reference anchor="MODES"
target="https://doi.org/10.6028/NIST.SP.800-38A";>
- <front>
- <title>Recommendation for Block Cipher Modes of Operation: Methods
and Techniques</title>
- <author initials="M." surname="Dworkin" fullname="Morris Dworkin">
- <organization>NIST</organization>
- </author>
+ <author initials="D." surname="Khovratovich"
+ fullname="Dmitry Khovratovich">
+ <organization>ABDK Consulting</organization>
+ </author>
+ <author initials="S." surname="Josefsson"
+ fullname="Simon Josefsson">
+ <organization>SJD AB</organization>
+ </author>
+ <date year="2020" month="March"/>
+ <abstract>
+ <t>
+ This document describes the Argon2 memory-hard
function for
+ password hashing and proof-of-work applications.
We provide an
+ implementer-oriented description with
+ test vectors. The purpose is to simplify adoption
of Argon2 for
+ Internet protocols. This document is a product of
the Crypto Forum Research Group (CFRG)
+ in the IRTF.
+ </t>
+ </abstract>
+ </front>
+ </reference>
+ <reference anchor="MODES"
target="https://doi.org/10.6028/NIST.SP.800-38A";>
+ <front>
+ <title>Recommendation for Block Cipher Modes of Operation:
Methods and Techniques</title>
+ <author initials="M." surname="Dworkin" fullname="Morris
Dworkin">
+ <organization>NIST</organization>
+ </author>
- <date year="2001" month="December"/>
- <abstract>
- <t>
- This recommendation defines five confidentiality modes of
operation for use with an underlying symmetric key block cipher algorithm:
Electronic Codebook (ECB), Cipher Block Chaining (CBC), Cipher Feedback (CFB),
Output Feedback (OFB), and Counter (CTR). Used with an underlying block cipher
algorithm that is approved in a Federal Information Processing Standard (FIPS),
these modes can provide cryptographic protection for sensitive, but
unclassified, computer data.
- </t>
- </abstract>
- </front>
- </reference>
- <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>
+ <date year="2001" month="December"/>
+ <abstract>
+ <t>
+ This recommendation defines five confidentiality
modes of operation for use with an
+ underlying symmetric key block cipher algorithm:
Electronic Codebook (ECB), Cipher Block
+ Chaining (CBC), Cipher Feedback (CFB), Output
Feedback (OFB), and Counter (CTR). Used with
+ an underlying block cipher algorithm that is
approved in a Federal Information Processing
+ Standard (FIPS), these modes can provide
cryptographic protection for sensitive, but
+ unclassified, computer data.
+ </t>
+ </abstract>
+ </front>
+ </reference>
+ <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 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="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="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>
+ <author initials="B." surname="Yang"
+ fullname="Bo-Yin Yang">
+ <organization>Academia Sinica</organization>
- </author>
- <date year="2011"/>
- </front>
- </reference>
+ </author>
+ <date year="2011"/>
+ </front>
+ </reference>
- <!-- <reference anchor="ISO20022">
- <front>
- <title>ISO 20022 Financial Services - Universal financial industry
message scheme</title>
- <author>
- <organization>International Organization for
Standardization</organization>
- <address>
- <uri>http://www.iso.ch</uri>
- </address>
- </author>
- <date month="May" year="2013"/>
- </front>
- </reference>-->
- </references>
- <!-- Change Log
- v00 2017-07-23 MS Initial version
- -->
- </back>
- </rfc>
+ <!-- <reference anchor="ISO20022">
+ <front>
+ <title>ISO 20022 Financial Services - Universal financial
industry message scheme</title>
+ <author>
+ <organization>International Organization for
Standardization</organization>
+ <address>
+ <uri>http://www.iso.ch</uri>
+ </address>
+ </author>
+ <date month="May" year="2013"/>
+ </front>
+ </reference>-->
+ </references>
+ <!-- Change Log
+ v00 2017-07-23 MS Initial version
+ -->
+ </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: Rearanget the code,
gnunet <=