Arthur Chen [ARCHIVE] on Nostr: ๐ Original date posted:2016-07-03 ๐ Original message:I strongly agree! In ...
๐
Original date posted:2016-07-03
๐ Original message:I strongly agree!
In crypto we should always follow well-studied open standard rather than
custom construction.
On Fri, Jul 1, 2016 at 10:42 PM, Zooko Wilcox via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
Xuesong (Arthur) Chen
Senior Principle Engineer
BlockChain Technologist
BTCC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160704/01f4de23/attachment.html>
๐ Original message:I strongly agree!
In crypto we should always follow well-studied open standard rather than
custom construction.
On Fri, Jul 1, 2016 at 10:42 PM, Zooko Wilcox via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
Xuesong (Arthur) Chen
Senior Principle Engineer
BlockChain Technologist
BTCC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160704/01f4de23/attachment.html>