From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 7415FC07FF for ; Sat, 21 Mar 2020 17:00:03 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id 5AF6F88521 for ; Sat, 21 Mar 2020 17:00:03 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bNi3t-ybixqh for ; Sat, 21 Mar 2020 17:00:01 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail-il1-f181.google.com (mail-il1-f181.google.com [209.85.166.181]) by hemlock.osuosl.org (Postfix) with ESMTPS id E21BA884FD for ; Sat, 21 Mar 2020 16:59:59 +0000 (UTC) Received: by mail-il1-f181.google.com with SMTP id o16so6313521ilm.2 for ; Sat, 21 Mar 2020 09:59: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; bh=wPr/QLM8M4kiMA0FV+Ox3Yl21ESqU0q2FLOioaYmAQ4=; b=zAUwnO26Ye23u/FJyfG+QzWPTH/gd6O3Bu3o4YCuTeuq2Pp8sMfFo7lDKfroz8PAym iaOBbPe3YSB3qtV171ifAw7hnEX+7fbTVLCFeewiP60K6DsMbf+g5DF4dZJ/zJlqEWbQ cOh7oE8FMvVef4oaCjJzbHUUftR0ufLmSaUlpTFdU2awEZWr3CGmwKQqTYjc9KMQ1oVU t57ozj2JZuLtslaeds2InGI1CAnVfchHD9sv33wL4OFNjp3/LxRet9o960gXc+CGFUgw 69oZzdYbhPHwBvw52PPVpbVtAQ9KzXlxq3J9bureHxqJ6rRugHh0Js7LraCeXYfXkBVQ Qtkw== 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; bh=wPr/QLM8M4kiMA0FV+Ox3Yl21ESqU0q2FLOioaYmAQ4=; b=kCD9pdb2JJ3RPcZW3tiNUHOyM6qswUMJ25scNUzhnKxOJAXZIJIY4GuIzxGwjc7yEw BUlEnDx4s0vXtBO73xkcN+3qNXtyjA7pdYW70mRkzJHpBM7hjqCRNgx0U0lWb3jIQ0Oy aMaIyWlzlIUIj20PhjAkfq3Sdm+1gzbQevjU2osKWXirpbWBlgHzpH7UoYac02vXCgtr BL3JyF6+/tlClO19bbWuyaYvOBRgZ4Manol8r9weRONTsfr9jz2eTqGYnlgG9WxbaQ0P T81/1DQr8tkhMLmRussPeBq8t0B/ea4ozpAZ3qzUPT9sBrU+KbtTfnUHRWq5OjoUNVbr eTTQ== X-Gm-Message-State: ANhLgQ04MNdl4JNd2LPbVEtI54PxCCvPnEgbA/hBu3wnztdQ0hHtbEHL 7XCB36GLpc9oF8A9NzsSaQtdbMjrOXJW9dEYujhI6NeZ X-Google-Smtp-Source: ADFU+vuymKGvV0yTRp1QUS6bPG4uSljEwt61W8545Rj14bUUsC69kVhJs9ef5dxh4T+hKfbfCfWowuqS3zXYjaEZwmQ= X-Received: by 2002:a92:5a88:: with SMTP id b8mr2771725ilg.151.1584809999037; Sat, 21 Mar 2020 09:59:59 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Russell O'Connor" Date: Sat, 21 Mar 2020 12:59:47 -0400 Message-ID: To: Tim Ruffing , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000078e9505a1605506" Subject: Re: [bitcoin-dev] Overview of anti-covert-channel signing techniques 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: Sat, 21 Mar 2020 17:00:03 -0000 --000000000000078e9505a1605506 Content-Type: text/plain; charset="UTF-8" On Sat, Mar 21, 2020 at 12:46 PM Tim Ruffing via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi Pieter, > > Let's take a step back first. If we believe that malicious hardware > wallets are big enough of a concern, then signing is only part of the > problem. The other issue is key generation. The PRG from which the seed > is derived can be malicious, e.g., just H(k_OO,counter) for a key k_OO > chosen by the hardware manufacturer. I haven't seen an argument why > attacks during the signing model should more realistic than attacks > during key generation, so I'd be very hesitant to deploy anti-covert > channel singing protocols without deploying protocols for key > generation that are secure in the same attacker model. > Public keys are deterministic and can be spot checked. In fact, AFAIU if hardened HD key derivations are not used, then spot checking is very easy. While spot checking isn't ideal, my original concern with the synthetic none standard proposal was that it is inherently non-deterministic and cannot ever be spot checked. This is why anti-covert signing protocols are so important if we are going to use synthetic nonces. --000000000000078e9505a1605506 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Mar 21, 2020 at 12:46 PM Tim Ruffing = via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
Hi Pieter,

Let's take a step back first. If we believe that malicious hardware
wallets are big enough of a concern, then signing is only part of the
problem. The other issue is key generation. The PRG from which the seed
is derived can be malicious, e.g., just H(k_OO,counter) for a key k_OO
chosen by the hardware manufacturer. I haven't seen an argument why
attacks during the signing model should more realistic than attacks
during key generation, so I'd be very hesitant to deploy anti-covert channel singing protocols without deploying protocols for key
generation that are secure in the same attacker model.

Public keys are deterministic and can be spot checked.=C2= =A0 In fact, AFAIU if hardened HD key derivations are not used, then spot c= hecking is very easy.

While spot checking isn'= t ideal, my original concern with the synthetic none standard proposal was = that it is inherently non-deterministic and cannot ever be spot checked.=C2= =A0 This is why anti-covert signing protocols are so important if we are go= ing to use synthetic nonces.
--000000000000078e9505a1605506--