Boost logo

Boost :

From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2020-02-26 23:39:43


On Wed, Feb 26, 2020 at 3:23 PM Vinnie Falco <vinnie.falco_at_[hidden]> 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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk