<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->

<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC4880 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4880.xml">
<!ENTITY RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
<!ENTITY RFC6637 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6637.xml">
<!ENTITY I-D.atkins-openpgp-device-certificates SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.atkins-openpgp-device-certificates.xml">]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-atkins-openpgp-algebraic-eraser-04" ipr="trust200902">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the 
         full title is longer than 39 characters -->

    <title abbrev="AEDH in OpenPGP">Using Algebraic Eraser (AEDH) in OpenPGP</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->

    <author fullname="Derek Atkins" initials="D.A."
            surname="Atkins">
      <organization>SecureRF Corporation</organization>

      <address>
        <postal>
          <street>100 Beard Sawmill Rd, Suite 350</street>

          <!-- Reorder these if your country does things differently -->

          <city>Shelton</city>

          <region>CT</region>

          <code>06484</code>

          <country>US</country>
        </postal>

        <phone>+1 617 623 3745</phone>

        <email>datkins@securerf.com, derek@ihtfp.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <date month="January" year="2015" />

    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill 
         in the current day for you. If only the current year is specified, xml2rfc will fill 
	 in the current day and month for you. If the year is not the current one, it is 
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the 
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to 
	 specify just the year. -->

    <!-- Meta-data Declarations -->

    <area>Security</area>

    <workgroup>Internet Engineering Task Force</workgroup>

    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.  
	 If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->

    <keyword>openpgp</keyword>
    <keyword>algebraic</keyword>
    <keyword>eraser</keyword>
    <keyword>algebraic eraser</keyword>
    <keyword>SecureRF</keyword>
    <keyword>AE</keyword>
    <keyword>AEKAP</keyword>
    <keyword>AEDH</keyword>

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
      <t>The Algebraic Eraser(TM) is an encryption engine that supports, among other configurations, a Diffie-Hellman-like key agreement protocol.  This draft specifies how to encode, store, share, and use Algebraic Eraser Key Agreement Protocol (AEKAP, also called AEDH) keys in OpenPGP.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>The OpenPGP specification in <xref target="RFC4880" /> defines the use of RSA, Elgamal, and DSA public key algorithms.  <xref target="RFC6637" /> adds support for Elliptic Curve Cryptography and specifies the ECDSA and ECDH algorithms.</t>

      <t>The Algebraic Eraser(TM) was first introduced in <xref target="AAGL">Key agreement, the Algebraic Eraser, and lightweight cryptography</xref> published by the American Mathematical Society in 2004.  It describes "a new key agreement protocol suitable for implementation on low-cost platforms which constrain the use of computational resources."  It is further compared to other algorithims in <xref target="AEIntro" />.  This document specifies how to encode, store, and use the Algebraic Eraser Key Agreement Protocol (AEKAP, also called AEDH) in OpenPGP.</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">RFC 2119</xref>.</t>
    </section>

    <section title="The Algebraic Eraser">
      <t>The Algebraic Eraser brings together the Braid Group, Matrices, and operations over small Finite Fields to produce an algorithm that executes linear in time with the increase in key size.</t>

      <t>A complete description of the Algebraic Eraser is available in <xref target="AAGL" />.</t>

      <section title="E-Multiplication" anchor="E-Multiplication">
	<t>The Algebraic Eraser defines an operation called "E-Multiplication" upon which the algorithm is based (see <xref target="AAGL" />).  E-Multiplication (denoted herein by *) takes one matrix (M0) and permutation (S0) and operates on a second matrix (M1) and permutation (S1), resulting in another matrix (M2) and permutation (S2).  In other words:  (M0,S0) * (M1,S1) = (M2,S2).</t>

	<t>The secret to E-multiplication is that you can take a Braid element (an "Artin generator") and map that to a matrix and permutation upon which you can operate.  Specifically, each Artin generator is associated to a specific Colored Burau (CB) matrix and permutation (see <xref target="AAGL" />).  The E-multiplication process involves permuting the variables in the CB matrix using the current permutation, substituting those variables with the TValues from the Keyset (see <xref target="Keyset" />), then multiplying that against the starting matrix resulting in the another matrix.  Then you multiply the permutations, resulting in a new permutation.  This new matrix and permutation is the the result of the E-Multiplication.</t>
      </section>

      <section title="AEDH Keyset Parameters" anchor="Keyset">
	<t>AEDH Keyset Parameters are similar to Diffie-Hellman cyclic groups of prime order or ECC curves.  Just as users must choose the same DH prime or ECC curve in order to communicate, similarly participants in the AEDH must be using the same Keyset Parameters.</t>

	<t>The first basic set of parameters is the chosen Braid Group and Field Size, BnFq, where n is the number of strands in the chosen braid (also called the braid index) and q is the size of the field in use.  The field size, q, must be a power of a prime.  Generally it is 2^r (where r is a small integer) although this is not a requirement.  For example, one might choose B10F8 or B16F32.  This is like choosing how many bits to use when generating a prime for Diffie-Hellman.</t>

	<t>Once the BnFq space is chosen then the Keyset Parameters can be generated by a trusted third party (TTP).  First they generate an n-by-n matrix (M) where each entry in the matrix is a member of the field Fq.  Second, the TTP generates a set of TValues, which is an array of n invertable entries within the field Fq (i.e., values 1 to Fq-1).  Finally, the TTP generates at least two sets of braid conjugates, Ca and Cb, where each conjugate in Ca commutes with each conjugate in Cb.  The conjugates are lists of "braid words", or "Artin generators" within the Bn braid group.  The TTP generates La conjugates for set Ca and Lb conjugates for set Cb, where the numbers La and Lb MAY be different.</t>

	<t>The public Keyset Parameters are the Matrix (M), TValues array, and conjugate sets and must be available to generate keys that can communicate.  Moreover, the TValue array must be available to anyone using the Keyset.  These Keysets MAY be published and named, but MUST be numbered with an OID.</t>

	<t>For two users to execute the AEDH they MUST generate keys from the same Keyset and they MUST choose from different conjugate sets within that Keyset.  I.e., for Alice and Bob to complete the AEDH Alice must generate her key from Ca and Bob must generate his key from Cb.</t>

	<t>This document does not specify any particular Keyset Parameters that MUST be implemented.</t>
      </section>

      <section title="Generating Key Pairs">
	<t>The Algebraic Eraser has a two-part Private Key and a two-part Public Key.  The Public key is then generated from the two Private Keys.</t>

	<t>To generate the 1st private key you generate a random polynomial and apply that to the public matrix from the keyset within the keyset field.  This results in an n-by-n matrix where each entry in the matrix is a member of the field Fq (although the last row of the matrix contains n-1 zeros).  The key search space for the 1st private key is q^(n-1).  Note that the 1st private key permutation is always the identity permutation, so there is no need to store it.</t>

	<t>To generate the 2nd private key you choose a random set of conjugates (and inverses) and string them together.  This results in a long string of Artin generators (and inverses).  You MAY reduce the string if you so choose using the Dehornoy reduction <xref target="Dehornoy" />.  The search space of the 2nd private key is (2l)^k (where l is the number of published conjugates (La or Lb), and k the number of chosen conjugates and inverses).</t>

	<t>The Public Key is computed by an E-Multiplication of the 1st private key and the 2nd private key, where the 2nd private key is iteratively processed  (see <xref target="E-Multiplication" />.  The result (the public key) is an n-by-n matrix of Fq and another permutation.</t>

	<t>Note that the last row of the Public Key Matrix is all zero except for the last entry.  When encoding the Public Key you SHOULD ignore those zeros.</t>
      </section>

      <section title="Computing the Shared Secret">
	<t>To compute the shared secret you first perform regular matrix multiplication of the 1st private key against the matrix component of the public key you receive from the other person. This results in another matrix. The permutation of the 1st private key is the identity, hence the result of multiplying it against the permutation of the public key leaves the permutation of the public key unchanged and you can just use it directly. Then you perform E-multiplication of this matrix/permutation result against the 2nd private key. The resulting matrix/permutation is the shared secret.</t>
      </section>

    </section>

    <section title="Encoding of Public and Private Keys" anchor="encoding">
      <t>Each portion of a key can be reduced to a byte-string (or, more accurately, multiple byte strings).  Each matrix can be encoded by stringing together each field element in each row and then stringing each row together.  A permutation can be encoded by stringing together each element in the list.  The conjugates are also encoded by stringing together each element.</t>

      <t>The following public key algorithm IDs are added to expand section 9.1 of <xref target="RFC4880" />, "Public-Key Algorithms":</t>

        <texttable>
          <ttcol align="center">ID</ttcol>
          <ttcol align="center">Description of Algorithm</ttcol>
          <c>TBD1</c>
          <c>AEDH public key algorithm</c>
        </texttable>

      <t>Encoding of Public and Private keys MUST use the version 4 packet format (or newer).</t>

      <section title="Encoding Bit-Strings">
	<t>The Algebraic eraser uses matrices, fields, and braids that are denoted in bits, particular strings of bits.  These objects need to be encoded into bit strings for storage and transmission.  The most simplistic method of encoding is to take each field as a byte (or multi-byte word) and string them together.  The following sections detail multiple (alternate) ways these bit strings can be encoded to possibly reduce the space used.</t>

	<section title="Encoding Techniques" anchor="encoding_techniques">
	  <t>Depending on the number of bits used per element (which is defined by the braid index and field size), using different encodings of these strings may result in reducing storage space by dropping extra bits and combining elements.</t>

	  <t>For example, when using the finite field F16 each entry can be encoded in exactly one nibble of four (4) bits, so you can easily combine two entries into a single 8-bit byte (called nibble-encoding).  This technique could also be used for entries smaller than a nibble, although then you would still have extra (unused) bits.  When using the nibble-encoding of an odd number of nibbles the encoding rules MUST specify whether the extra nibble is at the leading or trailing byte.</t>

	  <t>Another encoding option is bit-stealing.  This merges all bits together and then cuts it up into 8-bit bytes.  For example if the entries are 5 bits each you might steal 3 bits from the second entry to merge into the first, then shift the remaining 2 bits of the second entry, combine with the next 5 bits from the third, and then steal one bit from the fourth entry, and so on, until you've reached the end.  This could end up with unused bits at the end of the string.</t>

	  <t>Yet another option is the reverse-bit-stealing, where you start at the end of the string and work your way to the front.  This could leave you with unused bits a the front of the string.</t>

	  <t>Assume you require five (5) bits to encode your numbers, the following table shows how you could could use bit stealing and reverse bit stealing to encode them (where a, b, c, and d are the bits in the first, second, third, and fourth entries)</t>

	  <texttable style="all">
	    <ttcol align="right">Full Bytes:</ttcol>
	    <ttcol align="center">000aaaaa</ttcol>
	    <ttcol align="center">000bbbbb</ttcol>
	    <ttcol align="center">000ccccc</ttcol>
	    <ttcol align="center">000ddddd</ttcol>
	    <c>Bit stealing:</c>
	    <c>aaaaabbb</c>
	    <c>bbcccccd</c>
	    <c>dddd0000</c>
	    <c></c>
	    <c>Reverse bit stealing:</c>
	    <c>0000aaaa</c>
	    <c>abbbbbcc</c>
	    <c>cccddddd</c>
	    <c></c>
	  </texttable>

	  <t>Any unused bits MUST be left as zero (and MUST be checked to be zero).</t>

	  <t>The actual encoding method MUST be defined by the Keyset parameter definition and may change from one keyset parameter to another.</t>

	  <t>The row of zeros in the matrix SHOULD be assumed to "not exist".  When using these encoding techniques you SHOULD just tack the last entry of the final row onto the end of the list of entries of the rest of the matrix.  This could result in an odd number of entries depending on your n and q choices potentially requiring passing at the start or end of the bit string.</t>
	</section>

	<section title="Multi-Byte Entries">
	  <t>In the case of entries wider than 8 bits (e.g. a Field parameter greater than 256), the bits are combined in network byte order.  However they can still be merged together using the same encoding algorithms from <xref target="encoding_techniques" /> in the case of entries that are not 8-bit multiples.  For example, a 12-bit field (F4096) could be combined a nibble at a time, or a 10-bit field (F1024) could use bit-stealing.</t>
	</section>
      </section>

      <section title="Encoding Public Keys">
	<t>The following algorithm specific packets are added to Section 5.5.2 of <xref target="RFC4880" />, "Public-Key Packet Formats", to support AEDH:</t>

	<t><list style="symbols">
          <t>a variable length field containing a keyset parameter OID, formatted as follows (see <xref target="RFC6637" /> for a full description of the OID encoding method):
	  <list style="symbols">
	    <t>a one-octet size of the following field; values 0 and 0xFF are reserved for future extensions,</t>
	    <t>octets representing a keyset parameter OID</t>
	  </list></t>

          <t>one byte denoting from which set of conjugates in the keyset this key was generated (e.g. the Alice set or the Bob set)</t>
	  <t>MPI of the public key matrix</t>
	  <t>MPI of the public key permutation</t>
        </list></t>
      </section>

      <section title="Encoding Private Keys">
	<t>The following algorithm specific packets are added to Section 5.5.3 of <xref target="RFC4880" />, "Secret-Key Packet Formats", to support AEDH:</t>

	<t><list style="symbols">
	  <t>MPI of the 1st private key (matrix)</t>
	  <t>MPI of the 2nd private key (conjugate string)</t>
        </list></t>
      </section>

    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The term "Algebraic Eraser" is a trademark of SecureRF Corporation and is used herein with permission.</t>

      <t>The author would like to thank Paul Gunnells, Dorian Goldfeld, and Iris Anshel for their tireless efforts to review this document, suggest improvements, and explain to me how to improve my description of how AE works.  Big thanks also to Werner Koch and Vedaal for their comments and suggestions.</t>
    </section>

    <!-- Possibly a 'Contributors' section ... -->

    <section anchor="IANA" title="IANA Considerations">
      <t>IANA is requested to assign an algorithm number from the OpenPGP Public-Key Algorithms range, or the "namespace" in the terminology of <xref target="RFC5226" />, that was created by <xref target="RFC4880" />.  See <xref target="encoding" />.</t>

      <texttable>
        <ttcol align="center">ID</ttcol>
        <ttcol align="center">Algorithm</ttcol>
        <ttcol align="center">Reference</ttcol>
          <c>TBD1</c>
          <c>AEDH public key algorithm</c>
	  <c>This doc</c>
      </texttable>

      <t>[Notes to RFC-Editor: Please remove the table above on publication. It is desirable not to reuse old or reserved algorithms because some existing tools might print a wrong description.  A higher number is also an indication for a newer algorithm.  As of now 22 is the next free number, but we request the selection of 23.]</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>The security considerations of <xref target="RFC4880" /> apply accordingly.</t>

      <t>AEDH will generate the same session key when used with the same two public/private key pairs.  The authors of AE generally recommend that at least one party use an ephemeral key pair in order to prevent the same session key being generated every time.</t>

      <t>AEDH is an encryption-only algorithm, therefore it cannot self-certify a key.  To have an AEDH master key you MUST implement <xref target="I-D.atkins-openpgp-device-certificates" />.</t>

      <t>When using the generated session key, you MUST only use the bits included in the protocol.  You should MUST NOT use any always-zero bits, including those in the last row of the matrix.</t>
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <references title="Normative References">
      <reference anchor="AAGL" target="http://www.securerf.com/wp-content/uploads/2014/03/SecureRF-Technical-White-Paper-06-with-Appendix-A-B.pdf">
	<!-- Orignal posting: http://www.ams.org/books/conm/418/  -->
        <front>
          <title>Key agreement, the Algebraic Eraser, and lightweight cryptography</title>
          <author initials="I.A." surname="Anshel">
            <organization></organization>
          </author>
          <author initials="M.A." surname="Anshel">
            <organization></organization>
          </author>
          <author initials="D.G." surname="Goldfeld">
            <organization></organization>
          </author>
          <author initials="S.L." surname="Lemieux">
            <organization></organization>
          </author>

          <date year="2004" />
        </front>
	<seriesInfo name="Contemporary Mathematics" value="418" />
      </reference>

      <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
      &RFC2119;

      &RFC4880;

      &RFC5226;

      &RFC6637;

    </references>

    <references title="Informative References">
      <!-- Here we use entities that we defined at the beginning. -->
      <!-- A reference written by by an organization not a person. -->
      &I-D.atkins-openpgp-device-certificates;

      <reference anchor="Dehornoy" target="http://www.math.unicaen.fr/~dehornoy/Papers/Dfo.pdf">
        <front>
          <title>A fast method for comparing braids</title>
          <author initials="P.D." surname="Dehornoy">
          </author>

          <date year="1997" />
        </front>
	<seriesInfo name="Advances in Mathematics" value="123" />
      </reference>

      <reference anchor="AEIntro" target="http://www.securerf.com/wp-content/uploads/2014/04/SecureRF_Security_Intro_White_Paper.pdf">
	<front>
	  <title>An Introduction to Cryptographic Security Methods and Their Role in Securing Low Resource Computing Devices</title>
	  <author initials="SRF" surname="SecureRF Corporation" />
	  <date year="2011" />
	</front>
      </reference>

    </references>

    <section anchor="test-vectors" title="Test Vectors">
      <t>To help implementing this specification a non-normative example is provided.  This example assumes:</t>
	<t><list style="symbols">
	  <t>the algorithm id for AEDH will be 23</t>
	  <t>the keyset OID 1.3.6.1.4.1.44196.1.0.0, which defines:
	  <list style="symbols">
	    <t>the braid/field as B10F8</t>
	    <t>the public key packing is nibble-packed with trailing zeros</t>
	    <t>the 2nd private key is not bit-packed; it uses bit 7 to define "inverse" and bits 3-0 to define the Artin generator.</t>
	    <t>the TValues are: 6 5 4 4 3 2 6 6 3 4</t>
	  </list>
	  and gets encoded with length 11 and the following hex bytes: 2B 06 01 04 01 82 D9 24 01 00 00</t></list></t>

      <section title="Sample key">
	<t>The secret key used for this example is:</t>
	<t>1st Private Key Matrix:</t>
	<figure><artwork>
	  4 2 7 4 1 2 7 7 3 5
	  1 1 5 4 0 5 0 0 3 1
	  2 7 5 3 4 0 6 0 0 4
	  6 1 0 7 4 7 7 4 1 1
	  1 1 7 6 6 2 4 6 5 7
	  7 5 4 1 7 3 7 5 0 7
	  1 6 0 7 3 6 4 2 5 6
	  7 2 3 6 6 6 4 2 7 7
	  3 7 5 2 2 2 0 7 5 2
	                    6
            </artwork></figure>
	<t>2nd Private key (in hex):
	<list><t>06048182030405038484050602830405068283848581020304850687880788098485838482838485838383848506870807080986878888888788058607880908098788078809080987880903048585038484858383848384850607080987880906050607080987878886078809068708098304050607080903040506070809020384050607040506070883848485858384838485858687068708010203040506070809858687888885858683848585818282828282818182820304858687880908090708060708098485858686028304058686860182030485858687878787080809810203848586010203040586070887878787878708818182838485868708060707060606070607080909060788098809068788090708878708098687880909060708098788868787888807880607880986878888888687878888878788880788098788060788090906870807080909868687880707880909098788868687880988098809090687880788090687888807880606068788098708080808070809868788090988878809098788060706060707078809080987880906070809878788868686878787880988090909060708090687880988888809098788090907880987880788090909878809070809868788060788090809878888888888090987888607888809060708098687888686878788880909080987888809060708098788880687880987080986878809060708098787880988090708098706870809070809868687878888868686868686078888098788098787068788878886078806878807888607880687888807880986878787878807880607888607070707078809870808098686860708878787088687088687870809070708868787878787878708080607088686870809090607080986878807880909080987080987080987080986878806078809090687880909070788098687888888878809080708090786078809098708080809090808080808098788070786070788090909878809098687888888090986878809098182838485868788090607050605060607860707070704830485860707078203848586078102838485060607070708080909840182838405060788090904050687088182838485868708870808010203048506070102038405060708080202010102020202028384858687018283848586870803848586070607080988880909878809868788048586078809090506070809070886870809818283848586878807880987880788098788078809040304030304040506870808098586878809060708080607058304030303030405860203040584058683048582038485010203040485860582838483840201</t></list></t>
	<t>The key was created on 2014-09-09 16:35:36 from the tag conjugates (type 1), and thus the fingerprint of the OpenPGP key is:
	<list>
	  <t>8020 A772 BA18 EA47 3501 B8CE EABE 1082 56BB 5D64</t>
	</list></t>
	<t>and the entire public key packet is:
	<figure><artwork xml:space="preserve">
	  98 4a 04 54 0f 64 98 17  0b 2b 06 01 04 01 82 d9
	  24 01 00 00 01 01 6e 26  44 05 46 10 02 50 43 37
	  56 66 37 42 40 10 72 06  14 44 16 67 13 02 70 73
	  11 00 30 27 47 21 75 35  76 13 13 31 00 60 52 75
	  24 50 57 23 60 00 25 12  35 76 a8 94
	</artwork></figure></t>
      </section>

      <section title="Sample key agreement">
	<t>The key agreement is created using the sample key against a second (reader) public key.  The reader public key has the following data:</t>
	<t>Matrix (in nibbled-packed hex with trailing zeros):
	<figure><artwork xml:space="preserve">
	  24 14 13 22 14 67 30 02  20 23 11 26 26 51 20 11
	  67 40 56 57 60 77 01 04  66 56 71 35 21 27 57 00
	  55 75 16 40 07 75 05 12  31 35 75 45 66 40
	</artwork></figure></t>
	<t>Permutation (in nibble-packed hex): 32 14 56 78 9a</t>
	<t>Which results in the following shared secret:</t>
	<t>Matrix:
	<figure><artwork>
	  4 0 6 5 2 3 0 5 6 0 
	  6 5 5 0 2 0 1 7 5 5 
	  2 0 2 1 1 1 2 7 2 0 
	  4 0 1 2 5 6 6 6 1 2 
	  5 0 1 0 7 4 3 3 3 4 
	  5 1 2 5 3 3 5 5 7 1 
	  1 0 7 1 6 3 4 0 2 1 
	  2 7 5 4 6 7 1 4 7 4 
	  7 1 5 5 3 6 1 4 1 6 
	                    5
	</artwork></figure></t>
	<t>Permutation (decimal): 3 2 1 5 7 6 10 8 9 4</t>
      </section>

    </section>

    <!-- Change Log

v00 2014-09-09  DA    Initial version
v01 2014-09-10  DA    Fixed AAGL and added AEIntro refs
                      Changed type from 22 to 23 and updated example
v02 2014-09-12  DA    Refactored E-Multiplication Definition
                      Added description of computing the Shared Secret
                      Added TValues to public data
v03 2014-12-08  DA    Changed AEKAP to AEDH
v04 2015-01-14  DA    Added TValues to example, changed title
    -->
  </back>
</rfc>
