Re: [bitcoin-dev] BIP 151 use of HMAC_SHA512

> I haven't been able to find the beginning of this thread, so apologies > if I've misunderstood what this is for, but it _sounds_ like we're > re-inventing HKDF. > I'd recommend reading the paper about HKDF. It stands out among crypto > papers for having a nice clear justification for each of

Re: [bitcoin-dev] BIP 151 use of HMAC_SHA512

I strongly agree! In crypto we should always follow well-studied open standard rather than custom construction. On Fri, Jul 1, 2016 at 10:42 PM, Zooko Wilcox via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I haven't been able to find the beginning of this thread, so apologies >

Re: [bitcoin-dev] BIP 151

On 6/30/16, Erik Aronesty via bitcoin-dev wrote: > > I would like to see a PGP-like "web of trust" proposal for both the > security of the bitcoin network itself /and/ (eventually) of things like > transmission of bitcoin addresses. > > Something where nodes

Re: [bitcoin-dev] BIP 151 use of HMAC_SHA512

I haven't been able to find the beginning of this thread, so apologies if I've misunderstood what this is for, but it _sounds_ like we're re-inventing HKDF. I'd recommend reading the paper about HKDF. It stands out among crypto papers for having a nice clear justification for each of its design

Re: [bitcoin-dev] BIP 151 use of HMAC_SHA512

Ethan Heilman writes: >>It's also not clear to me why the HMAC, vs just SHA256(key|cipher-type|mesg). >> But that's probably just my crypto ignorance... > > SHA256(key|cipher-type|mesg) is an extremely insecure MAC because of > the length extension property of SHA256. > > If I

Re: [bitcoin-dev] BIP 151

> On Jun 30, 2016, at 9:06 PM, Peter Todd wrote: > > On Thu, Jun 30, 2016 at 08:25:45PM +0200, Eric Voskuil wrote: >>> To be clear, are you against Bitcoin Core's tor support? >>> >>> Because node-to-node connections over tor are encrypted, and make use of >>> onion >>>

Re: [bitcoin-dev] BIP 151

On Thu, Jun 30, 2016 at 08:25:45PM +0200, Eric Voskuil wrote: > > To be clear, are you against Bitcoin Core's tor support? > > > > Because node-to-node connections over tor are encrypted, and make use of > > onion > > addresses, which are self-authenticated in the exact same way as BIP151 > >

Re: [bitcoin-dev] BIP 151

> On Jun 30, 2016, at 6:52 PM, Peter Todd wrote: > >> On Thu, Jun 30, 2016 at 05:22:08PM +0200, Eric Voskuil via bitcoin-dev wrote: >> >>> On Jun 30, 2016, at 2:43 PM, Jonas Schnelli wrote: >>> >> The core problem posed by BIP151 is a MITM

Re: [bitcoin-dev] BIP 151

On Thu, Jun 30, 2016 at 05:22:08PM +0200, Eric Voskuil via bitcoin-dev wrote: > > > On Jun 30, 2016, at 2:43 PM, Jonas Schnelli wrote: > > > The core problem posed by BIP151 is a MITM attack. The implied solution > (BIP151 + authentication) requires that a peer

Re: [bitcoin-dev] BIP 151

> On Jun 30, 2016, at 2:43 PM, Jonas Schnelli wrote: > 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

Re: [bitcoin-dev] BIP 151

Pieter, these are in my opinion very reasonable positions. I've made some observations inline. > On Jun 30, 2016, at 3:03 PM, Pieter Wuille wrote: > > On Thu, Jun 30, 2016 at 11:57 AM, Eric Voskuil via bitcoin-dev > wrote: >> The

Re: [bitcoin-dev] BIP 151

On Thu, Jun 30, 2016 at 09:36:57AM -0400, Erik Aronesty via bitcoin-dev wrote: > Encrypting links in a network without identity doesn't really seem to help > enough for the costs to be justified. Passive is still better than none. > I would like to see a PGP-like "web of trust" proposal for both

