Mathematical Mesh: Reference Implementation
draft-hallambaker-mesh-developer-11

B.3.  Test Cases for AES_256_CBC_HMAC_SHA_512

    K =      00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
              10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
              20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
              30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f

    MAC_KEY = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
              10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f

    ENC_KEY = 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
              30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f

    P =      41 20 63 69 70 68 65 72 20 73 79 73 74 65 6d 20
              6d 75 73 74 20 6e 6f 74 20 62 65 20 72 65 71 75
              69 72 65 64 20 74 6f 20 62 65 20 73 65 63 72 65
              74 2c 20 61 6e 64 20 69 74 20 6d 75 73 74 20 62
              65 20 61 62 6c 65 20 74 6f 20 66 61 6c 6c 20 69
              6e 74 6f 20 74 68 65 20 68 61 6e 64 73 20 6f 66
              20 74 68 65 20 65 6e 65 6d 79 20 77 69 74 68 6f
              75 74 20 69 6e 63 6f 6e 76 65 6e 69 65 6e 63 65

    IV =      1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04

    A =      54 68 65 20 73 65 63 6f 6e 64 20 70 72 69 6e 63
              69 70 6c 65 20 6f 66 20 41 75 67 75 73 74 65 20
              4b 65 72 63 6b 68 6f 66 66 73

    AL =      00 00 00 00 00 00 01 50

    E =      4a ff aa ad b7 8c 31 c5 da 4b 1b 59 0d 10 ff bd
              3d d8 d5 d3 02 42 35 26 91 2d a0 37 ec bc c7 bd
              82 2c 30 1d d6 7c 37 3b cc b5 84 ad 3e 92 79 c2
              e6 d1 2a 13 74 b7 7f 07 75 53 df 82 94 10 44 6b
              36 eb d9 70 66 29 6a e6 42 7e a7 5c 2e 08 46 a1
              1a 09 cc f5 37 0d c8 0b fe cb ad 28 c7 3f 09 b3
              a3 b7 5e 66 2a 25 94 41 0a e4 96 b2 e2 e6 60 9e
              31 e6 e0 2c c8 37 f0 53 d2 1f 37 ff 4f 51 95 0b
              be 26 38 d0 9d d7 a4 93 09 30 80 6d 07 03 b1 f6

    M =      4d d3 b4 c0 88 a7 f4 5c 21 68 39 64 5b 20 12 bf
              2e 62 69 a8 c5 6a 81 6d bc 1b 26 77 61 95 5b c5
              fd 30 a5 65 c6 16 ff b2 f3 64 ba ec e6 8f c4 07
              53 bc fc 02 5d de 36 93 75 4a a1 f5 c3 37 3b 9c

    T =      4d d3 b4 c0 88 a7 f4 5c 21 68 39 64 5b 20 12 bf
              2e 62 69 a8 c5 6a 81 6d bc 1b 26 77 61 95 5b c5

Jones                    Expires April 17, 2015                [Page 62]
Internet-Draft          JSON Web Algorithms (JWA)          October 2014

Appendix C.  Example ECDH-ES Key Agreement Computation

  This example uses ECDH-ES Key Agreement and the Concat KDF to derive
  the Content Encryption Key (CEK) in the manner described in
  Section 4.6.  In this example, the ECDH-ES Direct Key Agreement mode
  ("alg" value "ECDH-ES") is used to produce an agreed upon key for AES
  GCM with a 128 bit key ("enc" value "A128GCM").

  In this example, a sender Alice is encrypting content to a recipient
  Bob. The sender (Alice) generates an ephemeral key for the key
  agreement computation.  Alice's ephemeral key (in JWK format) used
  for the key agreement computation in this example (including the
  private part) is:

    {"kty":"EC",
      "crv":"P-256",
      "x":"gI0GAILBdu7T53akrFmMyGcsF3n5dO7MmwNBHKW5SV0",
      "y":"SLW_xSffzlPWrHEVI30DHM_4egVwt3NQqeUD7nMFpps",
      "d":"0_NxaRPUMQoAJt50Gz8YiTr8gRTwyEaCumd-MToTmIo"
    }

  The recipient's (Bob's) key (in JWK format) used for the key
  agreement computation in this example (including the private part)
  is:

    {"kty":"EC",
      "crv":"P-256",
      "x":"weNJy2HscCSM6AEDTDg04biOvhFhyyWvOHQfeF_PxMQ",
      "y":"e8lnCO-AlStT-NJVX-crhB7QRYhiix03illJOVAOyck",
      "d":"VEmDZpDXXK8p8N0Cndsxs924q6nS1RXFASRl6BfUqdw"
    }

  Header Parameter values used in this example are as follows.  In this
  example, the "apu" (agreement PartyUInfo) parameter value is the
  base64url encoding of the UTF-8 string "Alice" and the "apv"
  (agreement PartyVInfo) parameter value is the base64url encoding of
  the UTF-8 string "Bob".  The "epk" parameter is used to communicate
  the sender's (Alice's) ephemeral public key value to the recipient
  (Bob).

