Figure 1. The pictured element types correspond to discrete client and server programs that Katzenpost requires to function.
- 
+ 
Figure 1. The pictured element types correspond to discrete client and server programs that Katzenpost requires to function.
The mix network contains an n-layer topology of mix-nodes, with three nodes per layer in this example. Sphinx packets traverse the network in one @@ -118,7 +118,7 @@ provides multiplexing and privilege separation with a consequent reduction in processing overhead. These clients also implement the Pigeonhole storage and BACAP protocols detailed in Place-holder for research paper link.
-The following client applications are available.
Table 1. Katzenpost clients
The following client applications are available.
Table 1. Katzenpost clients
|
Name @@ -178,7 +178,7 @@katzenpost/docker/dirauth_mixnet/auth1/authority.toml. In a
real-world mixnet, the component hosts would not be sharing a single IP address. For
more information about the test mixnet, see ???.
- Table 2. Directory authority (dirauth) configuration
+ Table 2. Directory authority (dirauth) configuration
sections The The
- Table 3. Mix node configuration sections Table 3. Mix node configuration sections The The The The The Table 4. Gateway node configuration sections Table 4. Gateway node configuration sections The The The The The Table 5. Mix node configuration sections Table 5. Mix node configuration sections The The The The The Table of Contents Table of Contents Katzenpost provides a ready-to-deploy Docker
@@ -346,7 +346,7 @@
gray blocks represent nodes, and the arrows represent information transfer. On the left, the Client transmits a message (shown by
purple arrows) through the Gateway node, across three
@@ -363,7 +363,7 @@
the following table. Note that all nodes share the same IP address (127.0.0.1, i.e.,
localhost), but are accessed through different ports. Each node type links to additional
information in ???. Table 2. Table 2: Test mixnet hosts Table 2. Table 2: Test mixnet hosts 30012 The following tree
output shows the location, relative to the Abstract Abstract Here I present a modification of the Sphinx cryptographic packet
-format that uses a KEM instead of a NIKE whilst preserving the
-properties of bitwise unlinkability, constant packet size and route
-length hiding. We’ll express our KEM Sphinx header in pseudo code. The Sphinx body
-will be exactly the same as SPHINXSPEC. Our
-basic KEM API has three functions: Additional notation includes: Therefore we must embed these KEM ciphertexts in the KEMSphinx
-header, one KEM ciphertext per mix hop. Special care must be taken in order correctly compose a hybrid post
-quantum KEM that is IND-CCA2 robust. The hybrid post quantum KEMs found in Cloudflare’s circl library are
-suitable to be used with Noise or TLS but not with KEM Sphinx because
-they are not IND-CCA2 robust. Noise and TLS achieve IND-CCA2 security by
-mixing in the public keys and ciphertexts into the hash object and
-therefore do not require an IND-CCA2 KEM. Firstly, our post quantum KEM is IND-CCA2 however we must
-specifically take care to make our NIKE to KEM adapter have semantic
-security. Secondly, we must make a security preserving KEM combiner. We easily achieve our IND-CCA2 security by means of hashing together
-the DH shared secret along with both of the public keys: Table of Contents
+ Abstract
+
+ Here I present a modification of the Sphinx cryptographic packet
+ format that uses a KEM instead of a NIKE whilst preserving the
+ properties of bitwise unlinkability, constant packet size and route
+ length hiding.
+
+ We’ll express our KEM Sphinx header in pseudo code. The Sphinx
+ body will be exactly the same as
+ SPHINXSPEC Our basic KEM API
+ has three functions:
+
+
+
+
+ Additional notation includes:
+
+
+
+ Therefore we must embed these KEM ciphertexts in the KEMSphinx
+ header, one KEM ciphertext per mix hop.
+
+ Special care must be taken in order correctly compose a hybrid
+ post quantum KEM that is IND-CCA2 robust.
+
+ The hybrid post quantum KEMs found in Cloudflare’s circl library
+ are suitable to be used with Noise or TLS but not with KEM Sphinx
+ because they are not IND-CCA2 robust. Noise and TLS achieve
+ IND-CCA2 security by mixing in the public keys and ciphertexts
+ into the hash object and therefore do not require an IND-CCA2 KEM.
+
+ Firstly, our post quantum KEM is IND-CCA2 however we must
+ specifically take care to make our NIKE to KEM adapter have
+ semantic security. Secondly, we must make a security preserving
+ KEM combiner.
+
+ We easily achieve our IND-CCA2 security by means of hashing
+ together the DH shared secret along with both of the public
+ keys:
+ The KEM Combiners paper KEMCOMB makes the
-observation that if a KEM combiner is not security preserving then the
-resulting hybrid KEM will not have IND-CCA2 security if one of the
-composing KEMs does not have IND-CCA2 security. Likewise the paper
-points out that when using a security preserving KEM combiner, if only
-one of the composing KEMs has IND-CCA2 security then the resulting
-hybrid KEM will have IND-CCA2 security. Our KEM combiner uses the split PRF design from the paper when
-combining two KEM shared secrets together we use a hash function to also
-mix in the values of both KEM ciphertexts. In this pseudo code example
-we are hashing together the two shared secrets from the two underlying
-KEMs, ss1 and ss2. Additionally the two ciphertexts from the underlying
-KEMs, cct1 and cct2, are also hashed together:
+ The KEM Combiners paper KEMCOMB
+ makes the observation that if a KEM combiner is not security
+ preserving then the resulting hybrid KEM will not have IND-CCA2
+ security if one of the composing KEMs does not have IND-CCA2
+ security. Likewise the paper points out that when using a
+ security preserving KEM combiner, if only one of the composing
+ KEMs has IND-CCA2 security then the resulting hybrid KEM will
+ have IND-CCA2 security.
+
+ Our KEM combiner uses the split PRF design from the paper when
+ combining two KEM shared secrets together we use a hash function
+ to also mix in the values of both KEM ciphertexts. In this
+ pseudo code example we are hashing together the two shared
+ secrets from the two underlying KEMs, ss1 and ss2. Additionally
+ the two ciphertexts from the underlying KEMs, cct1 and cct2, are
+ also hashed together:
+ Which simplifies to: The Split PRF can be used to combine an arbitrary number of KEMs.
-Here’s what it looks like with three KEMs:
+ Which simplifies to:
+
+ The Split PRF can be used to combine an arbitrary number of
+ KEMs. Here’s what it looks like with three KEMs:
+ NIKE Sphinx header elements: KEM Sphinx header elements: We can say that KEMSphinx differs from NIKE Sphinx by replacing the
-header’s group element (e.g. an X25519 public key) field with the KEM
-ciphertext. Subsequent KEM ciphertexts for each hop are stored inside
-the Sphinx header “routing information” section. First we must have a data type to express a mix hop, and we can use
-lists of these hops to express a route:
+ NIKE Sphinx header elements:
+
+ Version number (MACed but not encrypted)
+
+ Group element
+
+ Encrypted per routing commands
+
+ MAC for this hop (authenticates header fields 1 thru 4)
+
+ KEM Sphinx header elements:
+
+ Version number (MACed but not encrypted)
+
+ One KEM ciphertext for use with the next hop
+
+ Encrypted per routing commands AND KEM ciphtertexts, one for
+ each additional hop
+
+ MAC for this hop (authenticates header fields 1 thru 4)
+
+ We can say that KEMSphinx differs from NIKE Sphinx by replacing
+ the header’s group element (e.g. an X25519 public key) field with
+ the KEM ciphertext. Subsequent KEM ciphertexts for each hop are
+ stored inside the Sphinx header “routing information”
+ section.
+
+ First we must have a data type to express a mix hop, and we can
+ use lists of these hops to express a route:
+ Here’s how we construct a KEMSphinx packet header where path is a
-list of PathHop, and indicates the route through the network:
+ Here’s how we construct a KEMSphinx packet header where path is a
+ list of PathHop, and indicates the route through the network:
+
+ Derive the KEM ciphertexts for each hop.
+ Same as in SPHINXSPEC except for the fact
-that each routing info slot is now increased by the size of the KEM
-ciphertext. Here we modify the Sphinx implementation to pack the next KEM
-ciphertext into each routing information block. Each of these blocks is
-decrypted for each mix mix hop which will decrypt the KEM ciphertext for
-the next hop in the route.
+ Derive the routing_information keystream and encrypted padding
+ for each hop.
+
+ Same as in SPHINXSPEC except for
+ the fact that each routing info slot is now increased by the size
+ of the KEM ciphertext.
+
+ Create the routing_information block.
+
+ Here we modify the Sphinx implementation to pack the next KEM
+ ciphertext into each routing information block. Each of these
+ blocks is decrypted for each mix mix hop which will decrypt the
+ KEM ciphertext for the next hop in the route.
+
+ Assemble the completed Sphinx Packet Header and Sphinx Packet
+ Payload SPRP key vector. Same as in
+ SPHINXSPEC except the
+ Most of the design here will be exactly the same as in SPHINXSPEC. However there are a few notable
-differences: I would like to thank Peter Schwabe for the original idea of simply
-replacing the Sphinx NIKE with a KEM and for answering all my questions.
-I’d also like to thank Bas Westerbaan for answering questions. KEMCOMB SPHINX09 SPHINXSPEC
+ Most of the design here will be exactly the same as in
+ SPHINXSPEC. However there are a
+ few notable differences:
+
+ The shared secret is derived from the KEM ciphertext instead
+ of a DH.
+
+ Next hop’s KEM ciphertext stored in the encrypted routing
+ information.
+
+ I would like to thank Peter Schwabe for the original idea of
+ simply replacing the Sphinx NIKE with a KEM and for answering
+ all my questions. I’d also like to thank Bas Westerbaan for
+ answering questions.
+ KEMCOMB. Federico Giacon, Felix Heuer, Bertram Poettering, "KEM Combiners", 2018.
+ https://link.springer.com/chapter/10.1007/978-3-319-76578-5_7 SPHINX09. Danezis, G., Goldberg, I., "Sphinx: A Compact and Provably Secure Mix
+ Format\", DOI 10.1109/SP.2009.15, May 2009. https://cypherpunks.ca/~iang/pubs/Sphinx_Oakland09.pdf SPHINXSPEC. Angel, Y., Danezis, G., Diaz, C., Piotrowska, A., Stainton, D., "Sphinx Mix
+ Network Cryptographic Packet Format Specification" July 2017. https://katzenpost.network/docs/specs/sphinx/ Abstract This document defines the Katzenpost Mix Network Wire Protocol for
-use in all network communications to, from, and within the Katzenpost
-Mix Network. The Katzenpost Mix Network Wire Protocol (KMNWP) is the custom wire
-protocol for all network communications to, from, and within the
-Katzenpost Mix Network. This protocol provides mutual authentication,
-and an additional layer of cryptographic security and forward
-secrecy. 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 RFC2119. The “C” style Presentation Language as described in RFC5246 Section 4 is used to represent data
-structures, except for cryptographic attributes, which are specified as
-opaque byte vectors. This protocol uses ANY Key Encapsulation Mechanism. However it’s
-recommended that most users select a hybrid post quantum KEM such as
-Xwing. XWING The protocol is based on Kyber and Trevor Perrin’s Noise Protocol
-Framework NOISE along with “Post Quantum Noise”
-paper PQNOISE. Older previous versions of our
-transport were based on NOISEHFS. Our transport protocol begins with a prologue, Noise handshake,
-followed by a stream of Noise Transport messages in a minimal framing
-layer, over a TCP/IP connection. Our Noise protocol is configurable via the KEM selection in the TOML
-configuration files, here’s an example PQ Noise protocol string: The protocol string is a very condensed description of our protocol.
-We use the pqXX two way Noise pattern which is described as follows: The next part of the protocol string specifies the KEM,
- Finally the As a non-standard modification to the Noise protocol, the 65535 byte
-message length limit is increased to 1300000 bytes. We send very large
-messages over our Noise protocol because of our using the Sphincs+
-signature scheme which has signatures that are about 49k bytes. It is assumed that all parties using the KMNWP protocol have a fixed
-long or short lived All sessions start in the Handshake Phase, in which an anonymous
-authenticated handshake is conducted. The handshake is a unmodified Noise handshake, with a fixed prologue
-prefacing the initiator's first Noise handshake message. This prologue
-is also used as the The prologue is defined to be the following structure: Table of Contents
+ Abstract
+
+ This document defines the Katzenpost Mix Network Wire Protocol for
+ use in all network communications to, from, and within the
+ Katzenpost Mix Network.
+
+ The Katzenpost Mix Network Wire Protocol (KMNWP) is the custom
+ wire protocol for all network communications to, from, and within
+ the Katzenpost Mix Network. This protocol provides mutual
+ authentication, and an additional layer of cryptographic security
+ and forward secrecy.
+
+ 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 RFC2119.
+
+ The “C” style Presentation Language as described in
+ RFC5246 Section 4 is used to
+ represent data structures, except for cryptographic attributes,
+ which are specified as opaque byte vectors.
+
+
+ This protocol uses ANY Key Encapsulation Mechanism. However it’s
+ recommended that most users select a hybrid post quantum KEM
+ such as Xwing. XWING
+
+ The protocol is based on Kyber and Trevor Perrin’s Noise Protocol
+ Framework NOISE along with
+ “Post Quantum Noise” paper
+ PQNOISE. Older previous versions of
+ our transport were based on
+ NOISEHFS.
+
+ Our transport protocol begins with a prologue, Noise handshake,
+ followed by a stream of Noise Transport messages in a minimal
+ framing layer, over a TCP/IP connection.
+
+ Our Noise protocol is configurable via the KEM selection in the
+ TOML configuration files, here’s an example PQ Noise protocol
+ string:
+
+ The protocol string is a very condensed description of our
+ protocol. We use the pqXX two way Noise pattern which is described
+ as follows:
+
+ The next part of the protocol string specifies the KEM,
+
+ Finally the
+ As a non-standard modification to the Noise protocol, the 65535
+ byte message length limit is increased to 1300000 bytes. We send
+ very large messages over our Noise protocol because of our using
+ the Sphincs+ signature scheme which has signatures that are about
+ 49k bytes.
+
+ It is assumed that all parties using the KMNWP protocol have a
+ fixed long or short lived
+ All sessions start in the Handshake Phase, in which an anonymous
+ authenticated handshake is conducted.
+
+ The handshake is a unmodified Noise handshake, with a fixed
+ prologue prefacing the initiator's first Noise handshake
+ message. This prologue is also used as the
+
+ The prologue is defined to be the following structure:
+ As all Noise handshake messages are fixed sizes, no additional
-framing is required for the handshake. Implementations MUST preserve the Noise handshake hash
- Implementations MUST reject handshake attempts by terminating the
-session immediately upon any Noise protocol handshake failure and when,
-as a responder, they receive a Prologue containing an unknown
-protocol_version value. Implementations SHOULD impose reasonable timeouts for the handshake
-process, and SHOULD terminate sessions that are taking too long to
-handshake. Mutual authentication is done via exchanging fixed sized payloads as
-part of the
+ As all Noise handshake messages are fixed sizes, no additional
+ framing is required for the handshake.
+
+ Implementations MUST preserve the Noise handshake hash
+
+ Implementations MUST reject handshake attempts by terminating
+ the session immediately upon any Noise protocol handshake
+ failure and when, as a responder, they receive a Prologue
+ containing an unknown protocol_version value.
+
+ Implementations SHOULD impose reasonable timeouts for the
+ handshake process, and SHOULD terminate sessions that are taking
+ too long to handshake.
+
+ Mutual authentication is done via exchanging fixed sized
+ payloads as part of the Where: The initiator MUST send the The contents of the optional To authenticate the remote peer given an AuthenticateMessage, the
-receiving peer must validate the If the validation procedure succeeds, the peer is considered
-authenticated. If the validation procedure fails for any reason, the
-session MUST be terminated immediately. Responders MAY add a slight amount (+- 10 seconds) of random noise to
-the unix_time value to avoid leaking precise load information via packet
-queueing delay. Upon successfully concluding the handshake the session enters the
-Data Transfer Phase, where the initiator and responder can exchange
-KMNWP messages. A KMNWP message is defined to be the following structure:
+ Where:
+
+
+
+
+ The initiator MUST send the
+
+ The contents of the optional
+ To authenticate the remote peer given an AuthenticateMessage,
+ the receiving peer must validate the
+ If the validation procedure succeeds, the peer is considered
+ authenticated. If the validation procedure fails for any reason,
+ the session MUST be terminated immediately.
+
+ Responders MAY add a slight amount (+- 10 seconds) of random
+ noise to the unix_time value to avoid leaking precise load
+ information via packet queueing delay.
+
+ Upon successfully concluding the handshake the session enters
+ the Data Transfer Phase, where the initiator and responder can
+ exchange KMNWP messages.
+
+ A KMNWP message is defined to be the following structure:
+ Notes: All outgoing Message(s) are encrypted and authenticated into a pair
-of Noise Transport messages, each containing one of the following
-structures:
+ Notes:
+
+ The padding field, if any MUST be padded with
+
+ All outgoing Message(s) are encrypted and authenticated into a
+ pair of Noise Transport messages, each containing one of the
+ following structures:
+ Notes: All outgoing Message(s) are preceded by a Noise Transport Message
-containing a To receive incoming Ciphertext messages, first the Noise Transport
-Message containing the CiphertextHeader is consumed off the network,
-authenticated and decrypted, giving the receiver the length of the Noise
-Transport Message containing the actual message itself. The second Noise
-Transport Message is consumed off the network, authenticated and
-decrypted, with the resulting message being returned to the caller for
-processing. After receiving both Noise Transport Messages, the receiver
-MUST call the Noise CipherState Implementations MUST immediately terminate the session any of the
- Implementations MUST immediately terminate the session if an unknown
-command is received in a Message, or if the Message is otherwise
-malformed in any way. Implementations MAY impose a reasonable idle timeout, and terminate
-the session if it expires. The Implementations MUST NOT send any message payload accompanying this
-command, and all received command data MUST be discarded without
-interpretation. The While most implementations will likely wish to terminate the session
-upon receiving this command, any additional behavior is explicitly left
-up to the implementation and application. Implementations MUST NOT send any message payload accompanying this
-command, and MUST not send any further traffic after sending a
-disconnect command. The Initiators MUST terminate the session immediately upon reception of a
- We use traffic padding to hide from a passive network observer which
-command has been sent or received. Among the set of padded commands we exclude the
- GetConsensus NoOp Disconnect SendPacket RetrieveMessage MessageACK
-Message MessageEmpty However we split them up into two directions, client to server and
-server to client because they differ in size due to the difference in
-size between Client to Server commands: NoOp SendPacket Disconnect RetrieveMessage GetConsensus Server to client commands: Message MessageACK MessageEmpty The Adversaries being able to determine that two parties are
-communicating via KMNWP is beyond the threat model of this protocol. At
-a minimum, it is trivial to determine that a KMNWP handshake is being
-performed, due to the length of each handshake message, and the fixed
-positions of the various public keys. It is imperative that implementations use ephemeral keys for every
-handshake as the security properties of the Kyber KEM are totally lost
-if keys are ever reused. Kyber was chosen as the KEM algorithm due to it’s conservative
-parameterization, simplicty of implementation, and high performance in
-software. It is hoped that the addition of a quantum resistant algorithm
-will provide forward secrecy even in the event that large scale quantum
-computers are applied to historical intercepts. I would like to thank Trevor Perrin for providing feedback during the
-design of this protocol, and answering questions regarding Noise. Note that the following bibtex entry is in the IEEEtran bibtex style
-as described in a document called “How to Use the IEEEtran BIBTEX
-Style”.
+ Notes:
+
+ The
+ All outgoing Message(s) are preceded by a Noise Transport
+ Message containing a
+ To receive incoming Ciphertext messages, first the Noise
+ Transport Message containing the CiphertextHeader is consumed
+ off the network, authenticated and decrypted, giving the
+ receiver the length of the Noise Transport Message containing
+ the actual message itself. The second Noise Transport Message is
+ consumed off the network, authenticated and decrypted, with the
+ resulting message being returned to the caller for processing.
+ After receiving both Noise Transport Messages, the receiver MUST
+ call the Noise CipherState
+ Implementations MUST immediately terminate the session any of
+ the
+ Implementations MUST immediately terminate the session if an
+ unknown command is received in a Message, or if the Message is
+ otherwise malformed in any way.
+
+ Implementations MAY impose a reasonable idle timeout, and
+ terminate the session if it expires.
+
+ The
+ Implementations MUST NOT send any message payload accompanying
+ this command, and all received command data MUST be discarded
+ without interpretation.
+
+ The
+ While most implementations will likely wish to terminate the
+ session upon receiving this command, any additional behavior is
+ explicitly left up to the implementation and application.
+
+ Implementations MUST NOT send any message payload accompanying
+ this command, and MUST not send any further traffic after
+ sending a disconnect command.
+
+ The
+ Initiators MUST terminate the session immediately upon reception
+ of a
+ We use traffic padding to hide from a passive network observer
+ which command has been sent or received.
+
+ Among the set of padded commands we exclude the
+
+ GetConsensus NoOp Disconnect SendPacket RetrieveMessage MessageACK
+ Message MessageEmpty
+
+ However we split them up into two directions, client to server and
+ server to client because they differ in size due to the difference
+ in size between
+ Client to Server commands:
+
+ NoOp SendPacket Disconnect RetrieveMessage GetConsensus
+
+ Server to client commands:
+
+ Message MessageACK MessageEmpty
+
+ The
+ Adversaries being able to determine that two parties are
+ communicating via KMNWP is beyond the threat model of this
+ protocol. At a minimum, it is trivial to determine that a KMNWP
+ handshake is being performed, due to the length of each handshake
+ message, and the fixed positions of the various public keys.
+
+ It is imperative that implementations use ephemeral keys for every
+ handshake as the security properties of the Kyber KEM are totally
+ lost if keys are ever reused.
+
+ Kyber was chosen as the KEM algorithm due to it’s conservative
+ parameterization, simplicty of implementation, and high
+ performance in software. It is hoped that the addition of a
+ quantum resistant algorithm will provide forward secrecy even in
+ the event that large scale quantum computers are applied to
+ historical intercepts.
+
+ I would like to thank Trevor Perrin for providing feedback during
+ the design of this protocol, and answering questions regarding
+ Noise.
+
+ Note that the following bibtex entry is in the IEEEtran bibtex
+ style as described in a document called “How to Use the
+ IEEEtran BIBTEX Style”.
+ XWING Manuel Barbosa, Deirdre Connolly, JoĂŁo Diogo Duarte, Aaron Kaiser,
-Peter Schwabe, Karoline Varner, Bas Westerbaan “X-Wing: The Hybrid KEM
-You’ve Been Looking For”, https://eprint.iacr.org/2024/039.pdf NOISE Perrin, T., “The Noise Protocol Framework”, May 2017,
-https://noiseprotocol.org/noise.pdf NOISEHFS Weatherley, R., “Noise Extension: Hybrid Forward Secrecy”,
-https://github.com/noiseprotocol/noise_hfs_spec/blob/master/output/noise_hfs.pdf PQNOISE Yawning Angel, Benjamin Dowling, Andreas HĂĽlsing, Peter Schwabe and
-Florian Weber, “Post Quantum Noise”, 2022,
-https://eprint.iacr.org/2022/539.pdf RFC2119 Bradner, S., “Key words for use in RFCs to Indicate Requirement
-Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
-https://www.rfc-editor.org/info/rfc2119 RFC5246 Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS)
-Protocol Version 1.2”, RFC 5246, DOI 10.17487/RFC5246, August 2008,
-https://www.rfc-editor.org/info/rfc5246 RFC7748 Langley, A., Hamburg, M., and S. Turner, “Elliptic Curves for
-Security”, RFC 7748, DOI 10.17487/RFC7748, January 2016,
-http://www.rfc-editor.org/info/rfc7748 XWING. Manuel Barbosa, Deirdre Connolly, João Diogo Duarte, Aaron Kaiser, Peter Schwabe,
+ Karoline Varner, Bas Westerbaan, “X-Wing: The Hybrid KEM You’ve Been Looking
+ For”. https://eprint.iacr.org/2024/039.pdf NOISE. Perrin, T., “The Noise Protocol Framework”, May 2017. https://noiseprotocol.org/noise.pdf NOISEHFS. Weatherley, R., “Noise Extension: Hybrid Forward Secrecy”. https://github.com/noiseprotocol/noise_hfs_spec/blob/master/output/noise_hfs.pdf PQNOISE. Yawning Angel, Benjamin Dowling, Andreas Hülsing, Peter Schwabe and Florian Weber,
+ “Post Quantum Noise”, September 2023. https://eprint.iacr.org/2022/539.pdf RFC2119. Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”,
+ BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. https://www.rfc-editor.org/info/rfc2119 RFC5246. Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version
+ 1.2”, RFC 5246, DOI 10.17487/RFC5246, August 2008. https://www.rfc-editor.org/info/rfc5246
+ RFC7748. Langley, A., Hamburg, M., and S. Turner, “Elliptic Curves for Security”,
+ RFC 7748, DOI 10.17487/RFC7748, January 2016. http://www.rfc-editor.org/info/rfc7748 |
|---|
