Re: Cryptography for Boost. +1!

From: Lee Clagett (forum_at_[hidden])
Date: 2020-02-28 18:07:43

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, February 28, 2020 3:47 PM, Vinnie Falco via Boost <boost_at_[hidden]> wrote:

> On Fri, Feb 28, 2020 at 7:35 AM degski via Boost boost_at_[hidden] wrote:
>
> > https://github.com/jedisct1/libhydrogen
>
> What is this nonsense? A library that only has two algorithms
> (Curve25519 and Gimli?) seems pointless to me.
>
> Thanks

Everyone wanted audits by professionals. Less primitives means easier
audits. That library provides everything useful: symmetric encryption,
public-key encryption, digital signatures, and even an API for a key
exchange protocol. One of the authors of Gimli/curve25519, Daniel
Bernstein, as long argued for less options and fewer APIs for
cryptography to prevent misuse. Having options to select
block-cipher-modes with AES is nice, but has been used incorrectly
frequently due to subtle differences. This library/cipher/curve comes
from a long line of experience of prior mistakes. Boost providing the
kitchen sink of cryptography is only the correct approach if the goal
is to provide mass interoperability with other systems. Otherwise, less
is more.

I've looked at lots of cryptography code, this more sane to read than
much of the competitors. The biggest risk is the fairly new cipher and
possibly the AEAD design (probably based on poly1305?). x25519 is being
considered for major standards at this point.

Lee