Jones                    Expires April 17, 2015                [Page 63]
Internet-Draft          JSON Web Algorithms (JWA)          October 2014

    {"alg":"ECDH-ES",
      "enc":"A128GCM",
      "apu":"QWxpY2U",
      "apv":"Qm9i",
      "epk":
      {"kty":"EC",
        "crv":"P-256",
        "x":"gI0GAILBdu7T53akrFmMyGcsF3n5dO7MmwNBHKW5SV0",
        "y":"SLW_xSffzlPWrHEVI30DHM_4egVwt3NQqeUD7nMFpps"
      }
    }

  The resulting Concat KDF [NIST.800-56A] parameter values are:

  Z
      This is set to the ECDH-ES key agreement output.  (This value is
      often not directly exposed by libraries, due to NIST security
      requirements, and only serves as an input to a KDF.)  In this
      example, Z is following the octet sequence (using JSON array
      notation):
      [158, 86, 217, 29, 129, 113, 53, 211, 114, 131, 66, 131, 191, 132,
      38, 156, 251, 49, 110, 163, 218, 128, 106, 72, 246, 218, 167, 121,
      140, 254, 144, 196].

  keydatalen
      This value is 128 - the number of bits in the desired output key
      (because "A128GCM" uses a 128 bit key).

  AlgorithmID
      This is set to the octets representing the 32 bit big endian value
      7 - [0, 0, 0, 7] - the number of octets in the AlgorithmID content
      "A128GCM", followed, by the octets representing the UTF-8 string
      "A128GCM" - [65, 49, 50, 56, 71, 67, 77].

  PartyUInfo
      This is set to the octets representing the 32 bit big endian value
      5 - [0, 0, 0, 5] - the number of octets in the PartyUInfo content
      "Alice", followed, by the octets representing the UTF-8 string
      "Alice" - [65, 108, 105, 99, 101].

  PartyVInfo
      This is set to the octets representing the 32 bit big endian value
      3 - [0, 0, 0, 3] - the number of octets in the PartyUInfo content
      "Bob", followed, by the octets representing the UTF-8 string "Bob"
      - [66, 111, 98].

Jones                    Expires April 17, 2015                [Page 64]
Internet-Draft          JSON Web Algorithms (JWA)          October 2014

  SuppPubInfo
      This is set to the octets representing the 32 bit big endian value
      128 - [0, 0, 0, 128] - the keydatalen value.

  SuppPrivInfo
      This is set to the empty octet sequence.

  Concatenating the parameters AlgorithmID through SuppPubInfo results
  in an OtherInfo value of:
  [0, 0, 0, 7, 65, 49, 50, 56, 71, 67, 77, 0, 0, 0, 5, 65, 108, 105,
  99, 101, 0, 0, 0, 3, 66, 111, 98, 0, 0, 0, 128]

  Concatenating the round number 1 ([0, 0, 0, 1]), Z, and the OtherInfo
  value results in the Concat KDF round 1 hash input of:
  [0, 0, 0, 1,
  158, 86, 217, 29, 129, 113, 53, 211, 114, 131, 66, 131, 191, 132, 38,
  156, 251, 49, 110, 163, 218, 128, 106, 72, 246, 218, 167, 121, 140,
  254, 144, 196,
  0, 0, 0, 7, 65, 49, 50, 56, 71, 67, 77, 0, 0, 0, 5, 65, 108, 105, 99,
  101, 0, 0, 0, 3, 66, 111, 98, 0, 0, 0, 128]

  The resulting derived key, which is the first 128 bits of the round 1
  hash output is:
  [86, 170, 141, 234, 248, 35, 109, 32, 92, 34, 40, 205, 113, 167, 16,
  26]

  The base64url encoded representation of this derived key is:

    VqqN6vgjbSBcIijNcacQGg

Appendix D.  Acknowledgements

  Solutions for signing and encrypting JSON content were previously
  explored by Magic Signatures [MagicSignatures], JSON Simple Sign
  [JSS], Canvas Applications [CanvasApp], JSON Simple Encryption [JSE],
  and JavaScript Message Security Format [I-D.rescorla-jsms], all of
  which influenced this draft.

  The Authenticated Encryption with AES-CBC and HMAC-SHA
  [I-D.mcgrew-aead-aes-cbc-hmac-sha2] specification, upon which the
  AES_CBC_HMAC_SHA2 algorithms are based, was written by David A.
  McGrew and Kenny Paterson.  The test cases for AES_CBC_HMAC_SHA2 are
  based upon those for [I-D.mcgrew-aead-aes-cbc-hmac-sha2] by John
  Foley.

  Matt Miller wrote Using JavaScript Object Notation (JSON) Web
  Encryption (JWE) for Protecting JSON Web Key (JWK) Objects

Jones                    Expires April 17, 2015                [Page 65]
Internet-Draft          JSON Web Algorithms (JWA)          October 2014

  [I-D.miller-jose-jwe-protected-jwk], which the password-based
  encryption content of this draft is based upon.

  This specification is the work of the JOSE Working Group, which
  includes dozens of active and dedicated participants.  In particular,
  the following individuals contributed ideas, feedback, and wording
  that influenced this specification:

  Dirk Balfanz, Richard Barnes, John Bradley, Brian Campbell, Alissa
  Cooper, Breno de Medeiros, Vladimir Dzhuvinov, Roni Even, Stephen
  Farrell, Yaron Y. Goland, Dick Hardt, Joe Hildebrand, Jeff Hodges,
  Edmund Jay, Charlie Kaufman, Barry Leiba, James Manger, Matt Miller,
  Kathleen Moriarty, Tony Nadalin, Axel Nennker, John Panzer, Emmanuel
  Raviart, Eric Rescorla, Pete Resnick, Nat Sakimura, Jim Schaad,
  Hannes Tschofenig, and Sean Turner.

  Jim Schaad and Karen O&Request for posting confirmation emailed to previous authors: Phillip Hallam-Baker