[Cryptography] Looking for some feedback on design for collection of hash-based signatures libraries.

[Rob Meijer]

I'm already at iteration 6 of the design for this project, and it's amazing
how much I'm learning from just designing, trying the code, expanding on it
and running into walls. I'm now at a point though that I have a design
covering all operations I was aiming for, so I thought this would be a good
time to go look for some knowledgeable people to see if I can get some
feedback on the overall design this iteration.

What I'm working on is a not-so-little design for a collection of libraries
in different programming languages aimed at providing hash-based signing to
key-reuse-by-design utility blockchains. After some discussions with ocap
folks, the last two iterations had me recentre much of the design around
the concept of KDF index-space as to assure this initially entropy usage
heavy design wouldn't exhaust system entropy. I'm now using KDF-index-space
like a memory model without *free*, complete with stack and heap if you
believe it.

I think my current design is probably a bit unconventional because of this,
and on other aspects in contrast it may actually be a bit conservative. As
a practitioner, not a cryptographer, I'm really not going to be using CRCs
in my design no matter how much peer-reviewed CRCs in hash-based OTS
protocols may be, and I'm probably not going to be taking anyone's word on
that either. So my up/down OTS-chains are probably a bit conservative,
especialy in contrast to the KDF-keyspace part of the design.


https://peakd.com/coinzdense/@pibara/coinzdense-deep-dive-index

Did a series of 12 blog post on the technical system setup of what I'm
ailing to build. I'm open to all kinds of feedback, but I'm specifically
looking for things that would make my current design flawed from a security
aspect, a principle of least authority aspect, or that could improve the
usability in the type of setups that I'm targeting my libraries towards.

Kind regards,

Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20220122/64d7ed17/attachment.htm>