public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Jonas Schnelli <dev@jonasschnelli.ch>
To: Eric Voskuil <eric@voskuil.org>, Alfie John <alfie@alfie.wtf>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP 151
Date: Thu, 30 Jun 2016 14:20:59 +0200	[thread overview]
Message-ID: <57750EAB.3020105@jonasschnelli.ch> (raw)
In-Reply-To: <2981A919-4550-4807-8ED9-F8C51B2DC061@voskuil.org>


[-- Attachment #1.1: Type: text/plain, Size: 1743 bytes --]


> Yes, this is exactly what I meant. The complexity of the proposed construction is comparable to that of Bitcoin itself. This is not itself prohibitive, but it is clearly worthy of consideration.
> 
> A question we should ask is whether decentralized anonymous credentials is applicable to the authentication problem posed by BIP151. I propose that it is not.
> 
> The core problem posed by BIP151 is a MITM attack. The implied solution (BIP151 + authentication) requires that a peer trusts that another is not an attacker. 

BIP151 would increase the risks for MITM attackers.
What are the benefits for Mallory of he can't be sure Alice and Bob may
know that he is intercepting the channel?

MITM is possible today, it would still be possible (though under higher
costs) with BIP151.

With BIP151 we would have the basic tool-set to effectively reduce the
risks of being MITMled.

IMO we should focus on the risks and benefits of BIP151 and not drag
this discussion into the realm of authentication. This can and should be
done once we have proposals for authentication (and I'm sure this will
be a heated debate).

The only valid risk I have on my list from you, Eric, is the false sense
of security.

My countermeasure for that would be...
- deploy BIP151 together with the simplest form of authentication
(know_hosts / authorized_keys file, no TOFU only editable "by hand")
- make it more clear (in the BIP151 MOTIVATION text) that it won't solve
the privacy/MITM problem without additional authentication.

Or could you elaborate again – without stepping into the realm of
authentication/MITM (which is not part of the BIP or possible already
today) – why BIP151 would make things worse?

</jonas>


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2016-06-30 12:21 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-28  2:31 [bitcoin-dev] BIP 151 use of HMAC_SHA512 Rusty Russell
2016-06-28  7:17 ` [bitcoin-dev] BIP 151 Eric Voskuil
2016-06-28  8:26   ` Jonas Schnelli
2016-06-28 16:45     ` Eric Voskuil
2016-06-28 18:22       ` Peter Todd
2016-06-28 18:35         ` Eric Voskuil
2016-06-28 20:14           ` Peter Todd
2016-06-28 20:29             ` Eric Voskuil
2016-06-28 20:36               ` Peter Todd
2016-06-28 21:22                 ` Eric Voskuil
2016-06-28 21:36                   ` Gregory Maxwell
2016-06-28 21:40                     ` Cameron Garnham
2016-06-28 22:07                       ` Eric Voskuil
2016-06-28 22:33                         ` Cameron Garnham
2016-06-28 23:29                           ` Eric Voskuil
2016-06-29  0:06                             ` Nick ODell
2016-06-28 21:59                     ` Eric Voskuil
     [not found]                       ` <CAAS2fgQ0Ocs8hF+pf+fWfkKKhQwxNKpY=JHpb_bwua7neVO8tg@mail.gmail.com>
2016-06-28 23:34                         ` Eric Voskuil
2016-06-28 20:06       ` Jonas Schnelli
2016-06-28 23:31         ` Eric Voskuil
2016-06-29 11:17       ` Alfie John
2016-06-30 11:56         ` Eric Voskuil
2016-06-30 12:20           ` Jonas Schnelli [this message]
2016-06-30 12:27             ` Eric Voskuil
2016-06-30 12:43               ` Jonas Schnelli
2016-06-30 15:22                 ` Eric Voskuil
2016-06-30 16:52                   ` Peter Todd
2016-06-30 18:25                     ` Eric Voskuil
2016-06-30 19:06                       ` Peter Todd
2016-06-30 20:26                         ` Eric Voskuil
2016-06-28 19:55     ` Gregory Maxwell
2016-06-28 23:33       ` Eric Voskuil
2016-06-29  1:01         ` Gregory Maxwell
2016-06-30  9:57           ` Eric Voskuil
2016-06-30 13:03             ` Pieter Wuille
2016-06-30 15:10               ` Eric Voskuil
2016-08-31 14:29                 ` Pieter Wuille
2016-06-30 13:36             ` Erik Aronesty
2016-06-30 14:47               ` Alfie John
2016-07-02  9:44               ` Chris Priest
2016-06-28 12:13   ` Jonas Schnelli
2016-06-28 17:39     ` Eric Voskuil
2016-06-28  7:19 ` [bitcoin-dev] BIP 151 use of HMAC_SHA512 Jonas Schnelli
2016-06-28  8:31   ` Arthur Chen
2016-06-29 18:34     ` Jonas Schnelli
2016-06-29 20:13       ` Peter Todd
2016-06-29 20:31         ` Jonas Schnelli
2016-06-29  1:00   ` Rusty Russell
2016-06-29  1:38     ` Arthur Chen
2016-06-29  1:56     ` Ethan Heilman
2016-06-29  6:58       ` Pieter Wuille
2016-06-29 14:38         ` Ethan Heilman
2016-06-29 18:46           ` Jonas Schnelli
2016-07-01  3:25       ` Rusty Russell
2016-07-01 22:42         ` Zooko Wilcox
2016-07-04  1:23           ` Arthur Chen
2016-07-04  1:44             ` Arthur Chen
2016-07-04  6:47               ` Jonas Schnelli
2016-07-04  6:37           ` Jonas Schnelli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=57750EAB.3020105@jonasschnelli.ch \
    --to=dev@jonasschnelli.ch \
    --cc=alfie@alfie.wtf \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=eric@voskuil.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox