diff options
| author | Luke Dashjr <luke@dashjr.org> | 2016-03-24 02:16:55 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2016-03-24 02:17:18 +0000 |
| commit | 794042dd19424508ee32c7a9ea0b1ce721b344b3 (patch) | |
| tree | 51e73081dd3a8db9ee748eb60e2be788cfda254b /5a | |
| parent | 2bee95dce90c3fa370028b899c9e0abb56c58e99 (diff) | |
| download | pi-bitcoindev-794042dd19424508ee32c7a9ea0b1ce721b344b3.tar.gz pi-bitcoindev-794042dd19424508ee32c7a9ea0b1ce721b344b3.zip | |
Re: [bitcoin-dev] p2p authentication and encryption BIPs
Diffstat (limited to '5a')
| -rw-r--r-- | 5a/be8377b1deb74748e8dd5eeff8ad3c64ec5676 | 124 |
1 files changed, 124 insertions, 0 deletions
diff --git a/5a/be8377b1deb74748e8dd5eeff8ad3c64ec5676 b/5a/be8377b1deb74748e8dd5eeff8ad3c64ec5676 new file mode 100644 index 000000000..a255de684 --- /dev/null +++ b/5a/be8377b1deb74748e8dd5eeff8ad3c64ec5676 @@ -0,0 +1,124 @@ +Return-Path: <luke@dashjr.org> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id E1B0369 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 24 Mar 2016 02:17:18 +0000 (UTC) +X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 +Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21]) + by smtp1.linuxfoundation.org (Postfix) with ESMTP id 39D3F10A + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 24 Mar 2016 02:17:18 +0000 (UTC) +Received: from ishibashi.localnet (unknown + [IPv6:2001:470:5:265:61b6:56a6:b03d:28d6]) + (Authenticated sender: luke-jr) + by zinan.dashjr.org (Postfix) with ESMTPSA id A1EA338A17C7; + Thu, 24 Mar 2016 02:16:57 +0000 (UTC) +X-Hashcash: 1:25:160324:bitcoin-dev@lists.linuxfoundation.org::iBC2/37vkHJL/M=u:bU01E +X-Hashcash: 1:25:160324:dev@jonasschnelli.ch::NUIjFHu346GhVB3k:AD1P +From: Luke Dashjr <luke@dashjr.org> +To: bitcoin-dev@lists.linuxfoundation.org, + Jonas Schnelli <dev@jonasschnelli.ch> +Date: Thu, 24 Mar 2016 02:16:55 +0000 +User-Agent: KMail/1.13.7 (Linux/4.1.18-gentoo; KDE/4.14.8; x86_64; ; ) +References: <56F2B51C.8000105@jonasschnelli.ch> +In-Reply-To: <56F2B51C.8000105@jonasschnelli.ch> +X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F +X-PGP-Key-ID: BD02942421F4889F +X-PGP-Keyserver: hkp://pgp.mit.edu +MIME-Version: 1.0 +Content-Type: Text/Plain; + charset="iso-8859-15" +Content-Transfer-Encoding: 7bit +Message-Id: <201603240216.56752.luke@dashjr.org> +X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD + autolearn=ham version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +X-Mailman-Approved-At: Thu, 24 Mar 2016 02:23:51 +0000 +Subject: Re: [bitcoin-dev] p2p authentication and encryption BIPs +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.12 +Precedence: list +List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Thu, 24 Mar 2016 02:17:19 -0000 + +On Wednesday, March 23, 2016 3:24:12 PM Jonas Schnelli via bitcoin-dev wrote: +> I have just PRed a draft version of two BIPs I recently wrote. +> https://github.com/bitcoin/bips/pull/362 + +In the future, please submit BIP drafts to the mailing list for comment and +initial peer review before opening a pull request (or requesting a BIP number +assignment), per BIP 1. + +> Each peer that supports p2p authentication, must provide two user editable +> databases (can be a simple record-per-line file). + +As long as the format of these databases is not standardised, it seems +inappropriate to define *any* of this implementation detail in a BIP. + +> A peer can send an authenticate message by wrapping the desired message into +> an <code>auth</code>-message-wrapper to the remote peer. + +How does a peer know what messages the other peer requires to be +authenticated? + +> 33bytes || identity-pubkey || comp.-pubkey || The identity pubkey of the +> requesting peer + +Seems a waste to include this with every single [authenticated] message... + +> 8bytes || auth-msg-id || int64 || up-counting auth-msg-id (0 to INT64MAX) + +Is this required to persist across connections/restarts/possibly complete +reinstalls? + +Can the same auth-msg-id be used for multiple peers, so a message can be +signed once and sent to all N peers? + +> Responding peers must ignore (banning would lead to fingerprinting) the +> requesting peer after 5 unsuccessfully authentication tries to avoid +> resource attacks. + +How does banning in this specific case enable fingerprinting as opposed to any +other banning? + +> The peers should display the identity-pubkey as a identity-address to the +> users, which is a base58-check encoded ripemd160(sha256) hash. + +If this is going to become a general-purpose identity system, I think more is +needed than a simple EC keypair. At the very least, it should probably use a +HD chain and use a new key for every signature (notice you already have auth- +msg-id to use with this!). + +> This proposal is backward compatible. Non supporting peers will ignore the +> <code>auth</code> message. + +... and not process it at all? How is that backward compatible? + +> Encrypting traffic between peers is already possible with VPN, tor, stunnel, +> curveCP or any other encryption mechanism on a deeper OSI level, however, +> most mechanism are not practical for SPV or other DHCP/NAT environment and +> will require significant knowhow in how to setup a secure channel. + +I don't see how Tor fails this criteria... + +> The responding peer will set a session timeout time-interval. The default +> must be 1'800 seconds. + +What default? Is the timeout field optional? Why not simply require it? + +> This proposal is backward compatible. Non supporting peers will ignore the +> <code>enc*</code> messages. + +How should the supporting peer handle the message being ignored? + +Luke + |