Re: [bitcoin-dev] BIP 151

I agree. Encrypting links in a network without identity doesn't really seem to help enough for the costs to be justified. I would like to see a PGP-like "web of trust" proposal for both the security of the bitcoin network itself /and/ (eventually) of things like transmission of bitcoin

Re: [bitcoin-dev] BIP 151

On Thu, Jun 30, 2016 at 11:57 AM, Eric Voskuil via bitcoin-dev wrote: > The proliferation of node identity is my primary concern - this relates to > privacy and the security of the network. I think this is a reasonable concern. However, node identity is

Re: [bitcoin-dev] BIP 151

>>> 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

Re: [bitcoin-dev] BIP 151

> On Jun 30, 2016, at 2:20 PM, Jonas Schnelli wrote: > > >> 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

Re: [bitcoin-dev] BIP 151

> 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

Re: [bitcoin-dev] BIP 151

Hi Alfie, 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

Re: [bitcoin-dev] BIP 151

On Jun 29, 2016, at 3:01 AM, Gregory Maxwell wrote: > >> On Tue, Jun 28, 2016 at 11:33 PM, Eric Voskuil wrote: >> I don't follow this comment. The BIP aims quite clearly at "SPV" wallets as >> its justifying scenario. > > It cites SPV as an example, doesn't

Re: [bitcoin-dev] BIP 151 use of HMAC_SHA512

> On Wed, Jun 29, 2016 at 08:34:06PM +0200, Jonas Schnelli via bitcoin-dev > wrote: >>> Based on previous crypto analysis result, the actual security of SHA512 >>> is not significantly higher than SHA256. >>> maybe we should consider SHA3? >> >> As far as I know the security of the symmetric

Re: [bitcoin-dev] BIP 151 use of HMAC_SHA512

On Wed, Jun 29, 2016 at 08:34:06PM +0200, Jonas Schnelli via bitcoin-dev wrote: > > Based on previous crypto analysis result, the actual security of SHA512 > > is not significantly higher than SHA256. > > maybe we should consider SHA3? > > As far as I know the security of the symmetric cipher key

Re: [bitcoin-dev] BIP 151 use of HMAC_SHA512

Hi Ethan >> It is important to include the cipher-type into the symmetric cipher key to >> avoid weak-cipher-attacks. > > the cipher-type here refers to the ECDH negotiation parameters? No. Not to the ECDH negotiation. BIP151 specifies a flexible symmetric key cipher type negotiation,

Re: [bitcoin-dev] BIP 151 use of HMAC_SHA512

> Based on previous crypto analysis result, the actual security of SHA512 > is not significantly higher than SHA256. > maybe we should consider SHA3? As far as I know the security of the symmetric cipher key mainly depends on the PRNG and the ECDH scheme. The HMAC_SHA512 will be used to "drive"

Re: [bitcoin-dev] BIP 151 use of HMAC_SHA512

Just to clarify in BIP-0151 when it says: >It is important to include the cipher-type into the symmetric cipher key to >avoid weak-cipher-attacks. the cipher-type here refers to the ECDH negotiation parameters? On Wed, Jun 29, 2016 at 2:58 AM, Pieter Wuille wrote: >

Re: [bitcoin-dev] BIP 151

On Tue, Jun 28, 2016 at 06:45:58PM +0200, Eric Voskuil via bitcoin-dev wrote: > > then we should definitively use a form of end-to-end encryption between > > nodes. Built into the network layer. > > Widespread application of this model is potentially problematic. It is a > non-trivial problem to

Re: [bitcoin-dev] BIP 151 use of HMAC_SHA512

On Jun 29, 2016 07:05, "Ethan Heilman via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > > >It's also not clear to me why the HMAC, vs just SHA256(key|cipher-type|mesg). But that's probably just my crypto ignorance... > > SHA256(key|cipher-type|mesg) is an extremely insecure MAC

