{"id":25042361,"url":"https://github.com/sftcd/happykey","last_synced_at":"2026-03-07T15:34:41.078Z","repository":{"id":44352865,"uuid":"223981238","full_name":"sftcd/happykey","owner":"sftcd","description":"Implementing RFC9180 with OpenSSL","archived":false,"fork":false,"pushed_at":"2024-05-20T21:06:57.000Z","size":10454,"stargazers_count":5,"open_issues_count":0,"forks_count":2,"subscribers_count":3,"default_branch":"master","last_synced_at":"2025-07-20T16:27:56.548Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"","language":"C","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/sftcd.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null}},"created_at":"2019-11-25T15:29:16.000Z","updated_at":"2024-05-20T21:07:02.000Z","dependencies_parsed_at":"2025-04-14T00:42:44.308Z","dependency_job_id":"f79836bf-1b15-4898-a1b5-ce7952991ca4","html_url":"https://github.com/sftcd/happykey","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/sftcd/happykey","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/sftcd%2Fhappykey","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/sftcd%2Fhappykey/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/sftcd%2Fhappykey/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/sftcd%2Fhappykey/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/sftcd","download_url":"https://codeload.github.com/sftcd/happykey/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/sftcd%2Fhappykey/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":30219542,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-03-07T14:02:48.375Z","status":"ssl_error","status_checked_at":"2026-03-07T14:02:43.192Z","response_time":53,"last_error":"SSL_read: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2025-02-06T04:14:54.783Z","updated_at":"2026-03-07T15:34:41.059Z","avatar_url":"https://github.com/sftcd.png","language":"C","funding_links":[],"categories":[],"sub_categories":[],"readme":"# happykey\n\nThis is an implementation of [HPKE](https://www.rfc-editor.org/rfc/rfc9180.html), \nusing OpenSSL, as a precursor to using that for \n[Encrypted SNI/ECH](https://tools.ietf.org/html/draft-ietf-tls-esni) with my \n[ECH-enabled OpenSSL fork](https://github.com/sftcd/openssl).  This needs to be built\nagainst a master/tip version of OpenSSL such as my fork.\n\nThis PR generated from this code has now been upstreamed to OpenSSL and is\na part of current OpenSSL releases, so you're probably much better off using\nthat unless you're interested in the history of that code or something.\n\nI've submitted a [pull request](https://github.com/openssl/openssl/pull/17172)\nfor inclusion of HPKE in OpenSSL, based on this code. Since that'll take a\nwhile to happen, and then turn up in an official OpenSSL release, the idea is\nthat applications can use this as a sort of \"polyfill\" (borrowing the \n[concept](https://en.wikipedia.org/wiki/Polyfill_(programming) used in web \ndevelopment:-) in the meantime. I also plan to update this as newer\nHPKE ciphersuites are defined but that code won't (at least initially)\nbe part of the OpenSSL PR.\n\nHigh level notes:\n\n- All 480 local tests (``./alltest.sh``) are working - yes, you get to\n  480 test combinations with the variations allowed. That's too many IMO.\n- For test vectors, see ``tvtest.sh`` output - 96 tests pass, \n  and 84 don't match a test vector. \n- The default ciphersuite is x25519/hkdf-sha256,hkdf-sha256,aes128gcm. \n- (Almost) Only the single-shot APIs are supported.\n- Exporters are not supported.\n\n## Recent Changes\n\n- 20221125: My [HPKE-PR](https://github.com/openssl/openssl/pull/17172) has now\n  been merged! That means that anyone with an OpenSSL 3 master build already\n  has HPKE APIs. So we now only need two build options 1) use the library build\n  that has HPKE, or 2) use the system (dev) library that hasn't. (Will do that\n  in a bit.)\n\n- 20221122: yet more PR changes\n\n- 20221117: a few more PR nits\n\n- 20221115: many more test and code coverage checking\n\n- 20221105: lots more tweaks based on more PR review\n\n- 20221024: many more tweaks from PR review\n\n- 20221022: documentation tweaks and tidy up\n\n- 20221021: more documentation changes (but not quite done yet)\n\n- 20221019: starting to make the documentation related stuff work\n  for openssl folk (mostly that's in a fork of openssl though in\n  the HPKE-PR branch)\n\n- 20221018: moved KEM table to ``hpke_util.c`` using @slontis work - did\n  same with KDF and AEAD tables for consistency\n\n- 20221016: confirmed that latest APIs changes work for ECH and \n  updated OpenSSL forks accordingly\n\n- 20221015: various code re-arrangements to make it easier to build\n  against a system-installed OpenSSL library; added yet another \n  re-spin of external OpenSSL API (but why not, we've had so many\n  already:-) \n\n- 20221012: added API (needed for ECH) to recmmmend the length of\n  IKM to use with a given suite\n\n- 20221011: more changes based on PR comments, incl. export-only\n  mode and tests, removed \"legacy\" APIs, added ``OPENSSL_clear_free()``\n  and ``OPENSSL_cleanse()`` calls, I might need to add an API to\n  allow ECH code to know how much randomness to generate for an\n  IKM, but can do that tomorrow\n\n- 20221010: more changes based on PR comments\n\n- 20221008: changes to str2suite based on PR comments\n\n- 20221007: changes to keep OpenSSL CI happy\n\n- 20221006: getting PR comments on this now...\n    - DHKEM apis handle 9180 det key gen so I could lose that code\n\n- 20221005: reduced HPKE code duplication when building with DHKEM \n  PR now having being merged (but keeping ability to build and link to\n  a released OpenSSL 3.0.0). TODO: ECH checks.\n\n- 20220928: now working on two build targets - one for when using\n  the system install of OpenSSL (3.0 or above) (using -DHAPPOBJS),\n  so HPKE API objects need to be directly linked to application code,\n  and a second for when linking with a master branch build that has\n  the new HPKE APIs built-in (-DHPKEAPI).  The ``make forlib`` and\n  ``make copy2lib`` targets can be used to create and move the\n  relevant files (``hpke.h, hpke.c`` and ``apitest.c`` with some\n  ifdef'd code taken out using the ``uninfdef`` tool) to an OpenSSL build.\n\n- 202200906: new API seal/open working, with export APIs, and more\n  test vectors, ECH interop tested\n\n- 20220828: made quite a few changes based on review of our \n  [OpenSSL HPKE PR](https://github.com/openssl/openssl/pull/17172). Many\n  fairly trivial, but one required adding a shim for the otherwise\n  internal ``WPAKCET_*()`` APIs.\n\n- 20220618: added a (possibly temporary, possibly not) proposal for\n  a higher level API that better matches the RFC text - idea is to\n  see if OpenSSL devs prefer that (or something derived from that).\n  If so, will implement it then:-)\n\n- 20220716: replace ``ossl_hpke_suite_st`` with ``OSSL_HPKE_SUITE``\n  as per OpenSSL dev guidance.\n\n- 20220714: added HPKE deterministic key generation - had\n  previously omitted that as it wasn't needed for ECH but as it will be\n  needed for MLS and maybe other HPKE consumers, it was time to add it\n\n- 20220711: a pile of changes (including some external names) based on \n  fine comments received from OpenSSL developers)\n\n- 20220610: improved the doxygen documentation some - the [PDF](hpke-api.pdf)\n  should now actually be useful:-)\n\n- 20220610: many tweaks to make the OpenSSL ``util/check-format.pl`` script\n  happy with the code that's intended for inclusion inside the library\n\n- 20220608: expanded apitest.c significantly, and integrated that into\n  the OpenSSL ``make test`` target which resulted in some internal\n  changes due to evolution of upstream APIs (and a pair of bug fixes\n  which is nice)\n\n- 20220604: added [``apitest.c``](apitest.c) which'll be moved into\n  openssl ``make test`` target (probably ``test/evp_extra_test.c``\n  as currently or maybe elsewhere)\n\n- 20220604: changed internal aead, kem and kdf tables to be packed\n  rather than sparse - that'll be better if/as larger IANA codepoints\n  are allocated\n\n- 20220603: changes to external API names e.g. from ``hpke_enc``\n  to ``OSSL_HPKE_enc`` for consistency with OpenSSL conventions.\n  Various other similar changes.\n\n- 20220602: A number of changes taking the \"polyfill\" approach and\n  reacting to comments on the PR we've submitted for the OpenSSL library.\n  (I've only partly handled those comments so far.)\n\n- 20220530: Added instructions for building with an OpenSSL that \n  includes HPKE (from my fork) and rebasing, 'cause I always forget ;em;-)\n\n- 20220225: HPKE is now [RFC9180](https://www.rfc-editor.org/rfc/rfc9180.html),\n  so various comments updated accordingly.\n\n- 20211215: added a sketch of a [higher level API](hpkehigh.h) that\n  could be developed as part of discussion of PR for upstream. My\n  current working hypothesis is that that'd be a bad plan. \n\n- 20211205: Changed to use ``EVP_KDF_*`` APIs for extract/expand instead \n  of ``EVP_PKEY_derive*`` as advised by OpenSSL upstream maintainer. \n\n- 20211204: many teeny cosmetic changes to better match OpenSSL code\n  style. (One interesting change to return explicit non-zero error values\n  from hpkemain - one of our __LINE__ error returns was on line 512 and\n  when tha percolated out to the shell as the parameter to an ``exit()``\n  call it was of course seen as zero - confusing my test scripts into\n  seeing an unexpectd success when a failed decryption was the nominal\n  text extpection!)\n\n- 20211129: Fixed some issues that became apparent as I was documenting\n  HPKE for an OpenSSL PR - mostly just parameter name changes but one\n  real change was to allow an ``EVP_PKEY*`` form for the private key\n  for authentication in ``hpke_enc()`` \n\n- 20211128: added ossplayground.c as a place play with code to be\n  added to OpenSSL ``make test`` target.\n\n- 20211127: minor tweak as I documented things to prepare a PR \n  for OpenSSL.\n\n- 20211104: Added ``hpke_setlibctx()`` API to allow caller to set\n  a new default ``OSSL_LIB_CTX`` - that's needed for the OpenSSL\n  ``make test`` target that makes use of such.\n\n- 20211030: added ``HPKE_DEFSIZE`` (40kB) for handling e.g. stdin \n  when we don't know plaintext/ciphertext buffer size and reduced \n  the value of ``HPKE_MAXSIZE`` to 2kB as that's now only used \n  for keys and internal buffers that won't be that big until we hit\n  PQC or something (which is not now:-). \n\n- 20211029: removed size restriction on plaintext and ciphertext\n  (keys and other structures are still internallhy stack-based \n  and limited to ``HPKE_MAXSIZE``).\n\n- 20211012: fixed doube-free if bad value fed to NIST decoding of\n  public key buffer\n\n- 20210903: doing interop testing with boringssl, TLS HRR handing\n  requires use of the same HPKE context twice, which in turn\n  implies incrementing the nonce, so we added a sequence input\n  to ``hpke_enc()`` and ``hpke_dec()`` and co. HRR handing\n  isn't yet working, but this change moves us along a bit it\n  seems. (However, more change here may also be needed, we'll\n  have to see.) This also generates a TODO: - to add some 2nd\n  encryptions to the test vector tests - we'll get back to that\n  once get we interop for HRR cases.\n\n- 20210823: more cosmetic stuff - get rid of spaces at end of\n  lines (also for OpenSSL style points apparently;-)\n\n- 20210816: a pile of cosmetic checks to stick to 80-char line\n  lengths (for OpenSSL style points:-)\n\n- 20210816: added ``hpke_expansion`` allowing caller to know the\n  ciphertext length, they'll see for a given plaintext length \n  (basically 16 more octets for an aead tag:-) which is needed\n  for ECH draft-13.\n\n- 20210310: Surprisingly easy update to draft-08 and the (hopefully)\nfinal test vectors and version label. The Makefile defines the \"DRAFT_08\"\nsymbol which causes the runtime to use the \"HPKE-v1\" label and to\nuse the ``test-vectors-08.json`` file. If that's not defined then\nthe \"HPKE-07\" label will be used instead. (Note to self: once \nCloudflare and/or NSS have upgraded to draft-10 of ECH/draft-08 of\nHPKE then I'll change the default. That'll hopefully be soon.)\n\n- 20210310: tidied up hpke.c and esp ``hpke_buf2evp``\n\n- 20210310: added test2evp.c to see if we can unify the buffer to\n``EVP_PKEY`` code for NIST and non-NIST curves. Got some help on\nopenssl-users list for that from Matt Caswell which sorted it out.\n\n- 20210309: Still needs tidying but I've gotten rid of the deprecation\nwarnings finally. So this is just an overnight checkpoint before I\ntidy that up.\n\n- 20210305: Added external API to map from buffer \u0026 kem-id to private\nkey.\n\n- 20210304: built against rebased upstream openssl - there are some\ndeprecations still to handle, but otherwise happkeys is ok\n\n- 20210301: fixed the ``hpke_enc_evp`` variant\n\n- 20210220: improvement/fix inside ``hpke_expand`` - was assuming desired\noutput length and available buffer size (as input) were the same which is\nnot always the case.\n\n- 20210220: Added a test (see ``neod.c``,``neod_nss.c``) to try a round-trip\n  case where a long term key pair is generated by happykey, then NSS is used to\nencrypt to that public key, and finally we try a decrypt with happykey. That\nround-trip works ok in a basic test, (had some issues with test-code\ninitially), so the fact that ECH from NSS to my openssl build is currently\nfailing should be due to some protocol level thing and not something wrong\ninside HPKE, which should be good.... Aargh (and face palm;-) - turned out I\nwas compiling in draft-06 labels in the openssl build of hpke. \n\n- 20201216: Updated for draft-07, only changes made is the new\nlabels, and disable support for draft-05 - still haven't added exporter stuff.\n\n- 20201204: Made an internal api external (``hpke_suite_check()``) to allow a\n  client to check if the suite presented e.g. from an ECHConfig is supported\nlocally.\n\n- 20201027: this implements HPKE draft-06 as the default. It also supports HPKE\n  draft-05 with the X-coordinate DH fix.  This code verifies the most recently\nposted [test vectors](https://github.com/cfrg/draft-irtf-cfrg-hpke/blob/master/test-vectors.json)\nfor draft-06. (Or the older ones for draft-05.) \nAs we also (currently, hopefully briefly) need to keep draft-05 code too, because\nthat's apparently what the latest ESNI/ECH draft requires (sheesh!),\nI've kept both. See the [Makefile](Makefile) for how to define\nthe right things (hint: ``-DDRAFT_06`` is one way:-).\n\n## Build \n\nAssuming you want to build within ``$HOME/code``, with the upstream\nOpenSSL library, as I usually do, then:\n\n            $ cd $HOME/code\n            $ git clone https://github.com/sftcd/happykey\n            $ cd happykey\n\nThis build needs to be built against a \"master\" OpenSSL.  \nIf you want to check test vectors,\n(see below) you'll also need json-c,  so my setup looks like:\n\n- ``$HOME/code/happykey`` with this repo\n- ``$HOME/code/openssl`` with a clone of [OpenSSL](https://github.com/sftcd/openssl)\n- ``$HOME/code/json-c`` with a clone of [json-c](https://github.com/json-c/json-c)\n\nIf your setup differs, you'll need to hand-edit the [Makefile](Makefile)\nand then:\n\n            $ make\n            gcc -g  -I ../openssl/include -c hpkemain.c\n            gcc -g  -I ../openssl/include -c hpke.c\n            gcc -g  -o hpkemain hpkemain.o hpke.o -L ../openssl -lssl -lcrypto\n\nI also have a [bash script](env) that sets the environment vars to pick up \nthe shared objects needed:\n\n            $ . ./env\n\n\nIf you do build this, ``hpkemain`` is the test tool, so start with \n``hpkemain -h`` to see what's what:\n\n            $ ./hpkemain -h\n            HPKE (draft-irtf-cfrg-hpke) tester, options are:\n            Key generaion:\n                Usage: ./hpkemain -k -p private [-P public] [-c suite]\n            Encryption:\n                Usage: ./hpkemain -e -P public [-p private] [-a aad] [-I info]\n                        [-i input] [-o output]\n                        [-m mode] [-c suite] [-s psk] [-n pskid]\n            Decryption:\n                Usage: ./hpkemain -d -p private [-P public] [-a aad] [-I info]\n                        [-i input] [-o output]\n                        [-m mode] [-c suite] [-s psk] [-n pskid]\n            Options:\n                -a additional authenticated data file name or actual value\n                -c specify ciphersuite\n                -d decrypt\n                -e encrypt\n                -h help\n                -I additional info to bind to key - file name or actual value\n                -i input file name or actual value (stdin if not specified)\n                -k generate key pair\n                -P public key file name or base64 or ascii-hex encoded value\n                -p private key file name or base64 or ascii-hex encoded value\n                -m mode (a number or one of: base,psk,auth or pskauth)\n                -n PSK id string\n                -o output file name (output to stdout if not specified) \n                -s psk file name or base64 or ascii-hex encoded value\n                -v verbose output\n\n            Notes:\n            - Sometimes base64 or ascii-hex decoding might work when you\n              don't want it to (sorry about that;-)\n            - If a PSK mode is used, both pskid \"-n\" and psk \"-s\" MUST\n              be supplied\n            - For auth or pskauth modes, provide both public and private keys\n            - Ciphersuites are specified using a comma-separated list of numbers\n              e.g. \"-c 0x20,1,3\" or a comma-separated list of strings from:\n                  KEMs: p256, p384, p521, x25519 or x448\n                  KDFs: hkdf-sha256, hkdf-sha384 or hkdf-sha512\n                  AEADs: aes128gcm, aes256gcm or chachapoly1305\n              For example \"-c x25519,hkdf-sha256,aes128gcm\" (the default)\n\nThere's a bit of (unfinished) doxygen-generated documentation of the [API](hpke-api.pdf).\n\n## Build with OpenSSL that includes HPKE\n\nI have an OpenSSL fork with a [branch](https://github.com/sftcd/openssl/tree/HPKE-PR) \nthat has HPKE built into the library. (And a related [PR](https://github.com/openssl/openssl/pull/17172)\nfor inclusion of that with upstream. If you want to build with that then\ninstead of the above you want:\n\n            $ cd $HOME/code\n            $ git clone https://github.com/sftcd/openssl.git\n            $ cd openssl\n            $ git checkout HPKE-PR\n            $ ./config  \n            $ make -j8\n\nThen you need to modify the Makefile for happykey:\n\n            $ cd $HOME/code/happykey\n            $ vi Makefile\n            # uncomment the line for uselibcrypto=y\n            $ make\n            $ ./alltest.sh\n            All done. All good. (480 tests)\n\n## Rebasing the OpenSSL that includes HPKE\n\nUpstream code changes all the time and I always forget how to\ncatch up with that properly. (And probably do it wrong in any\ncase;-) Doing this obvious requires you to have write access\nto the origin, so this note is mostly for me:-)\n\nHere's how I'm currently doing that and plan to in\nfuture:\n\n            $ cd $HOME/code\n            $ git clone git@github.com:sftcd/openssl.git openssl-rebase\n            $ cd openssl-rebase\n            $ git remote add upstream https://github.com/openssl/openssl.git\n            $ git fetch upstream\n            $ git checkout master\n            $ git reset --hard upstream/master\n            $ git push origin master --force \n\nThat gets the ``master`` branch up to date with upstream. Next is to rebase\nmy own branch(es) with that, e.g. for HPKE-PR.\n\n            $ git checkout HPKE-PR\n            $ git rebase -i master HPKE-PR\n\nIf squashing commits then replace all but first \"pick\" with an \"f\"\n\nThen fixup the commit comment via:\n\n            $ git commit --amend\n\nAnd when the time is right, then a force push is correct\n\n            $ git push --force \n\nThat last has needs some repetitive stuff but works in the end\nbut don't forget to build/test/push to origin too.\n\n            $ make clean\n            $ ./config\n            $ make -j8\n            $ make test\n            $ git push\n\n## PEM-like ciphertext file format\n\nSince we need the ciphertext and sender's public key to do a decrypt,\nthe ``hpkemain`` command line test tool saves both of those in one\nfile. An [example](PEM-like-sample) of one of those is included:\n\n            $ cat PEM-like-sample\n            -----BEGIN SENDERPUB-----\n            Oxsee6j2HJ5v00nfO3oOxwszKT25d4uiR2Aga+HPKAI=\n            -----END SENDERPUB-----\n            -----BEGIN CIPHERTEXT-----\n            MPMS0EjIPJ2hRlJH8J9WLLlU2cPnWlmw6FyS1uxI6xyBx4nwWPGNCSZxQ65JP5xNYDqwKtTGTK5IR4nrs2ZqK4zTEROohDCtciUmB2A8+VBu1w==\n            -----END CIPHERTEXT-----\n\nMy code for reading those files is a little (but not a lot:-) tolerant, e.g. it\nallows additional whitespace to be added within the base64 encoded values.\nI'm not sure if that PEM-like stuff is wise, but we'll see - it's good enough\nto let me easily test round-tripping at least.\n\n## Encrypt a file\n\nThere's a file with a sample [public key](pub) to which you can encrypt things.\n(I don't have the private key, honest:-) Using that to enrypt the tiny shell\nscript [env](./env), looks like this:\n\n            $ ./hpkemain -P pub -i env\n            -----BEGIN SENDERPUB-----\n            AhsDyKTnsE+W42q+c3fiXX7F/WgZqTMBSMHKiYd5xnE=\n            -----END SENDERPUB-----\n            -----BEGIN CIPHERTEXT-----\n            IcUIJv4YCX57Uh/cH+KQCMCErLFQtXQgsk68lsCubUCzAVtEH7X1/eqhsij7ly0M9Mozp+r+7tp7s1hoFHtdI52G9frDnDjQ3OG+P0bpMJ7ovA==\n            -----END CIPHERTEXT-----\n\n## Test scripts\n\nThe [tvtest.sh](tvtest.sh) script tests all combinations of mode/cipheruite\nagainst test vectors.\nThat currently shows 84 cases (out of 180) where there is no match in the\nset of test vectors.\n\nThe [alltest.sh](alltest.sh) script tests key generation, encryption,\ndecryption and failed decryption, for all combinations of mode/cipheruite. \nFailed decryption tests for some\nexpected failed decryptions (e.g. presenting bad PSK values).  All relevant\nfiles end up in ``$HOME/code/happykey/scratch`` with random looking names. (A\n``make clean`` will clean those out too.)\n\nThe [roundtrip.sh](roundtrip.sh) script fetches some plaintext, generates a key\npair, encrypts a file to that public key, then tries to decrypt that.  You can\nadd extra comnand line parameters (e.g. \"-c 0x20,1,1\") and those'll be passed on\nto the key generation and encrypt/decrypt calls.\n\nThe [infoaadtest.sh](infoaadtest.sh) script does the same as\n[roundtrip.sh](roundtrip.sh) but provides (random) AAD and Info inputs to\nencryption and checks that decryption works or fails as appropriate when\ngood/bad values are provided. That's only done for base and psk modes for now.\nAs before, you can add extra comnand line parameters (e.g. \"-c 0x20,1,1\") and\nthose'll be passed on to the key generation and encrypt/decrypt calls.\n\n## Key generation\n\nTo generate a key pair and store the private key in PEM format (PKCS#8 PrivateKey)\nand the public key as a binary value:\n\n            $ ./hpkemain -k -p privfile -P pubfile\n            $ hd pubfile \n            00000000  84 16 89 b8 1c 16 ac 40  1a 7e 3d df f1 5b 38 fd  |.......@.~=..[8.|\n            00000010  29 6d e7 cc f4 47 5d 64  c3 d8 b0 70 21 39 70 7f  |)m...G]d...p!9p.|\n            00000020\n            $ cat privfile \n            -----BEGIN PRIVATE KEY-----\n            MC4CAQAwBQYDK2VuBCIEIDDuKfoFZyFu9Xh1m0HKbkbC6F5HXZed+dYwx5YDQyp8\n            -----END PRIVATE KEY-----\n\nOr you can put both keys in one file if you omit the public key file name:\n\n            $ ./hpkemain -k -p both\n            $ cat both\n            -----BEGIN PRIVATE KEY-----\n            MC4CAQAwBQYDK2VuBCIEINDTadwuLL44s9CU994pqowjI/rS1Vqg8Ate0dblQOtW\n            -----END PRIVATE KEY-----\n            -----BEGIN PUBLIC KEY-----\n            qfmyAu9tcQM8MQtg1pWimIz9gdAwXZDUzWPbm4Y5/Wg=\n            -----END PUBLIC KEY-----\n\n## Test Vectors\n \nThe authors of the HPKE draft also published a pile of test vectors,\nso one of the things I did while coding was to check I get the same\nvalues as those when encrypting with the given keys.\n\nTo enable test vector checking, compile with ``TESTVECTORS`` #define'd.\nThere's a line to uncomment in the [Makefile](Makefile) that does that.\nTo do the test vector comparison I use the published \n[test-vectors-08](test-vectors-08.json) \nfrom \n[the CFRG repo](https://github.com/cfrg/draft-irtf-cfrg-hpke).  I use the \n[json-c](https://github.com/json-c/json-c) library to decode\nthe JSON file into an array of type``hpke_tv_t`` that I defined.\nThe [Makefile](Makefile) here assumes that you've built json-c in a sibling\ndirectory to this one as shown above.\n\nAs of now, when the ``-T`` commnand line argument is used, the JSON file of\ntest vectors is loaded into an array of ``hpke_tv_t`` and I just pick the first\none that matches my chosen mode/suite, then print out various intermediate values on\nthe way to checking the ciphertext from ``hpke_enc()`` matches the test\nvector... and that now works.  \n\nIt appears that there is only one test vector matching each\nof my supported modes and ciphersuites. So we're not gonna do much\nbetter than just picking the first match:-)\n\nWhen you turn on ``TESTVECTORS`` then a pile of extra tracing is done\nto stdout. More or less the same happens if you ``#defined SUPERVERBOSE``\nin [hpke.c](hpke.c). As that's not really \"proper\" logging, and would\nexpose key material, both are off by default. But that should be a\nreminder that this is intended for test and not for real-world uses.\n(I plan to incorporate code from this into my OpenSSL fork when that's\noffered to upstream for ESNI/ECH.)\n\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fsftcd%2Fhappykey","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fsftcd%2Fhappykey","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fsftcd%2Fhappykey/lists"}