From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 4A671C016F for ; Wed, 27 May 2020 15:16:00 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id 37AEC86AD0 for ; Wed, 27 May 2020 15:16:00 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from fraxinus.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjcShpZQ262r for ; Wed, 27 May 2020 15:15:59 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail-io1-f53.google.com (mail-io1-f53.google.com [209.85.166.53]) by fraxinus.osuosl.org (Postfix) with ESMTPS id 5ABBB86AC9 for ; Wed, 27 May 2020 15:15:59 +0000 (UTC) Received: by mail-io1-f53.google.com with SMTP id y5so3513728iob.12 for ; Wed, 27 May 2020 08:15:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blockstream-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3WRnRN9gV4bVyCh4mD84l3zuywiD7vyyFYhDAwy8xuI=; b=JQuhLZJP01Xt/xjKM+ZPUjEQWsdvdccfcPiZrJDHq68957Pr27fgsXP01LiueC02o0 1oTIg2qzaED0YncYdbV7UPS0sV44T2XFx0bzQUaScnBfjMFIaxlYTK75t3rfujQzp6gc 6YS+H+Ry4D+zTzoiY0HJf0S5RwxROTyDJ/WhrVKlf72VCOsuMswyKW4uZhYm7hG//2QA oEyWLboiZdgbbv2QkneHE0Zak2PwEPGox5MUP4nT7buD7zNIIc2YTkpDNa2OtReQceYz no1/WrHsEbVV4dJm9Dl/M50oUSkDO6UrFkGNyA3SGOvhfiaLcp7VeEyAcdP1LtnrgcPs wUzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3WRnRN9gV4bVyCh4mD84l3zuywiD7vyyFYhDAwy8xuI=; b=mekxzqyvO+G0TgL1ydufZsh4sOrv/pKoj1NgorZxKzoYCUm+6pBV7wEoSaJftEib91 wq/4MLIqBBm7mcYWCJxKu2+s8ToZ012KOqVueMat5Vg28bJzO3Z98df5oU5600QLkqQb AWY+zr/dsK6d8fwil6UjznOeAQzEmQ1xFRjN2e+cmcB7aiPgKpDy29/khzpPIheRE3p1 byFNiGpZnyXJnT4aYP+/Rnoiu8vw4MhLU5/SVz76C30U0ZihWwbzy7SVuncTfJNfuA/Z 3YzckHivhxIIQj91AvvYjeVNrY6trliqdCPXTxriNKApDpANOjwZhkyxUr2zsYh3FcJ2 WKOQ== X-Gm-Message-State: AOAM532ZN9OXjfzo1P/yTNNxEauilBm1Fnf8KvZuxysODuZkeTZ2qya7 u1/BCmPnwUK6UetuKJcxkEMMabpvtYz2sG9h4Lt3UQ== X-Google-Smtp-Source: ABdhPJzmqOeQaazBo5Qd3zBdaBSVacy9i19VsBTrtMKnDMhoncv6jDNZ3nc9r43UaCbEAlLqrb/IcXS1EvTzcr0BvdE= X-Received: by 2002:a05:6602:2e0e:: with SMTP id o14mr21342231iow.164.1590592558589; Wed, 27 May 2020 08:15:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Russell O'Connor" Date: Wed, 27 May 2020 11:15:47 -0400 Message-ID: To: ZmnSCPxj , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="00000000000070093105a6a2b0fa" Cc: Greg Sanders Subject: Re: [bitcoin-dev] MIN_STANDARD_TX_NONWITNESS_SIZE and OP_RETURN X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2020 15:16:01 -0000 --00000000000070093105a6a2b0fa Content-Type: text/plain; charset="UTF-8" I don't believe that 60 bytes is a problem here. SHA256 padding includes a length value of the original message data. Thus a padded non-64 byte transaction can never be the same as any padded 64-byte value, and therefore after applying the SHA256 compression function the resulting hashes cannot be identical (unless SHA256 itself is broken). P.S. SHA256 also includes 10* padding, which also suffices to ensure messages of different lengths have different padding. On Sat, May 23, 2020 at 8:52 PM ZmnSCPxj via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Good morning Thomas, > > > So I think the question to ask would be "why can't we just make sure > it's not 64?" > > If we accept a 60-byte tx, then SHA-256 will pad it to 64 bytes, and it > may still be possible to mount CVE-2017-12842 attack with 32-bits of work. > Of course some other details will be changed from the standard SHA-256 in > mounting this attack, but from my poor understanding it seems safer to just > avoid the area around length 64. > > It *might* be safe to accept 65-byte or larger (but do not believe me, I > only play a cryptographer on the Internet), but that does not help your > specific application, which uses 60 byte tx. > > Regards, > ZmnSCPxj > > > > > On Sat, May 23, 2020 at 11:24 AM Greg Sanders > wrote: > > > > > AFAIU the number was picked to protect against CVE-2017-12842 > covertly. See: https://github.com/bitcoin/bitcoin/pull/16885 which > updated the text to explicitly mention this fact. > > > > > > On Sat, May 23, 2020 at 11:20 AM Thomas Voegtlin via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > > > > > Hello list, > > > > > > > > I have been trying to CPFP a transaction using OP_RETURN, because the > > > > remaining output value would have been lower than the dust threshold. > > > > > > > > The scriptPubkey of the output was OP_RETURN + OP_0, and there was a > > > > single p2wsh input. > > > > > > > > The result is a 60 bytes transaction (without witness), that gets > > > > rejected because it is lower than MIN_STANDARD_TX_NONWITNESS_SIZE, > which > > > > is equal to 82 bytes. > > > > > > > > Why is that value so high? Would it make sense to lower it to 60? > > > > > > > > Thomas > > > > _______________________________________________ > > > > bitcoin-dev mailing list > > > > bitcoin-dev@lists.linuxfoundation.org > > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --00000000000070093105a6a2b0fa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I don't believe t= hat 60 bytes is a problem here.=C2=A0=20 SHA256 padding includes a length value of the original message data. Thus a= padded non-64 byte transaction can never be the same as any padded 64-byte= value, and therefore after applying the SHA256 compression function the re= sulting hashes cannot be identical (unless SHA256 itself is broken).
<= div>
P.S. SHA256 also includes 10* padding, which also suffic= es to ensure messages of different lengths have different padding.