Re: [bitcoin-dev] BIP 151 use of HMAC_SHA512

>It's also not clear to me why the HMAC, vs just SHA256(key|cipher-type|mesg). >But that's probably just my crypto ignorance... SHA256(key|cipher-type|mesg) is an extremely insecure MAC because of the length extension property of SHA256. If I have a tag y = SHA256(key|cipher-type|mesg), I can

Re: [bitcoin-dev] BIP 151 use of HMAC_SHA512

HMAC has proven security property. It is still secure even when underlying crypto hashing function has collision resistant weakness. For example, MD5 is considered completely insecure now, but HMAC-MD5 is still considered secure. When in doubt, we should always use HMAC for MAC(Message

Re: [bitcoin-dev] BIP 151 use of HMAC_SHA512

Jonas Schnelli writes: >> To quote: >> >>> HMAC_SHA512(key=ecdh_secret|cipher-type,msg="encryption key"). >>> >>> K_1 must be the left 32bytes of the HMAC_SHA512 hash. >>> K_2 must be the right 32bytes of the HMAC_SHA512 hash. >> >> This seems a weak reason to introduce

Re: [bitcoin-dev] BIP 151

On Tue, Jun 28, 2016 at 11:33 PM, Eric Voskuil wrote: > I don't follow this comment. The BIP aims quite clearly at "SPV" wallets as > its justifying scenario. It cites SPV as an example, doesn't mention bloom filters.. and sure-- sounds like the bip text should make the >>

Re: [bitcoin-dev] BIP 151

>They both require authentication, Yeah, but not the same *sort* of authentication. As a trivial example, you could have ten servers that sign long-term keys for nodes. All that they need to check is that the node requesting a signature owns the corresponding IP address. On the other hand, 'evil

Re: [bitcoin-dev] BIP 151

>> On Jun 29, 2016, at 12:22 AM, Gregory Maxwell wrote: >> >> On Tue, Jun 28, 2016 at 9:59 PM, Eric Voskuil wrote: >> Passing the session ID out of band is authentication. As this is explicitly >> not part of BIP151 it cannot be that BIP151 provides the

Re: [bitcoin-dev] BIP 151

On Jun 28, 2016, at 9:55 PM, Gregory Maxwell via bitcoin-dev wrote: >> I understand the use, when coupled with a yet-to-be-devised identity system, >> with Bloom filter features. Yet these features > > This is a bit of a strawman, you've selected a

Re: [bitcoin-dev] BIP 151

On Jun 28, 2016, at 10:06 PM, Jonas Schnelli wrote: >>> In my opinion, the question should be "why would you _not_ encrypt". >> >> 1) creation of a false sense of security > > False sense of security is mostly a communication issue. > BIP151 does focus on encryption (not

Re: [bitcoin-dev] BIP 151

Your description of the two scenarios reduces to one. They both require authentication, and if you intend to connect to potentially evil nodes you aren't securing anything with link level security except the knowledge that your potentially evil node connection remains so. e > On Jun 29, 2016,

Re: [bitcoin-dev] BIP 151

There are two different topics mixed up here. 1. Link-level security (secure connection to the node we intended to connect to). 2. Node-level security (aka; don't connect to a 'evil node'). The fist requires link-level encryption and authentication. The second requires identity

Re: [bitcoin-dev] BIP 151

Hi Cameron, good to hear from you! > On Jun 28, 2016, at 11:40 PM, Cameron Garnham wrote: > > Unauthenticated link level encryption is wonderful! MITM attacks are > overrated; as they require an active attacker. This is not really the case with Bitcoin. A MITM attack does

Re: [bitcoin-dev] BIP 151

> On Jun 28, 2016, at 11:36 PM, Gregory Maxwell wrote: > > On Tue, Jun 28, 2016 at 9:22 PM, Eric Voskuil via bitcoin-dev > wrote: >> An "out of band key check" is not part of BIP151. > > It has a session ID for this purpose. Passing the

Re: [bitcoin-dev] BIP 151

Unauthenticated link level encryption is wonderful! MITM attacks are overrated; as they require an active attacker. Stopping passive attacks is the low hanging fruit. This should be taken first. Automated and secure peer authentication in a mesh network is a huge topic. One of the unsolved

Re: [bitcoin-dev] BIP 151

On Tue, Jun 28, 2016 at 9:22 PM, Eric Voskuil via bitcoin-dev wrote: > An "out of band key check" is not part of BIP151. It has a session ID for this purpose. > It requires a secure channel and is authentication. So BIP151 doesn't provide > the tools to

Re: [bitcoin-dev] BIP 151

> On Jun 28, 2016, at 10:36 PM, Peter Todd wrote: > >> On Tue, Jun 28, 2016 at 10:29:54PM +0200, Eric Voskuil wrote: >> >> On Jun 28, 2016, at 10:14 PM, Peter Todd wrote: On Tue, Jun 28, 2016 at 08:35:26PM +0200, Eric Voskuil wrote:

Re: [bitcoin-dev] BIP 151

On Tue, Jun 28, 2016 at 10:29:54PM +0200, Eric Voskuil wrote: > > > > On Jun 28, 2016, at 10:14 PM, Peter Todd wrote: > > > >> On Tue, Jun 28, 2016 at 08:35:26PM +0200, Eric Voskuil wrote: > >> Hi Peter, > >> > >> What in this BIP makes a MITM attack easier (or easy) to

Re: [bitcoin-dev] BIP 151

> On Jun 28, 2016, at 10:14 PM, Peter Todd wrote: > >> On Tue, Jun 28, 2016 at 08:35:26PM +0200, Eric Voskuil wrote: >> Hi Peter, >> >> What in this BIP makes a MITM attack easier (or easy) to detect, or >> increases the probability of one being detected? > > BIP151

Re: [bitcoin-dev] BIP 151

On Tue, Jun 28, 2016 at 08:35:26PM +0200, Eric Voskuil wrote: > Hi Peter, > > What in this BIP makes a MITM attack easier (or easy) to detect, or increases > the probability of one being detected? BIP151 gives users the tools to detect a MITM attack. It's kinda like PGP in that way: lots of

Re: [bitcoin-dev] BIP 151

>> In my opinion, the question should be "why would you _not_ encrypt". > > 1) creation of a false sense of security False sense of security is mostly a communication issue. BIP151 does focus on encryption (not trust). Are users aware of the fact that ISP/WiFi-Providers can track their bitcoin

Re: [bitcoin-dev] BIP 151

> I understand the use, when coupled with a yet-to-be-devised identity system, > with Bloom filter features. Yet these features This is a bit of a strawman, you've selected a single narrow usecase which isn't proposed by the BIP and then argue it is worthless. I agree that example doesn't have

Re: [bitcoin-dev] BIP 151

Hi Peter, What in this BIP makes a MITM attack easier (or easy) to detect, or increases the probability of one being detected? e > On Jun 28, 2016, at 8:22 PM, Peter Todd wrote: > > On Tue, Jun 28, 2016 at 06:45:58PM +0200, Eric Voskuil via bitcoin-dev wrote: >>> 1)

