Christophe Biocca [ARCHIVE] on Nostr: 📅 Original date posted:2014-09-12 📝 Original message:> What hash function would ...
📅 Original date posted:2014-09-12
📝 Original message:> What hash function would you recommend?
Due to the properties of hash functions, you can just take the first x
bits of a SHA256 sum and they're pretty much as good as an equally
secure hash function of that length. In fact SHA512/224 and SHA512/256
are defined in that way (Plus different initial values because you
might as well do that when defining a standard).
On Fri, Sep 12, 2014 at 10:36 AM, Andreas Schildbach
<andreas at schildbach.de> wrote:
> On 09/12/2014 03:49 PM, Mike Hearn wrote:
>
>> (1) Base64 of SHA256 seems overkill. 256 bits of hash is a lot. The risk
>> here is that a MITM intercepts the payment request, which will be
>> typically requested just seconds after the QR code is vended. 80 bits of
>> entropy would still be a lot and take a long time to brute force, whilst
>> keeping QR codes more compact, which impacts scannability.
>
> To put that into perspective, here is how a bitcoin: URI would look like:
> bitcoin:?h=J-J-4mra0VorfffEZm5J7mBmHGKX86Dpt-TnnmC_fhE&r=http://wallet.schildbach.de/bip70/r1409992884.bitcoinpaymentrequest
> (obviously for real-world usage you would optimize the "r" parameter)
>
> I looked at the list in this doc to evaluate what's easily available:
> https://code.google.com/p/guava-libraries/wiki/HashingExplained
>
> I thought SHA1 has a bad reputation these days, and we don't save much
> by using it. I don't know anything about Murmur. MD5 is clearly broken.
> What hash function would you recommend?
>
>> (2) This should *not* be necessary in the common HTTPS context.
>
> It is. People can't check names. People don't want to check names.
> People can't get certificates for lots of reasons. X.509 is centralized.
> X.509 has had serious security issues in the past. And shit continues to
> happen.
>
> To sum up, X.509 can't replace the trust anchor that is established by
> scanning a QR code or tapping two devices together.
>
>> (3) This can be useful in the Bluetooth context, but then again, we
>> could also do things a different way by signing with the key in the
>> first part of the URI, thus avoiding the need for a hash.
>
> Sure. But signing is harder than just calculating a hash.
>
>
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
📝 Original message:> What hash function would you recommend?
Due to the properties of hash functions, you can just take the first x
bits of a SHA256 sum and they're pretty much as good as an equally
secure hash function of that length. In fact SHA512/224 and SHA512/256
are defined in that way (Plus different initial values because you
might as well do that when defining a standard).
On Fri, Sep 12, 2014 at 10:36 AM, Andreas Schildbach
<andreas at schildbach.de> wrote:
> On 09/12/2014 03:49 PM, Mike Hearn wrote:
>
>> (1) Base64 of SHA256 seems overkill. 256 bits of hash is a lot. The risk
>> here is that a MITM intercepts the payment request, which will be
>> typically requested just seconds after the QR code is vended. 80 bits of
>> entropy would still be a lot and take a long time to brute force, whilst
>> keeping QR codes more compact, which impacts scannability.
>
> To put that into perspective, here is how a bitcoin: URI would look like:
> bitcoin:?h=J-J-4mra0VorfffEZm5J7mBmHGKX86Dpt-TnnmC_fhE&r=http://wallet.schildbach.de/bip70/r1409992884.bitcoinpaymentrequest
> (obviously for real-world usage you would optimize the "r" parameter)
>
> I looked at the list in this doc to evaluate what's easily available:
> https://code.google.com/p/guava-libraries/wiki/HashingExplained
>
> I thought SHA1 has a bad reputation these days, and we don't save much
> by using it. I don't know anything about Murmur. MD5 is clearly broken.
> What hash function would you recommend?
>
>> (2) This should *not* be necessary in the common HTTPS context.
>
> It is. People can't check names. People don't want to check names.
> People can't get certificates for lots of reasons. X.509 is centralized.
> X.509 has had serious security issues in the past. And shit continues to
> happen.
>
> To sum up, X.509 can't replace the trust anchor that is established by
> scanning a QR code or tapping two devices together.
>
>> (3) This can be useful in the Bluetooth context, but then again, we
>> could also do things a different way by signing with the key in the
>> first part of the URI, thus avoiding the need for a hash.
>
> Sure. But signing is harder than just calculating a hash.
>
>
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development