On Wed, Feb 26, 2020 at 3:23 PM Vinnie Falco <vinnie.falco@gmail.com> wrote:
...
Sorry... I forgot to explain the most important motivation for creating a cryptography framework! There are many cryptographic algorithms which are second-order operations. That is, they are expressed in terms of underlying primitives. For example, the "Merkle–Damgård construction" is an algorithm which can be used to turn a block cipher into a cryptographic hash function. This can be expressed in C++ quite elegantly: template< class BlockCipher, std::size_t DigestBits > struct MerkleDamgardConstruction; It is much easier to write, and verify the correctness of the generic construction implementation because it assumes that the provided BlockCipher type is already correct. There is no cryptographic operation in the implementation. Merkle-Damgard is not without its problems, so users will still have to ensure that the security tradeoffs are appropriate for their use-case. There are many other second-order algorithms which can be (relatively) easily expressed in terms of cryptographic primitives by writing a function template or class template parameterized on various concepts such as BlockCipher, OneWayFunction, and so on. These come up quite often in crypto-currency applications. A "BIP" is a "Bitcoin Improvement Proposal" which is a highly structured paper describing a possible improvement to Bitcoin. Often, they involve new second-order and third-order cyptographic algorithms. A Boostly cryptography "framework" would allow authors to quickly prototype new higher order algorithms using the concepts I described above along with our wrappers implementing those concepts, simply by writing function or class templates and combining existing cryptographic primitives. The value of having named requirements is to give these cryptographic primitives uniform interfaces so they may be changed or substituted at will, as the needs require, facilitating the prototyping described above. Thanks