Re: [bitcoin-dev] BIP 151

On Tue, Jun 28, 2016 at 06:45:58PM +0200, Eric Voskuil via bitcoin-dev wrote: > > 1) Transaction censorship > > ISPs, WIFI provider or any other MITM, can holdback/censor unconfirmed > > transactions. Regardless if you are a miner or a validation/wallet node. > > > > 2) Peer censorship > > MITM

Re: [bitcoin-dev] BIP 151

continued from previous post... > On Jun 28, 2016, at 2:13 PM, Jonas Schnelli via bitcoin-dev > wrote: > > Hi Eric > > Sorry for not directly addressing your points. No problem. Thanks for the detailed replies. > I try to be more precise in this follow

Re: [bitcoin-dev] BIP 151

Hi Jonas, I'll follow up in your second reply as well. Responses inline: > On Jun 28, 2016, at 10:26 AM, Jonas Schnelli via bitcoin-dev > wrote: > > Hi Eric > >> I haven't seen much discussion here on the rationale behind BIP 151. >> Apologies if I

Re: [bitcoin-dev] BIP 151

Hi Eric Sorry for not directly addressing your points. I try to be more precise in this follow up email: > I understand the use, when coupled with a yet-to-be-devised identity system, > with Bloom filter features. Yet these features are client-server in nature. > Libbitcoin (for example)

