Ed25519 rainstorms and donkeys

Mukund Sivaraman muks at isc.org
Wed Jun 7 16:27:24 UTC 2017

Hi Tony

On Mon, Jun 05, 2017 at 06:58:33PM +0100, Tony Finch wrote:
> ## BIND
> This PureEdDSA two-pass signature generation is a significant pain,
> because BIND pervasively assumes a one-pass API built around various
> _adddata() functions which are wrappers around EVP_DigestUpdate().
> So I'm wondering how to deal with this impedance mismatch.
> Unless I have overlooked something, I think it makes sense to put an
> isc_buffer in the dst_context, turn on autoreallocation, and stash the
> data in there until _sign() or _verify() are called? This would use the
> mctx which is already in the dctx. (Or should it use the
> dst__memory_pool?)
> Should I embed the isc_buffer in the dst_context (which would be a waste
> for existing algorithms) or make a new eddsa context structure to contain
> the buffer and the OpenSSL EVP_MD_CTX, and put a pointer to that in the
> dst_context.ctxdata union (slightly fiddly but nbd)?

First, make sure you check with Francis Dupont before writing anything
as he may be on his way in implementing EdDSA support.

On adding another buffer in the dst_context, the wastage of space ought
to be negligible and it can always be refactored later. On this
adddata() of dst_func, accumulating the data into a buffer ought to be
fine, as for purposes of RRSIGs, the accumulated data is unlikely to be
> 64 kB.

By autoreallocation, if you mean the bit within the isc_buffer API, if
memory serves me right it's possible this doesn't exist in older release
branches, so backporting this (if necessary) may need more work.. but it
can be looked at later.


More information about the bind-workers mailing list