Skip to main content

Crypto Team Update

· 3 min read
Iñigo Querejeta Azurmendi

High level summary​

The open fronts that the crypto team is working on are:

  • Mithril: We are creating helper functions to single out the usage of unsafe to facilitate auditing. We are also preparing a RFP for an audit of mithril's core library. Exploring future paths of mithril.
  • cardano-base: Decision of whether to continue with BLS12-381 or switch curves. Conversion Praos to PraosBatchCompat ready, as well as KES secure forgetting.
  • KES agent: using snockets and making things testable in IOSim
  • MuSig2: GH actions updated for checking the files whether they end with an empty line. Also, we reorganized the library.

Low level summary​

Mithril​

  • Given that removing the usage of transmute really affects the benchmarks, we decided to group all unsafe functions to facilitate auditing PR#722
  • We have progressed with the RFP document for the mithril-stm library. We are documenting the differences with respect with the original paper.
  • We are exploring possible paths of how mithril could be used 'as-a-service'. Other projects such as sidechains or Catalyst would benefit of such a service. We are at a very early stage of brainstorming how it could work.

cardano-base​

  • There has been a very thorough discussion with potential users of the BLS12-381 bindings if that is the best curve. We have considered alternatives such as Pasta curves, Pluto-Eris or BLS12-377, and considering it's trade-offs. Seems that the most interesting curve to have on main-net is still 381.
  • The team is gaining expertise in SNARKs to be able to experiment with them, and conclude whether the bindings will allow for SNARK verification on main-net in a timely manner.
  • The update VRF PR#341 is finally merged, and we are ready to merge PR#344, which implements conversion functions from the compatible types between Praos and PraosBatchCompat.

KES agent​

  • Use of snockets to send the data directly from the socket to secure memory.
  • We realized that in order for the DirectSerialise / DirectDeserialise classes to work against IOSim, we have to generalize a bunch of additional primitives
  • Our plans are to: (1) Split up MonadSodium into separate typeclasses, each capturing a more sensible concern; (2) Rename those typeclasses to something that reflects their nature better.

MuSig2​

The GitHub Action linelint is used to check the files.

  • A new job for linting is added to the file /.github/workflows/ci.yml. The rules are configured in the file /.github/workflows/.linelint.yml. Some files from the configuration of libsecp were failing, so in the rules in .linelint.yml the failing files are denoted to be ignored by the linter.
  • Folders are reorganized. We created a folder to handle the example. This folder includes the examplemusig2.c, a distinct config.h, and helper.c. The example is enhanced by implementing the functions in the helper for the configuration given in config.h. The number of messages is different than the tests. The example is made more generic to run with a loop.