Zooko Wilcox [ARCHIVE] on Nostr: 📅 Original date posted:2016-07-01 📝 Original message:I haven't been able to ...
📅 Original date posted:2016-07-01
📝 Original message: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
📝 Original message: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