On Sat, May 23, 2020 at 8:52 PM ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists.linuxfoundati= on.org> wrote:
Good morning Thomas,

> So I think the question to ask would be "why can't we just ma= ke sure it's not 64?"

If we accept a 60-byte tx, then SHA-256 will pad it to 64 bytes, and it may= still be possible to mount CVE-2017-12842 attack with 32-bits of work.
Of course some other details will be changed from the standard SHA-256 in m= ounting this attack, but from my poor understanding it seems safer to just = avoid the area around length 64.

It *might* be safe to accept 65-byte or larger (but do not believe me, I on= ly play a cryptographer on the Internet), but that does not help your speci= fic application, which uses 60 byte tx.

Regards,
ZmnSCPxj

>
> On Sat, May 23, 2020 at 11:24 AM Greg Sanders <gsanders87@gmail.com> wrote: >
> > AFAIU the number was picked to protect against=C2=A0CVE-2017-1284= 2 covertly. See:=C2=A0https://github.com/bitcoin/bitcoi= n/pull/16885=C2=A0which updated the text to explicitly mention this fac= t.
> >
> > On Sat, May 23, 2020 at 11:20 AM Thomas Voegtlin via bitcoin-dev = <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> > > Hello list,
> > >
> > > I have been trying to CPFP a transaction using OP_RETURN, be= cause the
> > > remaining output value would have been lower than the dust t= hreshold.
> > >
> > > The scriptPubkey of the output was OP_RETURN + OP_0, and the= re was a
> > > single p2wsh input.
> > >
> > > The result is a 60 bytes transaction (without witness), that= gets
> > > rejected because it is lower than MIN_STANDARD_TX_NONWITNESS= _SIZE, which
> > > is equal to 82 bytes.
> > >
> > > Why is that value so high? Would it make sense to lower it t= o 60?
> > >
> > > Thomas
> > > _______________________________________________
> > > bitcoin-dev mailing list
> > > bitcoin-dev@lists.linuxfoundation.org
> > > https://lists.linuxfoun= dation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--00000000000070093105a6a2b0fa--