Re: [bitcoin-dev] BIP 151 use of HMAC_SHA512

Based on previous crypto analysis result, the actual security of SHA512 is not significantly higher than SHA256. maybe we should consider SHA3? On Tue, Jun 28, 2016 at 3:19 PM, Jonas Schnelli via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > To quote: > > > >>

Re: [bitcoin-dev] BIP 151

Hi Eric > I haven't seen much discussion here on the rationale behind BIP 151. > Apologies if I missed it. I'm trying to understand why libbitcoin (or any > node) would want to support it. > > I understand the use, when coupled with a yet-to-be-devised identity system, > with Bloom filter

Re: [bitcoin-dev] BIP 151 use of HMAC_SHA512

> To quote: > >> HMAC_SHA512(key=ecdh_secret|cipher-type,msg="encryption key"). >> >> K_1 must be the left 32bytes of the HMAC_SHA512 hash. >> K_2 must be the right 32bytes of the HMAC_SHA512 hash. > > This seems a weak reason to introduce SHA512 to the mix. Can we just > make: > > K_1 =

[bitcoin-dev] BIP 151

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I haven't seen much discussion here on the rationale behind BIP 151. Apologies if I missed it. I'm trying to understand why libbitcoin (or any node) would want to support it. I understand the use, when coupled with a yet-to-be-devised identity

[bitcoin-dev] BIP 151 use of HMAC_SHA512

To quote: > HMAC_SHA512(key=ecdh_secret|cipher-type,msg="encryption key"). > > K_1 must be the left 32bytes of the HMAC_SHA512 hash. > K_2 must be the right 32bytes of the HMAC_SHA512 hash. This seems a weak reason to introduce SHA512 to the mix. Can we just make: K_1 =

Re: [bitcoin-dev] BIP 151 MITM

Hi > On Thu, Jun 09, 2016 at 01:24:09AM +, Gregory Maxwell wrote: >> Reduction to plaintext isn't an interesting attack vector for an active >> attacker: they can simply impersonate the remote side. >> >> This is addressed via authentication, where available, which is done by a >> separate

Re: [bitcoin-dev] BIP 151 MITM

On Thu, Jun 09, 2016 at 01:24:09AM +, Gregory Maxwell wrote: > Reduction to plaintext isn't an interesting attack vector for an active > attacker: they can simply impersonate the remote side. > > This is addressed via authentication, where available, which is done by a > separate specification

Re: [bitcoin-dev] BIP 151 MITM

On Wed, Jun 8, 2016 at 11:47 PM, Alfie John via bitcoin-dev wrote: > Hi folks, > > Overall I think BIP 151 is a good idea. However unless I'm mistaken, what's to > prevent someone between peers to suppress the initial 'encinit' message during > negotiation,

[bitcoin-dev] BIP 151 MITM

Hi folks, Overall I think BIP 151 is a good idea. However unless I'm mistaken, what's to prevent someone between peers to suppress the initial 'encinit' message during negotiation, causing both to fallback to plaintext? Peers should negotiate a secure channel from the outset or backout entirely