Add documentation

doc/pqcrypto_integration.bib

+@techreport{driscoll-pqt-hybrid-terminology-00,
+    number =    {draft-driscoll-pqt-hybrid-terminology-00},
+    type =      {Internet-Draft},
+    institution =   {Internet Engineering Task Force},
+    publisher = {Internet Engineering Task Force},
+    note =      {Work in Progress},
+    url =       {https://datatracker.ietf.org/doc/draft-driscoll-pqt-hybrid-terminology/00/},
+    author =    {Florence Driscoll},
+    title =     {{Terminology for Post-Quantum Traditional Hybrid Schemes}},
+    pagetotal = 10,
+    year =      2022,
+    month =     jul,
+    day =       8,
+    abstract =  {One aspect of the transition to post-quantum algorithms in cryptographic protocols is the development of hybrid schemes that incorporate both post-quantum and traditional asymmetric algorithms. This document defines terminology for such schemes. It is intended to ensure consistency and clarity across different protocols, standards, and organisations.},
+}
+@misc{rfc9180,
+    series =    {Request for Comments},
+    number =    9180,
+    howpublished =  {RFC 9180},
+    publisher = {RFC Editor},
+    doi =       {10.17487/RFC9180},
+    url =       {https://www.rfc-editor.org/info/rfc9180},
+    author =    {Richard Barnes and Karthikeyan Bhargavan and Benjamin Lipp and Christopher A. Wood},
+    title =     {{Hybrid Public Key Encryption}},
+    pagetotal = 107,
+    year =      2022,
+    month =     feb,
+    abstract =  {This document describes a scheme for hybrid public key encryption (HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes three authenticated variants, including one that authenticates possession of a pre-shared key and two optional ones that authenticate possession of a key encapsulation mechanism (KEM) private key. HPKE works for any combination of an asymmetric KEM, key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. Some authenticated variants may not be supported by all KEMs. We provide instantiations of the scheme using widely used and efficient primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation function (HKDF), and SHA2. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.},
+}
+
+@inproceedings{Bin18,
+  author = {Nina Bindel and Jacqueline Brendel and Marc Fischlin and Brian Goncalves and Douglas Stebila},
+  title  = {{Hybrid key encapsulation mechanisms and authenticated key exchange}},
+  url    = {https://eprint.iacr.org/2018/903.pdf},
+  year   = 2019,
+  month  = may,
+  pages  = {206--226},
+  booktitle = {Proc. 10th International Conference on Post-Quantum Cryptography (PQCrypto)},
+}
+
+@misc{rfc6189,
+    series =    {Request for Comments},
+    number =    6189,
+    howpublished =  {RFC 6189},
+    publisher = {RFC Editor},
+    doi =       {10.17487/RFC6189},
+    url =       {https://www.rfc-editor.org/info/rfc6189},
+    author =    {Philip Zimmermann and Alan Johnston and Jon Callas},
+    title =     {{ZRTP: Media Path Key Agreement for Unicast Secure RTP}},
+    pagetotal = 115,
+    year =      2011,
+    month =     apr,
+    abstract =  {This document defines ZRTP, a protocol for media path Diffie-Hellman exchange to agree on a session key and parameters for establishing unicast Secure Real-time Transport Protocol (SRTP) sessions for Voice over IP (VoIP) applications. The ZRTP protocol is media path keying because it is multiplexed on the same port as RTP and does not require support in the signaling protocol. ZRTP does not assume a Public Key Infrastructure (PKI) or require the complexity of certificates in end devices. For the media session, ZRTP provides confidentiality, protection against man-in-the-middle (MiTM) attacks, and, in cases where the signaling protocol provides end-to-end integrity protection, authentication. ZRTP can utilize a Session Description Protocol (SDP) attribute to provide discovery and authentication through the signaling channel. To provide best effort SRTP, ZRTP utilizes normal RTP/AVP (Audio-Visual Profile) profiles. ZRTP secures media sessions that include a voice media stream and can also secure media sessions that do not include voice by using an optional digital signature. This document is not an Internet Standards Track specification; it is published for informational purposes.},
+}
+
+@misc{liboqs,
+  author = {Douglas Stebila and Michele Mosca},
+  title = {{Post-quantum key exchange for the Internet and the Open Quantum Safe project}},
+  year = 2017,
+  month = oct,
+  booktitle = {Selected Areas in Cryptography (SAC) 2016},
+  url = {https://github.com/open-quantum-safe/liboqs},
+}
+
+@misc{libdecaf,
+  author = {Mike Hamburg},
+  title =  {Ed448-Goldilocks},
+  year = 2014,
+  url ={https://sourceforge.net/projects/ed448goldilocks/},
+  }
+
+@misc{lime,
+  author = {Johan Pascal},
+  title = {{Linphone Instant Message Encryption v2.0}},
+  institution = {Belledonne Communications},
+  number = {Revision 1},
+  year = 2019,
+  month = mar,
+  url = {https://gitlab.linphone.org/BC/public/lime/blob/master/lime.pdf},
+}
+
+@misc{rfc7748,
+    series =    {Request for Comments},
+    number =    7748,
+    howpublished =  {RFC 7748},
+    publisher = {RFC Editor},
+    doi =       {10.17487/RFC7748},
+    url =       {https://www.rfc-editor.org/info/rfc7748},
+    author =    {Adam Langley and Mike Hamburg and Sean Turner},
+    title =     {{Elliptic Curves for Security}},
+    pagetotal = 22,
+    year =      2016,
+    month =     jan,
+    abstract =  {This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the \textasciitilde{}128-bit and \textasciitilde{}224-bit security level, respectively, and are generated deterministically based on a list of required properties.},
+}
+
+@misc{rfc7983,
+    series =    {Request for Comments},
+    number =    7983,
+    howpublished =  {RFC 7983},
+    publisher = {RFC Editor},
+    doi =       {10.17487/RFC7983},
+    url =       {https://www.rfc-editor.org/info/rfc7983},
+        author =    {Marc Petit-Huguenin and Gonzalo Salgueiro},
+    title =     {{Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS)}},
+    pagetotal = 13,
+    year =      2016,
+    month =     sep,
+    abstract =  {This document defines how Datagram Transport Layer Security (DTLS), Real-time Transport Protocol (RTP), RTP Control Protocol (RTCP), Session Traversal Utilities for NAT (STUN), Traversal Using Relays around NAT (TURN), and ZRTP packets are multiplexed on a single receiving socket. It overrides the guidance from RFC 5764 ("SRTP Extension for DTLS"), which suffered from four issues described and fixed in this document. This document updates RFC 5764.},
+}