I haven't been able to find the beginning of this thread, so apologies if I've misunderstood what this is for, but it _sounds_ like we're re-inventing HKDF.
I'd recommend reading the paper about HKDF. It stands out among crypto papers for having a nice clear justification for each of its design decisions, so you can see why they did it (very slightly) differently than the various constructions proposed up-thread. https://eprint.iacr.org/2010/264 Also, of course, it is a great idea to re-use a standard (https://tools.ietf.org/html/rfc5869) and widely-understood crypto algorithm to reduce risk of both cryptographer errors and implementor errors. Of course, the cost of that is the you sometimes end up computing something that is a tiny bit more complicated or inefficient than a custom algorithm for our current use case. IMHO that's a cheap price to pay. Regards, Zooko _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
