[bitcoin-dev] BIP 151 use of HMAC_SHA512

[bitcoin-dev] BIP 151 use of HMAC_SHA512

[Rusty Russell]

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 = HMAC_SHA256(key=ecdh_secret|cipher-type,msg="header encryption key")
K_2 = HMAC_SHA256(key=ecdh_secret|cipher-type,msg="body encryption key")

Thanks,
Rusty.

[bitcoin-dev] BIP 151

[Eric Voskuil]

-----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 system, with Bloom filter features. Yet these features are client-server in nature. Libbitcoin (for example) supports client-server features on an independent port (and implements a variant of CurveCP for encryption and identity). My concern arises with application of identity to the P2P protocol (excluding Bloom filter features).

It seems to me that the desire to secure against the weaknesses of BF is being casually generalized to the P2P network. That generalization may actually weaken the security of the P2P protocol. One might consider the proper resolution is to move the BF features to a client-server protocol.

The BIP does not make a case for other scenarios, or contemplate the significant problems associated with key distribution in any identity system. Given that the BIP relies on identity, these considerations should be fully vetted before heading down another blind alley.

e
-----BEGIN PGP SIGNATURE-----
Version: oPenGP 6.0 on iOS

iQEVAwUBV3IkYjzYwH8LXOFOAQg+iggAkFShi/ibZXiVv3A3z1a1SMd+4ar0kiZk
mCkBBZaatoW8tXVZmuv5xzLnj3ali9Y4jp/3h2nUJ1B4ov2kcB0kZIKE/a1DTFwb
4X3uSzgu0lEAqSZormOvt7Op46NPn6KJ+/wTtP4lUFU72lSd7qrVKMlCVc88VE7/
pMloKSc69nAeFIkyWbOUi/zDzefu/5tarfif85jumooYjPmAwJnkgiPCqpqBbuga
5lBdS1r47KK+SaDFl6Cbn4i/c6tBPLTnu+TR7TEKOW5vwVA7eUqb6SOK7pETWJGK
0Ii4ZWYt7MOPSEda381CMjWEwtsCNp0eI4GPZAAz+jNLo4G1+PAbaw==
=Balw
-----END PGP SIGNATURE-----

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

[Jonas Schnelli]

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

> 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 = HMAC_SHA256(key=ecdh_secret|cipher-type,msg="header encryption key")
> K_2 = HMAC_SHA256(key=ecdh_secret|cipher-type,msg="body encryption key")

SHA512_HMAC is used by BIP32 [1] and I guess most clients will somehow
make use of bip32 features. I though a single SHA512_HMAC operation is
cheaper and simpler then two SHA256_HMAC.

AFAIK, sha256_hmac is also not used by the current p2p & consensus layer.
Bitcoin-Core uses it for HTTP RPC auth and Tor control.

I don't see big pros/cons for SHA512_HMAC over SHA256_HMAC.

</jonas>

[1]
https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#child-key-derivation-ckd-functions


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

Re: [bitcoin-dev] BIP 151

[Jonas Schnelli]

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

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 features. Yet these features are client-server in nature. Libbitcoin (for example) supports client-server features on an independent port (and implements a variant of CurveCP for encryption and identity). My concern arises with application of identity to the P2P protocol (excluding Bloom filter features).
> 
> It seems to me that the desire to secure against the weaknesses of BF is being casually generalized to the P2P network. That generalization may actually weaken the security of the P2P protocol. One might consider the proper resolution is to move the BF features to a client-server protocol.
> 
> The BIP does not make a case for other scenarios, or contemplate the significant problems associated with key distribution in any identity system. Given that the BIP relies on identity, these considerations should be fully vetted before heading down another blind alley.


In my opinion, the question should be "why would you _not_ encrypt".


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 can remove or add entries from a "addr" message.

3) Fingerprinting
ISPs or any other MITM can intercept/inject fingerprinting relevant
messages like "mempool" to analyze the bitcoin network.

4) SPV
For obvious reasons regarding BF (see BIP or above).

5) Goundwork for a "client-server" model over the P2P channel
Fee estimation, bloom-filters, or any other message type that requires
authentication.

I would not reduce BIP151 to only solve the BF privacy/censorship problem.

If we agree that censorship-resistance is one of the main properties of
Bitcoin, then we should definitively use a form of end-to-end encryption
between nodes. Built into the network layer.

There are plenty of other options to solve this problem. stunnel,
Bernsteins CurveCP, VPN, etc. which are available since years.
But the reality has shown that most bitcoin traffic is still unencrypted.
Example: IIRC non of the available SPV wallets can "speak" on of the
possible encryption techniques. Encrypting traffic below the application
layer is extremely hard to set up for non-experienced users.

On top of that, encryption allows us to drop the SHA256 checksum per p2p
message which should result in a better performance on the network layer
once BIP151 is deployed.

I agree that BIP151 _must_ be deployed together with an authentication
scheme (I'm working on that) to protect again MITM during encryption
initialization.

---
</jonas>


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

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

[Arthur Chen]

[-- Attachment #1: Type: text/plain, Size: 1509 bytes --]

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:
> >
> >> 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 = HMAC_SHA256(key=ecdh_secret|cipher-type,msg="header encryption
> key")
> > K_2 = HMAC_SHA256(key=ecdh_secret|cipher-type,msg="body encryption key")
>
> SHA512_HMAC is used by BIP32 [1] and I guess most clients will somehow
> make use of bip32 features. I though a single SHA512_HMAC operation is
> cheaper and simpler then two SHA256_HMAC.
>
> AFAIK, sha256_hmac is also not used by the current p2p & consensus layer.
> Bitcoin-Core uses it for HTTP RPC auth and Tor control.
>
> I don't see big pros/cons for SHA512_HMAC over SHA256_HMAC.
>
> </jonas>
>
> [1]
>
> https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#child-key-derivation-ckd-functions
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>


-- 
Xuesong (Arthur) Chen
Senior Principle Engineer
BlockChain Technologist
BTCC

[-- Attachment #2: Type: text/html, Size: 2528 bytes --]

Re: [bitcoin-dev] BIP 151

[Jonas Schnelli]

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

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) supports client-server features on an independent port (and implements a variant of CurveCP for encryption and identity). My concern arises with application of identity to the P2P protocol (excluding Bloom filter features).

I think the bloom filter SPV usecase is not "pure client-server". SPV
clients could request from/broadcast to multiple "trusted nodes".
Trusted nodes could be nodes where the operators have shared
identities/keys in advance over a different channel.

Further private p2p extensions (lets say a p2p form of the estimatefee
command) are something which needs to be discussed first and not
something that is encouraged or outlined in BIP151.

> It seems to me that the desire to secure against the weaknesses of BF is being casually generalized to the P2P network. That generalization may actually weaken the security of the P2P protocol. One might consider the proper resolution is to move the BF features to a client-server protocol.

I don't see reasons why BIP151 could weaken the security of the P2P
network. Can you point out some specific concerns?


> The BIP does not make a case for other scenarios, or contemplate the significant problems associated with key distribution in any identity system. Given that the BIP relies on identity, these considerations should be fully vetted before heading down another blind alley.

BIP151 does not rely on identities. BIP151 does not use persisted keys
(only ephemeral keys). The authentication/identity system needs to be
described in a another BIP.
But correct, BIP151 without a form of authentication/identity management
is vulnerable to all sorts of MITM attacks and that's why I think BIP151
must be deployed together with an p2p authentication scheme.

Scope creeping and the risks of overspecifying is the main reason to
focus on the "pure encryption part" in BIP151.

Thanks
---
</jonas>


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

Re: [bitcoin-dev] BIP 151

[Eric Voskuil]

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 <bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
> 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 features. Yet these features are client-server in nature. Libbitcoin (for example) supports client-server features on an independent port (and implements a variant of CurveCP for encryption and identity). My concern arises with application of identity to the P2P protocol (excluding Bloom filter features).
>> 
>> It seems to me that the desire to secure against the weaknesses of BF is being casually generalized to the P2P network. That generalization may actually weaken the security of the P2P protocol. One might consider the proper resolution is to move the BF features to a client-server protocol.
>> 
>> The BIP does not make a case for other scenarios, or contemplate the significant problems associated with key distribution in any identity system. Given that the BIP relies on identity, these considerations should be fully vetted before heading down another blind alley.

> In my opinion, the question should be "why would you _not_ encrypt".

1) creation of a false sense of security
2) as a tradeoff against anonymity
3) benefit does not justify cost

> 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 can remove or add entries from a "addr" message.
> 
> 3) Fingerprinting
> ISPs or any other MITM can intercept/inject fingerprinting relevant
> messages like "mempool" to analyze the bitcoin network.

Encryption alone cannot protect against a MITM attack in an anonymous and permissionless network. This is accepted in the BIP (and your follow-up reply).

> 4) SPV
> For obvious reasons regarding BF (see BIP or above).
> 
> 5) Goundwork for a "client-server" model over the P2P channel
> Fee estimation, bloom-filters, or any other message type that requires
> authentication.

I do not challenge the usefulness and appropriateness of encryption with authentication in a client-server blockchain protocol.

> I would not reduce BIP151 to only solve the BF privacy/censorship problem.
> 
> If we agree that censorship-resistance is one of the main properties of Bitcoin,

We do.

> then we should definitively use a form of end-to-end encryption between nodes. Built into the network layer.

This is the assumption that I'm questioning.

> There are plenty of other options to solve this problem. stunnel,
> Bernsteins CurveCP, VPN, etc. which are available since years.
> But the reality has shown that most bitcoin traffic is still unencrypted.

The question arises from concern over the security of the network in the case where encryption (and therefore authentication) is pervasive.

As you point out, anyone can set up a private network of nodes today. These nodes must also connect to the permissionless network to maintain the chain. These nodes constitute a trust zone within Bitcoin. This zone of exclusion operates as a single logical node from the perspective of the Bitcoin security model (one entity controls the validation rules for all nodes).

Widespread application of this model is potentially problematic. It is a non-trivial problem to design a distributed system that requires authentication but without identity and without central control. In fact this may be more challenging than Bitcoin itself. Trust on first use (TOFU) does not solve this problem.

In my opinion this question has not received sufficient consideration to warrant proceeding with a network encryption scheme (which concerns me as well, but as I consider it premature I won't comment).

> Example: IIRC non of the available SPV wallets can "speak" on of the
> possible encryption techniques. Encrypting traffic below the application
> layer is extremely hard to set up for non-experienced users.

Bloom filters can (and IMO should) be isolated from the P2P protocol. Also, if the proposal creates an insecurity its ease of deployment is moot.

> On top of that, encryption allows us to drop the SHA256 checksum per p2p
> message which should result in a better performance on the network layer
> once BIP151 is deployed.

I would not consider this a performance enhancing proposal. Simply dropping the checksum seems like a better option. But again, it is moot if it creates an insecurity.

> I agree that BIP151 _must_ be deployed together with an authentication
> scheme (I'm working on that) to protect again MITM during encryption
> initialization.

At a minimum I would propose that you modify BIP151 to declare a dependency on a future BIP, making BIP151 incomplete without it. I think we can agree that it would be unadvisable to deploy (and therefore to implement) encryption alone.

I'll respond to the question of authentication in your follow-up post.

e

> ---
> </jonas>
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP 151

[Eric Voskuil]

continued from previous post...

> On Jun 28, 2016, at 2:13 PM, Jonas Schnelli via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> 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 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) supports client-server features on an independent port (and implements a variant of CurveCP for encryption and identity). My concern arises with application of identity to the P2P protocol (excluding Bloom filter features).
> 
> I think the bloom filter SPV usecase is not "pure client-server". SPV
> clients could request from/broadcast to multiple "trusted nodes".

I have referred to the Bloom filters messages. These are clearly asymmetric in nature. Despite being possible it is not a valid use case for a full node to make BF requests to another node.

One client to multiple servers is still client-server for the sake of this discussion. The nature of the P2P protocol is synchronization of content between all nodes/peers. If the protocol is asymmetric the semantics, and therefore use cases, are different.

FWIW posting a transaction to the network can be done using the P2P protocol, connecting for a short period of time. But this is also a client-server scenario and is a hack when done (full disclosure, bx provides both P2P and client-server commands for tx posting). Broadcasting is naturally the behavior of a full node.

> Trusted nodes could be nodes where the operators have shared identities/keys in advance over a different channel.

Yes, this is necessarily the case in order to prevent a MITM attack. This is the basis of my concern.

> Further private p2p extensions (lets say a p2p form of the estimatefee
> command) are something which needs to be discussed first and not
> something that is encouraged or outlined in BIP151.

Sure, but then let us not make assumptions about it in the context of this discussion. Libbitcoin provides fee estimation by monitoring broadcast penetration using a client-server protocol with an optional subscription mechanism.

>> It seems to me that the desire to secure against the weaknesses of BF is being casually generalized to the P2P network. That generalization may actually weaken the security of the P2P protocol. One might consider the proper resolution is to move the BF features to a client-server protocol.
> 
> I don't see reasons why BIP151 could weaken the security of the P2P network. Can you point out some specific concerns?

TOFU cannot prevent MITM attacks (the goal of the encryption). Authentication requires a secure (trusted) side channel by which to distribute public keys. This presents what I consider a significant problem. If widespread, control over this distribution network would constitute control over who can use Bitcoin.

The effort to prevent censorship could actually enable it. I don't think it would get that far. Someone would point this out in the process of vetting the authentication BIP, and the result would be the scrapping of BIP151.

>> The BIP does not make a case for other scenarios, or contemplate the significant problems associated with key distribution in any identity system. Given that the BIP relies on identity, these considerations should be fully vetted before heading down another blind alley.
> 
> BIP151 does not rely on identities. BIP151 does not use persisted keys
> (only ephemeral keys).

BIP 151 is incomplete without authentication.

> The authentication/identity system needs to be described in a another BIP.
> But correct, BIP151 without a form of authentication/identity management
> is vulnerable to all sorts of MITM attacks and that's why I think BIP151
> must be deployed together with an p2p authentication scheme.

Agree, but my problem is that I do not believe we can assume this is a solvable problem.

> Scope creeping and the risks of overspecifying is the main reason to
> focus on the "pure encryption part" in BIP151.

Understood, yet this is the basis of my blind alley comment.

e

> Thanks
> ---
> </jonas>

Re: [bitcoin-dev] BIP 151

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1648 bytes --]

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 can remove or add entries from a "addr" message.
> > 
> > 3) Fingerprinting
> > ISPs or any other MITM can intercept/inject fingerprinting relevant
> > messages like "mempool" to analyze the bitcoin network.
> 
> Encryption alone cannot protect against a MITM attack in an anonymous and permissionless network. This is accepted in the BIP (and your follow-up reply).

Being able to easily detect MITM attacks is a _huge_ step forward that
shouldn't be underestimated; even if 99% of users aren't in a position to
detect the MITM you only need a small subset of users that do the necessary
checks to alert the wider community, who can then respond with stronger
security measures. Those measures are likely to be more costly - authenticated
systems are significantly harder than not - so better to save your efforts
until the need for them is more obvious.

Also the fact that an attack has a reasonable probability of detection is a big
disincentive for many types of attackers - note how one of the things revealed
in the Snowden leaks was the fact that the NSA generally tries quite hard to
avoid tipping off targets to the fact that they're being surveilled, with a
myriad of carefully scripted policies to control when and how exploits are used
against targets.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [bitcoin-dev] BIP 151

[Eric Voskuil]

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 <pete@petertodd.org> wrote:
> 
> 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 can remove or add entries from a "addr" message.
>>> 
>>> 3) Fingerprinting
>>> ISPs or any other MITM can intercept/inject fingerprinting relevant
>>> messages like "mempool" to analyze the bitcoin network.
>> 
>> Encryption alone cannot protect against a MITM attack in an anonymous and permissionless network. This is accepted in the BIP (and your follow-up reply).
> 
> Being able to easily detect MITM attacks is a _huge_ step forward that
> shouldn't be underestimated; even if 99% of users aren't in a position to
> detect the MITM you only need a small subset of users that do the necessary
> checks to alert the wider community, who can then respond with stronger
> security measures. Those measures are likely to be more costly - authenticated
> systems are significantly harder than not - so better to save your efforts
> until the need for them is more obvious.
> 
> Also the fact that an attack has a reasonable probability of detection is a big
> disincentive for many types of attackers - note how one of the things revealed
> in the Snowden leaks was the fact that the NSA generally tries quite hard to
> avoid tipping off targets to the fact that they're being surveilled, with a
> myriad of carefully scripted policies to control when and how exploits are used
> against targets.
> 
> -- 
> https://petertodd.org 'peter'[:-1]@petertodd.org

Re: [bitcoin-dev] BIP 151

[Gregory Maxwell]

> 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 much value (and I believe that
eventually the BIP37 bloom filters should be removed from the
protocol).

Without something like BIP151 network participants cannot have privacy
for the transactions they originate within the protocol against
network observers. Even if, through some extraordinary effort, their
own first hop is encrypted, unencrypted later hops would rapidly
expose significant information about transaction origins in the
network.

Without something like BIP151 authenticated links are not possible, so
manually curated links (addnode/connect) cannot be counted on to
provide protection against partitioning sybils.

Along the way BIP151 appears that it will actually make the protocol faster.

> Given that the BIP relies on identity

This is untrue. The proposal is an ephemerally keyed opportunistic
encryption system. The privacy against a network observer does not
depend on authentication, much less "identity".  And when used with
authentication at all it makes interception strongly detectable after
the fact.

> The BIP does not [...] contemplate the significant problems associated with key distribution in any identity system

Because it does not propose any "identity system" or authorization
(also, I object to your apparent characterization of authentication as
as an 'identity system'-- do you also call Bitcoin addresses an
identity system?).

That said, manually maintaining adds nodes to your own and somewhat
trusted nodes is a recommend best practice for miners and other high
value systems which is rendered much less effective due to a lack of
authentication, there is no significant key distribution problem in
that case, and I expect the future auth BIP (Jonas had one before, but
it was put aside for now to first focus on the link layer encryption)
to address that case quite well.

Re: [bitcoin-dev] BIP 151

[Jonas Schnelli]

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

>> 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 spending (if they use SPV+BF) and link it with other internet
traffic or sell the data to anyone who is interested to do correlation?

Are node operators aware of the possibilities that ISPs/Data-Centers,
etc. can hold back peers, etc.?

If there is a false sense of security/anonymity, then we are already
deep into this territory.
BIP151 was designed as a puzzle-pice towards better security and better
censorship resistance. You shouldn't project all sorts of "false sense
of security" into BIP151. Is a stepping stone towards greater security.

> 2) as a tradeoff against anonymity

Can you point out the tradeoffs?
BIP151 does not introduce fingerprinting possibilities.

> 3) benefit does not justify cost

Can you elaborate the costs?
[Extremely simplified]: we need 300 lines of code from openssh
(ChaCha20-Poly1305@openssl) and some ECDH magic (already in
Bitcoin-Cores codebase) together with two or three (maybe payed)
cryptoanalysis once the implementation is done.


>> There are plenty of other options to solve this problem. stunnel,
>> Bernsteins CurveCP, VPN, etc. which are available since years.
>> But the reality has shown that most bitcoin traffic is still unencrypted.
> 
> The question arises from concern over the security of the network in the case where encryption (and therefore authentication) is pervasive.
> 
> As you point out, anyone can set up a private network of nodes today. These nodes must also connect to the permissionless network to maintain the chain. These nodes constitute a trust zone within Bitcoin. This zone of exclusion operates as a single logical node from the perspective of the Bitcoin security model (one entity controls the validation rules for all nodes).
> 
> Widespread application of this model is potentially problematic. It is a non-trivial problem to design a distributed system that requires authentication but without identity and without central control. In fact this may be more challenging than Bitcoin itself. Trust on first use (TOFU) does not solve this problem.

Yes. There is no plan to adopt a TUFO scheme. Bip151 does not use TUFO
it does not cover "trust" (It just encrypt all traffic).

Imaging Bip151 together with a simple form of preshared EC key
authentication (nonce signing or similar). You could drastically
increase the security/censor-resistance-properties between nodes where
owners have preshared identity keys (with nodes I also mean SPV/wallet
nodes).

And I guess there are plenty of awesome identity management system ideas
tied or not tied to the Bitcoin blockchain out there.
This is also a reason to not cover trust/authentication/identity in BIP151.
It is  possible to have multiple authentication schemes.

> In my opinion this question has not received sufficient consideration to warrant proceeding with a network encryption scheme (which concerns me as well, but as I consider it premature I won't comment).

Yes. I think nobody have started implementing BIP151. It's a draft BIP
and I think it's still okay and great that we have this discussion.

BIP151 hopefully has started some brainwork in how encryption and
authentication could work in Bitcoin and I'm happy to deprecate BIP151
if we have found a better solution or if we come to a point where we
agree that BIP151 does make the network security worse.

>> Example: IIRC non of the available SPV wallets can "speak" on of the
>> possible encryption techniques. Encrypting traffic below the application
>> layer is extremely hard to set up for non-experienced users.
> 
> Bloom filters can (and IMO should) be isolated from the P2P protocol. Also, if the proposal creates an insecurity its ease of deployment is moot.

If we assume increasing amount of novice users starting with Bitcoin
every day, how should these users run wallets without increasing
centralization by using webwallets or client/central-server wallets?
(which is OT, but an interesting question)

>> On top of that, encryption allows us to drop the SHA256 checksum per p2p
>> message which should result in a better performance on the network layer
>> once BIP151 is deployed.
> 
> I would not consider this a performance enhancing proposal. Simply dropping the checksum seems like a better option. But again, it is moot if it creates an insecurity.
> 
>> I agree that BIP151 _must_ be deployed together with an authentication
>> scheme (I'm working on that) to protect again MITM during encryption
>> initialization.
> 
> At a minimum I would propose that you modify BIP151 to declare a dependency on a future BIP, making BIP151 incomplete without it. I think we can agree that it would be unadvisable to deploy (and therefore to implement) encryption alone.

I think BIP151 does what it says: encryption and laying groundwork for
authentication.
You wouldn't probably say BIP32 is incomplete because it does not cover
a scheme how to recover funds (or BIP141 [SW consensus] is incomplete
because it does not cover p2p [BIP144]).

The missing MITM protection (solvable over auth) is prominent mentioned
in the BIP [1].


(from your other mail):
>> I don't see reasons why BIP151 could weaken the security of the P2P network. Can you point out some specific concerns?
> 
> TOFU cannot prevent MITM attacks (the goal of the encryption). Authentication requires a secure (trusted) side channel by which to distribute public keys. This presents what I consider a significant problem. If widespread, control over this distribution network would constitute control over who can use Bitcoin.
> The effort to prevent censorship could actually enable it. I don't think it would get that far. Someone would point this out in the process of vetting the authentication BIP, and the result would be the scrapping of BIP151.

I agree that the secure trusted 2nd channel key-sharing problem can be
significant for large networks and/or connecting to unknown identities.

But as said, there could be multiple ways of sharing identity keys.
If you want to connect your node to serval other trusted nodes, you can
simply physically preshare keys or do it over GPG / Signal App, etc..

And if I have followed the news correctly, there are some clever guys
working on various internet of trust 2.0 proposals...

>>
>> BIP151 does not rely on identities. BIP151 does not use persisted keys
>> (only ephemeral keys).
> 
> BIP 151 is incomplete without authentication.

I would agree if you would say, _trusted encryption_ is incomplete with
authentication. But IMO BIP151 is complete and should be deployed
together with one or multiple authentication schemes.


[1] https://github.com/bitcoin/bips/blob/master/bip-0151.mediawiki#risks


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

Re: [bitcoin-dev] BIP 151

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1211 bytes --]

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 PGP users don't properly check keys,
so an attacker won't have a hard time MITM attacking those users. But some
users do check keys, a labor intensive manual process, but not a process that
requires any real cryptographic sophistication, let alone writing any code.
It's very difficult for widescale attackers to distinguish the users who do
check keys from the ones that don't, so if you MITM attack _any_ user you run
the risk of running into one of the few that does check, and those users can
alert everyone else.

The key thing, is we need to get everyones communications encrypted first: if
we don't the MITM attacker can intercept 99% of the communications with 0% risk
of detection, because the non-sophisticated users are trivially distinguishable
from the sophisticated users: just find the users with unencrypted
communications!

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [bitcoin-dev] BIP 151

[Eric Voskuil]

> On Jun 28, 2016, at 10:14 PM, Peter Todd <pete@petertodd.org> 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 gives users the tools to detect a MITM attack.
> 
> It's kinda like PGP in that way: lots of PGP users don't properly check keys,

PGP requires a secure side channel for transmission of public keys. How does one "check" a key of an anonymous peer? I know you well enough to know you wouldn't trust a PGP key received over an insecure channel.

All you can prove is that you are talking to a peer and that communications in the session remain with that peer. The peer can be the attacker. As Jonas has acknowledged, authentication is required to actually guard against MITM attacks.

> so an attacker won't have a hard time MITM attacking those users. But some
> users do check keys, a labor intensive manual process, but not a process that
> requires any real cryptographic sophistication, let alone writing any code.
> It's very difficult for widescale attackers to distinguish the users who do
> check keys from the ones that don't, so if you MITM attack _any_ user you run
> the risk of running into one of the few that does check, and those users can
> alert everyone else.
> 
> The key thing, is we need to get everyones communications encrypted first: if
> we don't the MITM attacker can intercept 99% of the communications with 0% risk
> of detection, because the non-sophisticated users are trivially distinguishable from the sophisticated users: just find the users with unencrypted
> communications!
> 
> -- 
> https://petertodd.org 'peter'[:-1]@petertodd.org

Re: [bitcoin-dev] BIP 151

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1410 bytes --]

On Tue, Jun 28, 2016 at 10:29:54PM +0200, Eric Voskuil wrote:
> 
> 
> > On Jun 28, 2016, at 10:14 PM, Peter Todd <pete@petertodd.org> 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 gives users the tools to detect a MITM attack.
> > 
> > It's kinda like PGP in that way: lots of PGP users don't properly check keys,
> 
> PGP requires a secure side channel for transmission of public keys. How does one "check" a key of an anonymous peer? I know you well enough to know you wouldn't trust a PGP key received over an insecure channel.
> 
> All you can prove is that you are talking to a peer and that communications in the session remain with that peer. The peer can be the attacker. As Jonas has acknowledged, authentication is required to actually guard against MITM attacks.

Easy: anonymous peers aren't always actually anonymous.

A MITM attacker can't easily distinguish communications between two nodes that
randomly picked their peers, and nodes that are connected because their
operators manually used -addnode to peer; in the latter case the operators can
check whether or not they're being attacked with an out-of-band key check.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [bitcoin-dev] BIP 151

[Eric Voskuil]

> On Jun 28, 2016, at 10:36 PM, Peter Todd <pete@petertodd.org> wrote:
> 
>> On Tue, Jun 28, 2016 at 10:29:54PM +0200, Eric Voskuil wrote:
>> 
>> 
>>>> On Jun 28, 2016, at 10:14 PM, Peter Todd <pete@petertodd.org> 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 gives users the tools to detect a MITM attack.
>>> 
>>> It's kinda like PGP in that way: lots of PGP users don't properly check keys,
>> 
>> PGP requires a secure side channel for transmission of public keys. How does one "check" a key of an anonymous peer? I know you well enough to know you wouldn't trust a PGP key received over an insecure channel.
>> 
>> All you can prove is that you are talking to a peer and that communications in the session remain with that peer. The peer can be the attacker. As Jonas has acknowledged, authentication is required to actually guard against MITM attacks.
> 
> Easy: anonymous peers aren't always actually anonymous.
> 
> A MITM attacker can't easily distinguish communications between two nodes that
> randomly picked their peers, and nodes that are connected because their operators manually used -addnode to peer; in the latter case the operators can
> check whether or not they're being attacked with an out-of-band key check.

An "out of band key check" is not part of BIP151. It requires a secure channel and is authentication. So BIP151 doesn't provide the tools to detect an attack, that requires authentication. A general requirement for authentication is the issue I have raised.

e

Re: [bitcoin-dev] BIP 151

[Gregory Maxwell]

On Tue, Jun 28, 2016 at 9:22 PM, Eric Voskuil via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> 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 detect an attack, that requires authentication. A general requirement for authentication is the issue I have raised.

One might wonder how you ever use a Bitcoin address, or even why we
might guess these emails from "you" aren't actually coming from the
NSA.

Re: [bitcoin-dev] BIP 151

[Cameron Garnham]

[-- Attachment #1: Type: text/plain, Size: 1602 bytes --]

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 problems in computer science.

A simple 'who is that' by asking for the fingerprint of your peers from your other peers is a very simple way to get 'some' authentication.  Semi-trusted index nodes also is a low hanging fruit for authentication.

However, let's first get unauthenticated encryption. Force the attackers to use active attacks. (That are thousands times more costly to couduct).

Sent from my iPhone

> On 29 Jun 2016, at 00:36, Gregory Maxwell via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
> On Tue, Jun 28, 2016 at 9:22 PM, Eric Voskuil via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> 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 detect an attack, that requires authentication. A general requirement for authentication is the issue I have raised.
> 
> One might wonder how you ever use a Bitcoin address, or even why we
> might guess these emails from "you" aren't actually coming from the
> NSA.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[-- Attachment #2: Type: text/html, Size: 3000 bytes --]

Re: [bitcoin-dev] BIP 151

[Eric Voskuil]

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

Passing the session ID out of band is authentication. As this is explicitly not part of BIP151 it cannot be that BIP151 provides the tools to detect a attack (the point at issue).

>> It requires a secure channel and is authentication. So BIP151 doesn't provide the tools to detect an attack, that requires authentication. A general requirement for authentication is the issue I have raised.
> 
> One might wonder how you ever use a Bitcoin address, or even why we might guess these emails from "you" aren't actually coming from the NSA.

The sarcasm is counterproductive Greg. By the same token I could ask how you ever use Bitcoin given that the P2P protocol is not encrypted or authenticated.

It doesn't matter who I am, maybe I am the NSA. I don't argue from a position of authority. Signing my emails while traveling on holiday with only my phone gets a little tedious.

The blockchain and mempool are a cache of public data. Transmission of a payment address to a payer is not a comparable scenario.

The possibility that authentication may become required to participate in this trustless network is a legitimate concern, and one that has not been addressed.

e

Re: [bitcoin-dev] BIP 151

[Eric Voskuil]

[-- Attachment #1: Type: text/plain, Size: 2197 bytes --]

Hi Cameron, good to hear from you!

> On Jun 28, 2016, at 11:40 PM, Cameron Garnham <da2ce7@gmail.com> 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 not require that the attacker find a way to inject traffic into the communication between nodes. Peers will connect to the attacker directly, or accept connections directly from it. Such attacks can be easier than even passive attacks.

> 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 problems in computer science.
> 
> A simple 'who is that' by asking for the fingerprint of your peers from your other peers is a very simple way to get 'some' authentication.  Semi-trusted index nodes also is a low hanging fruit for authentication.

It is the implication of widespread authentication that is at issue. Clearly there are ways to implement it using a secure side channels.

> However, let's first get unauthenticated encryption. Force the attackers to use active attacks. (That are thousands times more costly to couduct).
> 
> Sent from my iPhone
> 
>> On 29 Jun 2016, at 00:36, Gregory Maxwell via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> 
>> On Tue, Jun 28, 2016 at 9:22 PM, Eric Voskuil via bitcoin-dev
>> <bitcoin-dev@lists.linuxfoundation.org> 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 detect an attack, that requires authentication. A general requirement for authentication is the issue I have raised.
>> 
>> One might wonder how you ever use a Bitcoin address, or even why we
>> might guess these emails from "you" aren't actually coming from the
>> NSA.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[-- Attachment #2: Type: text/html, Size: 3951 bytes --]

Re: [bitcoin-dev] BIP 151

[Cameron Garnham]

[-- Attachment #1: Type: text/plain, Size: 3235 bytes --]


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

You described the 'evil node' attack; that indeed needs an identity system to stop. However BIP151 doesn't intend to protect against connecting to evil Bitcoin Nodes.

It is important not to mixup link-level authentication and node-level authentication.

When your client picks random nodes to connect to, you are not considered whom in particular runs them. (Rather that you have a good random sample of the network).

If you manually add a friends node; at this point you wish to have node-level authentication.  However, this may (and probably should) happen out-of-band.


Sent from my iPhone

> On 29 Jun 2016, at 01:07, Eric Voskuil <eric@voskuil.org> wrote:
> 
> Hi Cameron, good to hear from you!
> 
>> On Jun 28, 2016, at 11:40 PM, Cameron Garnham <da2ce7@gmail.com> 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 not require that the attacker find a way to inject traffic into the communication between nodes. Peers will connect to the attacker directly, or accept connections directly from it. Such attacks can be easier than even passive attacks.
> 
>> 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 problems in computer science.
>> 
>> A simple 'who is that' by asking for the fingerprint of your peers from your other peers is a very simple way to get 'some' authentication.  Semi-trusted index nodes also is a low hanging fruit for authentication.
> 
> It is the implication of widespread authentication that is at issue. Clearly there are ways to implement it using a secure side channels.
> 
>> However, let's first get unauthenticated encryption. Force the attackers to use active attacks. (That are thousands times more costly to couduct).
>> 
>> Sent from my iPhone
>> 
>>> On 29 Jun 2016, at 00:36, Gregory Maxwell via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>> 
>>> On Tue, Jun 28, 2016 at 9:22 PM, Eric Voskuil via bitcoin-dev
>>> <bitcoin-dev@lists.linuxfoundation.org> 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 detect an attack, that requires authentication. A general requirement for authentication is the issue I have raised.
>>> 
>>> One might wonder how you ever use a Bitcoin address, or even why we
>>> might guess these emails from "you" aren't actually coming from the
>>> NSA.
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[-- Attachment #2: Type: text/html, Size: 5799 bytes --]

Re: [bitcoin-dev] BIP 151

[Eric Voskuil]

[-- Attachment #1: Type: text/plain, Size: 3678 bytes --]

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, at 12:33 AM, Cameron Garnham <da2ce7@gmail.com> wrote:
> 
> 
> 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 authentication.
> 
> You described the 'evil node' attack; that indeed needs an identity system to stop. However BIP151 doesn't intend to protect against connecting to evil Bitcoin Nodes.
> 
> It is important not to mixup link-level authentication and node-level authentication.
> 
> When your client picks random nodes to connect to, you are not considered whom in particular runs them. (Rather that you have a good random sample of the network).
> 
> If you manually add a friends node; at this point you wish to have node-level authentication.  However, this may (and probably should) happen out-of-band.
> 
> 
> Sent from my iPhone
> 
>> On 29 Jun 2016, at 01:07, Eric Voskuil <eric@voskuil.org> wrote:
>> 
>> Hi Cameron, good to hear from you!
>> 
>>> On Jun 28, 2016, at 11:40 PM, Cameron Garnham <da2ce7@gmail.com> 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 not require that the attacker find a way to inject traffic into the communication between nodes. Peers will connect to the attacker directly, or accept connections directly from it. Such attacks can be easier than even passive attacks.
>> 
>>> 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 problems in computer science.
>>> 
>>> A simple 'who is that' by asking for the fingerprint of your peers from your other peers is a very simple way to get 'some' authentication.  Semi-trusted index nodes also is a low hanging fruit for authentication.
>> 
>> It is the implication of widespread authentication that is at issue. Clearly there are ways to implement it using a secure side channels.
>> 
>>> However, let's first get unauthenticated encryption. Force the attackers to use active attacks. (That are thousands times more costly to couduct).
>>> 
>>> Sent from my iPhone
>>> 
>>>> On 29 Jun 2016, at 00:36, Gregory Maxwell via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>> 
>>>> On Tue, Jun 28, 2016 at 9:22 PM, Eric Voskuil via bitcoin-dev
>>>> <bitcoin-dev@lists.linuxfoundation.org> 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 detect an attack, that requires authentication. A general requirement for authentication is the issue I have raised.
>>>> 
>>>> One might wonder how you ever use a Bitcoin address, or even why we
>>>> might guess these emails from "you" aren't actually coming from the
>>>> NSA.
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev@lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[-- Attachment #2: Type: text/html, Size: 6373 bytes --]

Re: [bitcoin-dev] BIP 151

[Eric Voskuil]

On Jun 28, 2016, at 10:06 PM, Jonas Schnelli <dev@jonasschnelli.ch> 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 trust).
> 
> Are users aware of the fact that ISP/WiFi-Providers can track their
> bitcoin spending (if they use SPV+BF) and link it with other internet
> traffic or sell the data to anyone who is interested to do correlation?

The relevant question would be to ask whether encryption would prevent an ISP from doing so (which it would not). This is a good example of false sense of security.

> Are node operators aware of the possibilities that ISPs/Data-Centers,
> etc. can hold back peers, etc.?
> 
> If there is a false sense of security/anonymity, then we are already
> deep into this territory.
> BIP151 was designed as a puzzle-pice towards better security and better
> censorship resistance. You shouldn't project all sorts of "false sense
> of security" into BIP151. Is a stepping stone towards greater security.

FWIW I was just answering your question comprehensively. Relationship to BIP151 is incidental (though apparently applicable).

Keep in mind my specific concern is not with the design of BIP151, it is with the implication of its dependency on an unspecified authentication proposal.

>> 2) as a tradeoff against anonymity
> 
> Can you point out the tradeoffs?
> BIP151 does not introduce fingerprinting possibilities.

The security tradeoff would arise from widespread deployment of authentication - which is necessary to make encryption useful against envisioned MITM attacks. See my previous discussion of trust zones below.

>> 3) benefit does not justify cost
> 
> Can you elaborate the costs?
> [Extremely simplified]: we need 300 lines of code from openssh
> (ChaCha20-Poly1305@openssl) and some ECDH magic (already in
> Bitcoin-Cores codebase) together with two or three (maybe payed)
> cryptoanalysis once the implementation is done.

Simply put, any code that is unnecessary does not justify its cost.

>>> There are plenty of other options to solve this problem. stunnel,
>>> Bernsteins CurveCP, VPN, etc. which are available since years.
>>> But the reality has shown that most bitcoin traffic is still unencrypted.
>> 
>> The question arises from concern over the security of the network in the case where encryption (and therefore authentication) is pervasive.
>> 
>> As you point out, anyone can set up a private network of nodes today. These nodes must also connect to the permissionless network to maintain the chain. These nodes constitute a trust zone within Bitcoin. This zone of exclusion operates as a single logical node from the perspective of the Bitcoin security model (one entity controls the validation rules for all nodes).
>> 
>> Widespread application of this model is potentially problematic. It is a non-trivial problem to design a distributed system that requires authentication but without identity and without central control. In fact this may be more challenging than Bitcoin itself. Trust on first use (TOFU) does not solve this problem.
> 
> Yes. There is no plan to adopt a TUFO scheme. Bip151 does not use TUFO
> it does not cover "trust" (It just encrypt all traffic).

TOFU (trust on first use) was a reference to what was discussed on IRC as a potential solution to the (deferred) authentication problem. I didn't mean to imply that it was part of BIP151.

> Imaging Bip151 together with a simple form of preshared EC key
> authentication (nonce signing or similar). You could drastically
> increase the security/censor-resistance-properties between nodes where
> owners have preshared identity keys (with nodes I also mean SPV/wallet
> nodes).

This is a restatement of what I have accepted as a premise - that authentication, and as such, key distribution, will be a necessary part of making any encryption scheme effective. "Preshared" implies a secure side channel for key distribution.

> And I guess there are plenty of awesome identity management system ideas
> tied or not tied to the Bitcoin blockchain out there.
> This is also a reason to not cover trust/authentication/identity in BIP151.
> It is  possible to have multiple authentication schemes.

Whether or not there are multiple schemes is not relevant to the point I have raised. The issue is that authentication is necessary.

>> In my opinion this question has not received sufficient consideration to warrant proceeding with a network encryption scheme (which concerns me as well, but as I consider it premature I won't comment).
> 
> Yes. I think nobody have started implementing BIP151. It's a draft BIP
> and I think it's still okay and great that we have this discussion.
> 
> BIP151 hopefully has started some brainwork in how encryption and
> authentication could work in Bitcoin and I'm happy to deprecate BIP151 if we have found a better solution or if we come to a point where we agree that BIP151 does make the network security worse.

We should contemplate what the distributed permissionless network of anonymous peers looks like once every node authenticates every one of its peers using one or more key distribution side channels.

>>> Example: IIRC non of the available SPV wallets can "speak" on of the
>>> possible encryption techniques. Encrypting traffic below the application
>>> layer is extremely hard to set up for non-experienced users.
>> 
>> Bloom filters can (and IMO should) be isolated from the P2P protocol. Also, if the proposal creates an insecurity its ease of deployment is moot.
> 
> If we assume increasing amount of novice users starting with Bitcoin every day, how should these users run wallets without increasing centralization by using webwallets or client/central-server wallets?
> (which is OT, but an interesting question)

I fully appreciate the significant security risk arising from the proliferation of web wallets. This can only be resolved by people validating using code under their own control.

Encryption/authentication are orthogonal to this question, assuming people have wallets directly attached to full nodes. Remoting a wallet from a full node does not require use of the P2P protocol, and can use encryption/authentication without the concerns I've raised. It properly places the trust boundary around a wallet and its trusted node(s), as opposed to spanning (independent) nodes.

>>> On top of that, encryption allows us to drop the SHA256 checksum per p2p
>>> message which should result in a better performance on the network layer
>>> once BIP151 is deployed.
>> 
>> I would not consider this a performance enhancing proposal. Simply dropping the checksum seems like a better option. But again, it is moot if it creates an insecurity.
>> 
>>> I agree that BIP151 _must_ be deployed together with an authentication
>>> scheme (I'm working on that) to protect again MITM during encryption
>>> initialization.
>> 
>> At a minimum I would propose that you modify BIP151 to declare a dependency on a future BIP, making BIP151 incomplete without it. I think we can agree that it would be unadvisable to deploy (and therefore to implement) encryption alone.
> 
> I think BIP151 does what it says: encryption and laying groundwork for authentication.
> You wouldn't probably say BIP32 is incomplete because it does not cover
> a scheme how to recover funds (or BIP141 [SW consensus] is incomplete
> because it does not cover p2p [BIP144]).

This is an unfair statement. You have acknowledged that BIP151 requires authentication to accomplish its sole objective.

> The missing MITM protection (solvable over auth) is prominent mentioned in the BIP [1].

As I pointed out.

> (from your other mail):
>>> I don't see reasons why BIP151 could weaken the security of the P2P network. Can you point out some specific concerns?
>> 
>> TOFU cannot prevent MITM attacks (the goal of the encryption). Authentication requires a secure (trusted) side channel by which to distribute public keys. This presents what I consider a significant problem. If widespread, control over this distribution network would constitute control over who can use Bitcoin.
>> The effort to prevent censorship could actually enable it. I don't think it would get that far. Someone would point this out in the process of vetting the authentication BIP, and the result would be the scrapping of BIP151.
> 
> I agree that the secure trusted 2nd channel key-sharing problem can be significant for large networks and/or connecting to unknown identities.
> 
> But as said, there could be multiple ways of sharing identity keys.
> If you want to connect your node to serval other trusted nodes, you can simply physically preshare keys or do it over GPG / Signal App, etc..

Again, it's the fact that authentication is required that produces the issue, not that there are multiple ways to implement it.

> And if I have followed the news correctly, there are some clever guys
> working on various internet of trust 2.0 proposals...

I don't see how this is relevant.

>>> BIP151 does not rely on identities. BIP151 does not use persisted keys
>>> (only ephemeral keys).
>> 
>> BIP 151 is incomplete without authentication.
> 
> I would agree if you would say, _trusted encryption_ is incomplete with
> authentication. But IMO BIP151 is complete and should be deployed together with one or multiple authentication schemes.

It seems that we are talking past each other. You haven't yet addressed the issue that I have raised.

It is the requirement for authentication of any node that any other node may wish to connect to that is the issue. We end up with something that looks like WoT or PKI. And if not fully controlled by PKI (so using WoT) we will have hybrid nodes that accept untrusted connections and propagate information between trusted and untrusted nodes.

> [1] https://github.com/bitcoin/bips/blob/master/bip-0151.mediawiki#risks
> 

Re: [bitcoin-dev] BIP 151

[Eric Voskuil]

On Jun 28, 2016, at 9:55 PM, Gregory Maxwell via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> 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 single narrow usecase which isn't proposed by the BIP and then argue it is worthless. I agree that example doesn't have much value (and I believe that
> eventually the BIP37 bloom filters should be removed from the protocol).

I don't follow this comment. The BIP aims quite clearly at "SPV" wallets as its justifying scenario.

> Without something like BIP151 network participants cannot have privacy for the transactions they originate within the protocol against network observers.

And they won't get it with BIP151 either. Being a peer is easier than observing the network. If one can observe the encrypted traffic one can certainly use a timing attack to determine what the node has sent.

> Even if, through some extraordinary effort, their own first hop is encrypted, unencrypted later hops would rapidly
> expose significant information about transaction origins in the network.

As will remain the case until all connections are encrypted and authenticated, and all participants are known to be good guys. Starting to sound like PKI?

> Without something like BIP151 authenticated links are not possible, so
> manually curated links (addnode/connect) cannot be counted on to provide protection against partitioning sybils.

If we trust the manual links we don't need/want the other links. In fact retaining the other links enables the attack you described above. Of course there is no need to worry about Sybil attacks when all of your peers are authenticated. But again, let us not ignore the problems of requiring all peers on the network be authenticated.

> Along the way BIP151 appears that it will actually make the protocol faster.
> 
>> Given that the BIP relies on identity
> 
> This is untrue. The proposal is an ephemerally keyed opportunistic
> encryption system. The privacy against a network observer does not depend on authentication, much less "identity".  And when used with authentication at all it makes interception strongly detectable after the fact.

Maybe I was insufficiently explicit. By "relies on identity" I meant that the BIP is not effective without it. I did not mean to imply that the BIP itself implements an identity scheme. I thought this was clear from the context.

>> The BIP does not [...] contemplate the significant problems associated with key distribution in any identity system
> 
> Because it does not propose any "identity system" or authorization (also, I object to your apparent characterization of authentication as as an 'identity system'-- do you also call Bitcoin addresses an identity system?).

Please read more carefully what I wrote. I did not characterize authentication as an identity system. I proposed that key distribution has significant problems, and used identity systems as an example of systems with such problems. I could just have easily written "authentication systems", (and probably should have).

> That said, manually maintaining adds nodes to your own and somewhat trusted nodes is a recommend best practice for miners and other high value systems which is rendered much less effective due to a lack of
> authentication, there is no significant key distribution problem in that case

This is the only legitimate scenario that I am aware of. Doing this by IP address (as we do) is weak if there is no VPN.

Yet this scenario is very different than general authentication. This scenario is a set of nodes that is essentially a single logical node from the perspective of the Bitcoin security model. One entity controls the validation rules, or is collaborating with another entity to do so.

My concern is that a general authentication requirement expands this single logical node and gives control over if to the entity that controls key distribution - the hard problem that hasn't been addressed.

If there is no such entity restricting access to the network (which hopefully we can assume) then there is no reason to expect any effective improvement, since nodes will necessarily have to connect with anonymous peers. Anyone with a node and the ability to monitor traffic should remain very effective.

> and I expect the future auth BIP (Jonas had one before, but it was put aside for now to first focus on the link layer encryption)
> to address that case quite well.

Defining an auth implementation is not a hard problem, nor is it the concern I have raised.

e

Re: [bitcoin-dev] BIP 151

[Eric Voskuil]

>> On Jun 29, 2016, at 12:22 AM, Gregory Maxwell <gmaxwell@gmail.com> wrote:
>> 
>> On Tue, Jun 28, 2016 at 9:59 PM, Eric Voskuil <eric@voskuil.org> 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 tools to detect a attack (the point at issue).
> 
> It provides the ID, the rest is meat.

The rest is "authentication".

> Users can compare session IDs
> via whatever communications channels they already use after the fact
> and discover if they were or are being MITMed.
> 
>>>> It requires a secure channel and is authentication. So BIP151 doesn't provide the tools to detect an attack, that requires authentication. A general requirement for authentication is the issue I have raised.
>>> 
>>> One might wonder how you ever use a Bitcoin address, or even why we might guess these emails from "you" aren't actually coming from the NSA.
>> 
>> The sarcasm is counterproductive Greg. By the same token I could ask how you ever use Bitcoin given that the P2P protocol is not encrypted or authenticated.
> 
> I think I was unclear. A bitcoin address needs to be sent over a secure channel, which we do not provide. Yet sending funds to addresses instead of anyone_can_spend is pretty useful.
> 
> Similarly, I can guess that messages claiming to you are probably from you when many people can independently check, even if they don't usually. The fact tampered messages might be detected is a big disincentive from trying.

You were perfectly clear. Did I give some indication that I did not understand what you meant?

>> The blockchain and mempool are a cache of public data. Transmission of a payment address to a payer is not a comparable scenario.
> 
> The precise timing and ordering of transactions being relayed is _not_
> public data.

Posting txs to the network is a client-server scenario. The set of txs arriving at an arbitrary node, including the order of arrival, is by definition public information. The only possible way it could be considered private is if the entire network was private.

So where does the private timing become public? First hop, second, third?

Encryption and authentication cannot prevent timing attacks against a person posting txs to the network unless the entire network is "secured". That is not possible without centralized access control.

Encrypting the P2P network doesn't resolve this problem, nor does authentication, nor does Tor. I would prefer we advance an actual solution to this significant problem than advance a false sense of security while creating both complexity and the likely evolution of node identity.

e

Re: [bitcoin-dev] BIP 151

[Nick ODell]

>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 nodes' is a
subjective quality that is hard to assess automatically.

>and if you intend to connect to potentially evil nodes you aren't securing anything

Bitcoin is designed with the assumption that some of the nodes you
connect to might be evil. Sure, if 100% of the nodes you're connected
to are evil, you're screwed. However, we shouldn't avoid protecting
people from someone on the same coffee-shop network, just because the
same mitigation won't work against a nation-state.

On Tue, Jun 28, 2016 at 5:29 PM, Eric Voskuil via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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, at 12:33 AM, Cameron Garnham <da2ce7@gmail.com> wrote:
>
>
> 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 authentication.
>
> You described the 'evil node' attack; that indeed needs an identity system
> to stop. However BIP151 doesn't intend to protect against connecting to evil
> Bitcoin Nodes.
>
> It is important not to mixup link-level authentication and node-level
> authentication.
>
> When your client picks random nodes to connect to, you are not considered
> whom in particular runs them. (Rather that you have a good random sample of
> the network).
>
> If you manually add a friends node; at this point you wish to have
> node-level authentication.  However, this may (and probably should) happen
> out-of-band.
>
>
> Sent from my iPhone
>
> On 29 Jun 2016, at 01:07, Eric Voskuil <eric@voskuil.org> wrote:
>
> Hi Cameron, good to hear from you!
>
> On Jun 28, 2016, at 11:40 PM, Cameron Garnham <da2ce7@gmail.com> 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 not require
> that the attacker find a way to inject traffic into the communication
> between nodes. Peers will connect to the attacker directly, or accept
> connections directly from it. Such attacks can be easier than even passive
> attacks.
>
> 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 problems in computer science.
>
> A simple 'who is that' by asking for the fingerprint of your peers from your
> other peers is a very simple way to get 'some' authentication.  Semi-trusted
> index nodes also is a low hanging fruit for authentication.
>
>
> It is the implication of widespread authentication that is at issue. Clearly
> there are ways to implement it using a secure side channels.
>
> However, let's first get unauthenticated encryption. Force the attackers to
> use active attacks. (That are thousands times more costly to couduct).
>
> Sent from my iPhone
>
> On 29 Jun 2016, at 00:36, Gregory Maxwell via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> On Tue, Jun 28, 2016 at 9:22 PM, Eric Voskuil via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> 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 detect an attack, that requires authentication. A
> general requirement for authentication is the issue I have raised.
>
>
> One might wonder how you ever use a Bitcoin address, or even why we
> might guess these emails from "you" aren't actually coming from the
> NSA.
> _______________________________________________
> 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
>

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

[Rusty Russell]

Jonas Schnelli <dev@jonasschnelli.ch> 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 SHA512 to the mix.  Can we just
>> make:
>> 
>> K_1 = HMAC_SHA256(key=ecdh_secret|cipher-type,msg="header encryption key")
>> K_2 = HMAC_SHA256(key=ecdh_secret|cipher-type,msg="body encryption key")
>
> SHA512_HMAC is used by BIP32 [1] and I guess most clients will somehow
> make use of bip32 features. I though a single SHA512_HMAC operation is
> cheaper and simpler then two SHA256_HMAC.

Good point; I would argue that mistake has already been made.  But I was
looking at appropriating your work for lightning inter-node comms, and
adding another hash algo seemed unnecessarily painful.

> AFAIK, sha256_hmac is also not used by the current p2p & consensus layer.
> Bitcoin-Core uses it for HTTP RPC auth and Tor control.

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

Thanks!
Rusty.

Re: [bitcoin-dev] BIP 151

[Gregory Maxwell]

On Tue, Jun 28, 2016 at 11:33 PM, Eric Voskuil <eric@voskuil.org> 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

>> Without something like BIP151 network participants cannot have privacy for the transactions they originate within the protocol against network observers.
>
> And they won't get it with BIP151 either. Being a peer is easier than observing the network.

Not passively, undetectable, and against thousands of users at once at low cost.

> If one can observe the encrypted traffic one can certainly use a timing attack to determine what the node has sent.

Not against Bitcoin Core, transactions are batched and relayed in
sorted order.  (obviously there are limits at what this provides;
ironically, the lack of link encryption has been used to argue against
privacy preserving relay behavior)

>> Even if, through some extraordinary effort, their own first hop is encrypted, unencrypted later hops would rapidly
>> expose significant information about transaction origins in the network.
>
> As will remain the case until all connections are encrypted and authenticated, and all participants are known to be good guys. Starting to sound like PKI?

Huh? The first and subsequent hops obscures the origin and timing.

>> Without something like BIP151 authenticated links are not possible, so
>> manually curated links (addnode/connect) cannot be counted on to provide protection against partitioning sybils.
>
> If we trust the manual links we don't need/want the other links. In fact retaining the other links enables the attack you described above. Of course there is no need to worry about Sybil attacks when all of your peers are authenticated. But again, let us not ignore the problems of requiring all peers on the network be authenticated.

Don't need and want them for what?  For _partitioning_ resistance,
you are not partitioned if you have one honest connection to the
functional network. Additional peers purely reduce your partition
vulnerability-- so long as an active network attacker isn't
itercepting all your connections out.

For privacy, you have improve transaction privacy so long as your
transaction isn't initially relayed to a malicious peer-- but
malicious peers can lie further out because transit nodes obscure the
order of message creation.  Bitcoin Core currently relays transactions
first and more frequently to outbound and whitelisted peers.

> Maybe I was insufficiently explicit. By "relies on identity" I meant that the BIP is not effective without it. I did not mean to imply that the BIP itself implements an identity scheme. I thought this was clear from the context.

I understood that, but my point was that Bitcoin cannot be used at
all_unless users have secure communication channels to share
addresses.

> then there is no reason to expect any effective improvement, since nodes will necessarily have to connect with anonymous peers.

They're not required to _only_ connect with anonymous peers. And
partition resistance requires that you have any one good link.

> Anyone with a node and the ability to monitor traffic should remain very effective.

Not via passive observation.

> Defining an auth implementation is not a hard problem, nor is it the concern I have raised.

Glad you agree.

We seem to be looping now. Feel free to not implement this proposal,
no one suggests making it mandatory.

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

[Arthur Chen]

[-- Attachment #1: Type: text/plain, Size: 1946 bytes --]

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 Authentication
Code) rather than custom construction

On Wed, Jun 29, 2016 at 9:00 AM, Rusty Russell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Jonas Schnelli <dev@jonasschnelli.ch> 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 SHA512 to the mix.  Can we just
> >> make:
> >>
> >> K_1 = HMAC_SHA256(key=ecdh_secret|cipher-type,msg="header encryption
> key")
> >> K_2 = HMAC_SHA256(key=ecdh_secret|cipher-type,msg="body encryption key")
> >
> > SHA512_HMAC is used by BIP32 [1] and I guess most clients will somehow
> > make use of bip32 features. I though a single SHA512_HMAC operation is
> > cheaper and simpler then two SHA256_HMAC.
>
> Good point; I would argue that mistake has already been made.  But I was
> looking at appropriating your work for lightning inter-node comms, and
> adding another hash algo seemed unnecessarily painful.
>
> > AFAIK, sha256_hmac is also not used by the current p2p & consensus layer.
> > Bitcoin-Core uses it for HTTP RPC auth and Tor control.
>
> 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...
>
> Thanks!
> Rusty.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>



-- 
Xuesong (Arthur) Chen
Senior Principle Engineer
BlockChain Technologist
BTCC

[-- Attachment #2: Type: text/html, Size: 3001 bytes --]

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

[Ethan Heilman]

>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 without
knowing key or msg compute a value y' such that
y' = SHA256(key|cipher-type|mesg|any values I want).

Thus, an attacker can trivially forge a tag protected by
SHA256(key|cipher-type|mesg).

For more details see:
https://web.archive.org/web/20141029080820/http://vudang.com/2012/03/md5-length-extension-attack/

On Tue, Jun 28, 2016 at 9:00 PM, Rusty Russell via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Jonas Schnelli <dev@jonasschnelli.ch> 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 SHA512 to the mix.  Can we just
>>> make:
>>>
>>> K_1 = HMAC_SHA256(key=ecdh_secret|cipher-type,msg="header encryption key")
>>> K_2 = HMAC_SHA256(key=ecdh_secret|cipher-type,msg="body encryption key")
>>
>> SHA512_HMAC is used by BIP32 [1] and I guess most clients will somehow
>> make use of bip32 features. I though a single SHA512_HMAC operation is
>> cheaper and simpler then two SHA256_HMAC.
>
> Good point; I would argue that mistake has already been made.  But I was
> looking at appropriating your work for lightning inter-node comms, and
> adding another hash algo seemed unnecessarily painful.
>
>> AFAIK, sha256_hmac is also not used by the current p2p & consensus layer.
>> Bitcoin-Core uses it for HTTP RPC auth and Tor control.
>
> 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...
>
> Thanks!
> Rusty.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Pieter Wuille]

[-- Attachment #1: Type: text/plain, Size: 829 bytes --]

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 because of
> the length extension property of SHA256.

This property does technically not apply here, as the output of the hash is
kept secret, and the possible messages are constants (which are presumably
chosen in such a way that one is never an extension of another).

However, this is a good example of why you can't generically use a hash
function in places where you want a MAC (aka "a hash with a shared
secret"). Furthermore, if you already have a hash function anyway, HMAC is
very easy construct on top of it.

-- 
Pieter

[-- Attachment #2: Type: text/html, Size: 1049 bytes --]

Re: [bitcoin-dev] BIP 151

[Alfie John]

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 design a distributed system that requires authentication
> but without identity and without central control. In fact this may be more
> challenging than Bitcoin itself. Trust on first use (TOFU) does not solve this
> problem.

Maybe the following paper can feed into this discussion:

  "Decentralized Anonymous Credentials" by Christina Garman, Matthew Green, Ian Miers
	https://eprint.iacr.org/2013/622.pdf

Alfie

-- 
Alfie John
https://www.alfie.wtf

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

[Ethan Heilman]

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 <pieter.wuille@gmail.com> wrote:
> 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 because of
>> the length extension property of SHA256.
>
> This property does technically not apply here, as the output of the hash is
> kept secret, and the possible messages are constants (which are presumably
> chosen in such a way that one is never an extension of another).
>
> However, this is a good example of why you can't generically use a hash
> function in places where you want a MAC (aka "a hash with a shared secret").
> Furthermore, if you already have a hash function anyway, HMAC is very easy
> construct on top of it.
>
> --
> Pieter

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

[Jonas Schnelli]

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

> 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" keys from the ECDH shared secret.
HMAC_SHA256 would be sufficient but I have specified SHA512 to allow to
directly derive 512bits which allows to have two 256bit keys with one
HMAC operation (same pattern is used in BIP for the key/chaincode
derivation).

Keccak would be an alternative but we probably don't want to introduce
another new hash type just for the encryption.

</jonas>


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

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

[Jonas Schnelli]

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

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,
although, BIP151 only specifies chacha20-poly1305@openssh.com.

Lets assume someone adds another symmetric cipher type after BIP151 has
been deployed which has less strong security properties then
chacha20-poly1305.

If we don't include the ciphersuite-type in the key derivation HMAC, an
attacker/MITM could in theory force both nodes to use the weaker
symmetric cipher type.

</jonas>


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

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

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1015 bytes --]

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 mainly depends
> on the PRNG and the ECDH scheme.
> 
> The HMAC_SHA512 will be used to "drive" keys from the ECDH shared secret.
> HMAC_SHA256 would be sufficient but I have specified SHA512 to allow to
> directly derive 512bits which allows to have two 256bit keys with one
> HMAC operation (same pattern is used in BIP for the key/chaincode
> derivation).

What's the rational for doing that "directly" rather than with two SHA256
operations? (specifcially SHA256(0 . thing), SHA256(1 + thing) for the two
parts we need to derive)

Reducing the # of basic cryptographic primitives you need to implement a
standard needs is a good thing.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

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

[Jonas Schnelli]

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

> 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 mainly depends
>> on the PRNG and the ECDH scheme.
>>
>> The HMAC_SHA512 will be used to "drive" keys from the ECDH shared secret.
>> HMAC_SHA256 would be sufficient but I have specified SHA512 to allow to
>> directly derive 512bits which allows to have two 256bit keys with one
>> HMAC operation (same pattern is used in BIP for the key/chaincode
>> derivation).
> 
> What's the rational for doing that "directly" rather than with two SHA256
> operations? (specifcially SHA256(0 . thing), SHA256(1 + thing) for the two
> parts we need to derive)

SHA256 and SHA512 are both from the SHA-2 family.

I have specified SHA512 to (slightly) increase the brute-force security
of the ecdh shared secret when knowing K_1 and K_2.

And I assumed (haven't measured the required cpu cycles) that a single
SHA512_HMAC is less expensive then two SHA256_HMAC.

</jonas>


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

Re: [bitcoin-dev] BIP 151

[Eric Voskuil]

On Jun 29, 2016, at 3:01 AM, Gregory Maxwell <greg@xiph.org> wrote:
> 
>> On Tue, Jun 28, 2016 at 11:33 PM, Eric Voskuil <eric@voskuil.org> 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

"MOTIVATION:
The Bitcoin network does not encrypt communication between peers today. This opens up security issues (eg: traffic manipulation by others) and allows for mass surveillance / analysis of bitcoin users. Mostly this is negligible because of the nature of Bitcoins trust model, however for SPV nodes this can have significant privacy impacts [1] and could reduce the censorship-resistance of a peer."

This is not an example, this is the exception that is described as "significant" in comparison to the other issues, which are described as "negligible".

The Bloom filters messages are of course the unique aspects of the protocol as it pertains to "SPV".

The RISKS section declares that the BIP cannot prevent MITM attacks and that "identity authentication" will  be defined in a forthcoming BIP.

The obvious implication (accepted by the author) is that authentication is required to prevent a MITM attack, and furthermore establishment of identity will be required to ensure that the authenticated party is not a bad actor.

>>> Without something like BIP151 network participants cannot have privacy for the transactions they originate within the protocol against network observers.
>> 
>> And they won't get it with BIP151 either. Being a peer is easier than observing the network.
> 
> Not passively, undetectable, and against thousands of users at once at low cost.

This is a straw man, as the BIP does not state that its objective is to moderately raise the cost of passive attack against large numbers of users.

It is also a red herring, as passivity is not itself a benefit. It implies that the attack is easier and therefore less costly. But a trivial active attack may be a larger security problem than a complex passive attack. Attacks against privacy under this BIP (and with authentication) can be carried out by passively monitoring traffic and operating one or more nodes. Operating a node may be considered "active" because the node communicates, but technically it is not. In either case the activeness itself hardly raises the difficulty, especially for a global (thousands of users) passive attacker.

Depending on the attacker, cost may not be an issue at all, so raising it can have zero effect. Certainly we are not talking about prohibitive (cryptographically hard) cost. Raising the cost *any* amount is not likely a reasonable cost-benefit tradeoff.

Privacy attacks would remain entirely undetectable under this proposal, and under any additional proposal that required authentication in the absence of identity. Only with all users of the network identified as "good" would such proposals be effective. Until that point any bad actors can become an integral part of the network. I will investigate the question of identity in a follow-up to an independent post.

>> If one can observe the encrypted traffic one can certainly use a timing attack to determine what the node has sent.
> 
> Not against Bitcoin Core, transactions are batched and relayed in
> sorted order.  (obviously there are limits at what this provides;
> ironically, the lack of link encryption has been used to argue against
> privacy preserving relay behavior)

It cannot be both impossible ("not against Bitcoin Core") and limited in effectiveness ("obviously there are limits").

We should be clear at this point that the transaction-posting security provided against a privacy attack, based on the assumption of "good" (identified) peers in the first few hops, derives entirely from the ability of the good peers to break the timing attack, which is itself "limited".

This is a compound pair of weak assumptions, that to be made stronger will require widespread use of identity (not just authentication).

The proliferation of node identity is my primary concern - this relates to privacy and the security of the network. Secondarily I am concerned about users operating under a false assumption about the strength of privacy. Thirdly I am concerned about the risk of vulnerability introduced by the integration into the P2P network layer of an totally new network security scheme. Fourthly I'm concerned about the cost of the above based on the belief that the benefit may not be material and that it may lead to increased centralization.

>>> Even if, through some extraordinary effort, their own first hop is encrypted, unencrypted later hops would rapidly
>>> expose significant information about transaction origins in the network.
>> 
>> As will remain the case until all connections are encrypted and authenticated, and all participants are known to be good guys. Starting to sound like PKI?
> 
> Huh? The first and subsequent hops obscures the origin and timing.

Described as "limited" in effectiveness, and clearly useful only if these hops are not attacker nodes.

So back to my comment on how we maintain a pool of "good" nodes for people to connect to, and raising the question of how effective is this strategy (which is itself unspecified and so cannot be assumed to even exist in the context of the BIP).

>>> Without something like BIP151 authenticated links are not possible, so
>>> manually curated links (addnode/connect) cannot be counted on to provide protection against partitioning sybils.
>> 
>> If we trust the manual links we don't need/want the other links. In fact retaining the other links enables the attack you described above. Of course there is no need to worry about Sybil attacks when all of your peers are authenticated. But again, let us not ignore the problems of requiring all peers on the network be authenticated.
> 
> Don't need and want them for what?  For _partitioning_ resistance,
> you are not partitioned if you have one honest connection to the
> functional network. Additional peers purely reduce your partition vulnerability-- so long as an active network attacker isn't
> intercepting all your connections out.

Don't want them as peers for the purpose of tx relay. As I said this, "enables the attack you described above."

> For privacy, you have improve transaction privacy so long as your
> transaction isn't initially relayed to a malicious peer-- but
> malicious peers can lie further out because transit nodes obscure the
> order of message creation.  Bitcoin Core currently relays transactions
> first and more frequently to outbound and whitelisted peers.

This whitelisting is simply a stand-in for a more formal identity system. One doesn't whitelist anonymous peers, one whitelists peers controlled by trusted parties. Preferring trusted peers is another aspect of trying to break the timing attack. So I would lump this under the same analysis as above (batching).

>> Maybe I was insufficiently explicit. By "relies on identity" I meant that the BIP is not effective without it. I did not mean to imply that the BIP itself implements an identity scheme. I thought this was clear from the context.
> 
> I understood that, but my point was that Bitcoin cannot be used at all_unless users have secure communication channels to share addresses.

This is true but not relevant. The parties with whom we transact are not in the same space as the nodes with which we connect. The fact that I am face-to-face with a counterparty does not help me find a "good" node, nor does my ability to PGP email a payment address or to send a stealth address in the clear.

But the fact that you raise this point is itself instructive. The solution that was devised to resolve the problem of verifying that a counterparty is who one thinks it is ended up being based on the use of certificate authorities - despite the fact the the BIP did not require this. Some people consider this extremely dangerous for Bitcoin, enough so that Peter Todd recently proposed scrapping the BIP.

It's not clear to me how the Bitcoin community intends to establish what nodes are good nodes. But one thing is certain, any anonymous node may be an undetectable attacker.

>> then there is no reason to expect any effective improvement, since nodes will necessarily have to connect with anonymous peers.
> 
> They're not required to _only_ connect with anonymous peers. And partition resistance requires that you have any one good link.

As a minimum requirement, it implies that only need only to connect to one or more "good" peers. Anonymous peers are gravy for partition resistance, yet they are potential attackers for tx tainting. In other words the logical topology is to only connect to good peers. That is a problem.

>> Anyone with a node and the ability to monitor traffic should remain very effective.
> 
> Not via passive observation.

See above commentary on the irrelevance of this distinction.

>> Defining an auth implementation is not a hard problem, nor is it the concern I have raised.
> 
> Glad you agree.

I don't get your point here. It seems like you are just trying to antagonize.

> We seem to be looping now. Feel free to not implement this proposal,

At this point I think it's fair for me to say that nobody needs your permission.

> no one suggests making it mandatory.

Have you ever debated an optional feature proposal?

e

Re: [bitcoin-dev] BIP 151

[Eric Voskuil]

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

Authentication of an anonymous peer cannot achieve this objective, since the peer may be anyone and an attack on privacy can be undetectable. The identity of a peer must be known to the relying peer, either directly or transitively.

DAC is applicable in cases where identity is never required.  The prime example in the paper is that of first-come-first-served name registration. No identity is required in that scenario, just proof that a party in question is the original registrant. All participants are presumed to be "good".

I believe that a distributed anonymous system is fundamentally at odds with isolation of "good" vs. "bad" participants who comply with protocol rules (DoS considerations aside), and that any attempt to resolve this conflict will result in the system no longer allowing anonymous participation.

I may be mistaken, but I haven't found a way out of this realization.

e

> On Jun 29, 2016, at 1:17 PM, Alfie John <alfie@alfie.wtf> wrote:
> 
> 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 design a distributed system that requires authentication
>> but without identity and without central control. In fact this may be more
>> challenging than Bitcoin itself. Trust on first use (TOFU) does not solve this
>> problem.
> 
> Maybe the following paper can feed into this discussion:
> 
> "Decentralized Anonymous Credentials" by Christina Garman, Matthew Green, Ian Miers
>   https://eprint.iacr.org/2013/622.pdf
> 
> Alfie
> 
> -- 
> Alfie John
> https://www.alfie.wtf

Re: [bitcoin-dev] BIP 151

[Jonas Schnelli]

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

Re: [bitcoin-dev] BIP 151

[Eric Voskuil]

> On Jun 30, 2016, at 2:20 PM, Jonas Schnelli <dev@jonasschnelli.ch> 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 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?

It is not clear to me why you believe an attack on privacy by an anonymous peer is detectable.

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

Re: [bitcoin-dev] BIP 151

[Jonas Schnelli]

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



>>> 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?
> 
> It is not clear to me why you believe an attack on privacy by an anonymous peer is detectable.

If Mallory has substituted the ephemeral keys in both directions, at the
point where Alice and Bob will do an authentication, they can be sure
Mallory is listening.

Simple dummy example:
1.) Encryption setup with ECDH with ephemeral keys after BIP151
2.) Mallory is MITMling the connection. He is substituting both
direction with its own keys
3.) Connection is successfully MITMled
4.) Alice tells Bob "prove me that you are Bob, please sign the
session-ID with your identity key"
5.) Bob signs the sessionID (ECDH secret) with his identity key which
will be unusable for Mallory who has a substituted sessionID in both
directions.
6.) Alice has successfully detected the Mallory

Disclaimer: 4) and 5) are _not_ authentication proposals :-)

</jonas>


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

Re: [bitcoin-dev] BIP 151

[Pieter Wuille]

On Thu, Jun 30, 2016 at 11:57 AM, Eric Voskuil via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> 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 already being used widely, and in a very
inadvisable way:
* Since forever there have been lists of 'good nodes' to pass in
addnode= configuration options.
* Various people run multiple nodes in different geographic locations,
peering with each other.
* Various pieces of infrastructure exist that relies on connecting to
well-behaving nodes (miner relay networks, large players peering
directly with each other, ...)
* Several lightweight clients support configuring a trusted host to connect to.

Perhaps you deplore that fact, but I believe it is inevitable that
different pieces of the network will make different choices here. You
can'tg prevent people from create connections along preexisting trust
lines. That does not mean that the network as a whole relies on first
establishing trust everywhere.

And I do think there are advantages.

BIP 151 on its own gives you opportunistic encryption. You're very
right to point out that this does not give you protection from active
attackers, and that active attacking is relatively easy through sybil
attacks. I still prefer my attacker to actually do that over just
listening in on my connection. And yes, we should also work on
improving the privacy nodes and wallets have orthogonal to encryption,
but nothing will make everything perfectly private.

BIP 151 plus a simple optional pre-shared-secret authentication
extension can improve upon pure IP-based authentication, as well as
simplify things like SSL tunnels, and onion addresses purely used as
identity. This will still require explicit configuration, but not more
than now.

BIP 151 plus a non-leaking public key authentication scheme (where
peers can query "are you the peer with pubkey X?" but don't learn
anything if the answer is no) with keys specific to the IP addresses
can give a TOFU-like security. Nodes already remember IP addresses
they've succesfully interacted with in the past, and ban IP addresses
that misbehave. Being able to tell whether a node you connect to is
the same as one you've connected to before is a natural extension of
this, and does not require establishing any real-world identity beyond
what we're already implicitly relying on.

Perhaps these use cases and their security assumptions should be
spelled out more clearly in the BIP. If there is a misunderstanding,
it should be clearly stated that BIP 151 is only a building block for
further improvements

> Secondarily I am concerned about users operating under a false assumption about the strength of privacy.

This is a widespread problem, but it exists far outside the scope of
this proposal. The privacy properties of Bitcoin are often
misrepresented and even used as advertizements. The solution is
education, not avoiding improvements because they may be
misunderstood.

> The complexity of the proposed construction is comparable to that of Bitcoin itself.

I really think this is an exaggeration. It's a diffie-hellman
handshake and a stream cipher (both very common constructions), that
apply to individual connections. There are no consensus risks nor a
requirement for coordinated change through the network. The
cryptographic code can be directly reused from a well-known project
(OpenSSH), and is very small in size.

-- 
Pieter

Re: [bitcoin-dev] BIP 151

[Erik Aronesty]

[-- Attachment #1: Type: text/plain, Size: 10746 bytes --]

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

Something where nodes of any kind (full, spv, mobile wallets) can
/optionally/ accumulate trust over time and are capable of verifying the
identity of other nodes in that web.

*Then* you can slap an encryption layer on top of it.   Once you have
identity & P2P verified pub keys for nodes, encryption becomes easy.


On Thu, Jun 30, 2016 at 5:57 AM, Eric Voskuil via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Jun 29, 2016, at 3:01 AM, Gregory Maxwell <greg@xiph.org> wrote:
> >
> >> On Tue, Jun 28, 2016 at 11:33 PM, Eric Voskuil <eric@voskuil.org>
> 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
>
> "MOTIVATION:
> The Bitcoin network does not encrypt communication between peers today.
> This opens up security issues (eg: traffic manipulation by others) and
> allows for mass surveillance / analysis of bitcoin users. Mostly this is
> negligible because of the nature of Bitcoins trust model, however for SPV
> nodes this can have significant privacy impacts [1] and could reduce the
> censorship-resistance of a peer."
>
> This is not an example, this is the exception that is described as
> "significant" in comparison to the other issues, which are described as
> "negligible".
>
> The Bloom filters messages are of course the unique aspects of the
> protocol as it pertains to "SPV".
>
> The RISKS section declares that the BIP cannot prevent MITM attacks and
> that "identity authentication" will  be defined in a forthcoming BIP.
>
> The obvious implication (accepted by the author) is that authentication is
> required to prevent a MITM attack, and furthermore establishment of
> identity will be required to ensure that the authenticated party is not a
> bad actor.
>
> >>> Without something like BIP151 network participants cannot have privacy
> for the transactions they originate within the protocol against network
> observers.
> >>
> >> And they won't get it with BIP151 either. Being a peer is easier than
> observing the network.
> >
> > Not passively, undetectable, and against thousands of users at once at
> low cost.
>
> This is a straw man, as the BIP does not state that its objective is to
> moderately raise the cost of passive attack against large numbers of users.
>
> It is also a red herring, as passivity is not itself a benefit. It implies
> that the attack is easier and therefore less costly. But a trivial active
> attack may be a larger security problem than a complex passive attack.
> Attacks against privacy under this BIP (and with authentication) can be
> carried out by passively monitoring traffic and operating one or more
> nodes. Operating a node may be considered "active" because the node
> communicates, but technically it is not. In either case the activeness
> itself hardly raises the difficulty, especially for a global (thousands of
> users) passive attacker.
>
> Depending on the attacker, cost may not be an issue at all, so raising it
> can have zero effect. Certainly we are not talking about prohibitive
> (cryptographically hard) cost. Raising the cost *any* amount is not likely
> a reasonable cost-benefit tradeoff.
>
> Privacy attacks would remain entirely undetectable under this proposal,
> and under any additional proposal that required authentication in the
> absence of identity. Only with all users of the network identified as
> "good" would such proposals be effective. Until that point any bad actors
> can become an integral part of the network. I will investigate the question
> of identity in a follow-up to an independent post.
>
> >> If one can observe the encrypted traffic one can certainly use a timing
> attack to determine what the node has sent.
> >
> > Not against Bitcoin Core, transactions are batched and relayed in
> > sorted order.  (obviously there are limits at what this provides;
> > ironically, the lack of link encryption has been used to argue against
> > privacy preserving relay behavior)
>
> It cannot be both impossible ("not against Bitcoin Core") and limited in
> effectiveness ("obviously there are limits").
>
> We should be clear at this point that the transaction-posting security
> provided against a privacy attack, based on the assumption of "good"
> (identified) peers in the first few hops, derives entirely from the ability
> of the good peers to break the timing attack, which is itself "limited".
>
> This is a compound pair of weak assumptions, that to be made stronger will
> require widespread use of identity (not just authentication).
>
> The proliferation of node identity is my primary concern - this relates to
> privacy and the security of the network. Secondarily I am concerned about
> users operating under a false assumption about the strength of privacy.
> Thirdly I am concerned about the risk of vulnerability introduced by the
> integration into the P2P network layer of an totally new network security
> scheme. Fourthly I'm concerned about the cost of the above based on the
> belief that the benefit may not be material and that it may lead to
> increased centralization.
>
> >>> Even if, through some extraordinary effort, their own first hop is
> encrypted, unencrypted later hops would rapidly
> >>> expose significant information about transaction origins in the
> network.
> >>
> >> As will remain the case until all connections are encrypted and
> authenticated, and all participants are known to be good guys. Starting to
> sound like PKI?
> >
> > Huh? The first and subsequent hops obscures the origin and timing.
>
> Described as "limited" in effectiveness, and clearly useful only if these
> hops are not attacker nodes.
>
> So back to my comment on how we maintain a pool of "good" nodes for people
> to connect to, and raising the question of how effective is this strategy
> (which is itself unspecified and so cannot be assumed to even exist in the
> context of the BIP).
>
> >>> Without something like BIP151 authenticated links are not possible, so
> >>> manually curated links (addnode/connect) cannot be counted on to
> provide protection against partitioning sybils.
> >>
> >> If we trust the manual links we don't need/want the other links. In
> fact retaining the other links enables the attack you described above. Of
> course there is no need to worry about Sybil attacks when all of your peers
> are authenticated. But again, let us not ignore the problems of requiring
> all peers on the network be authenticated.
> >
> > Don't need and want them for what?  For _partitioning_ resistance,
> > you are not partitioned if you have one honest connection to the
> > functional network. Additional peers purely reduce your partition
> vulnerability-- so long as an active network attacker isn't
> > intercepting all your connections out.
>
> Don't want them as peers for the purpose of tx relay. As I said this,
> "enables the attack you described above."
>
> > For privacy, you have improve transaction privacy so long as your
> > transaction isn't initially relayed to a malicious peer-- but
> > malicious peers can lie further out because transit nodes obscure the
> > order of message creation.  Bitcoin Core currently relays transactions
> > first and more frequently to outbound and whitelisted peers.
>
> This whitelisting is simply a stand-in for a more formal identity system.
> One doesn't whitelist anonymous peers, one whitelists peers controlled by
> trusted parties. Preferring trusted peers is another aspect of trying to
> break the timing attack. So I would lump this under the same analysis as
> above (batching).
>
> >> Maybe I was insufficiently explicit. By "relies on identity" I meant
> that the BIP is not effective without it. I did not mean to imply that the
> BIP itself implements an identity scheme. I thought this was clear from the
> context.
> >
> > I understood that, but my point was that Bitcoin cannot be used at
> all_unless users have secure communication channels to share addresses.
>
> This is true but not relevant. The parties with whom we transact are not
> in the same space as the nodes with which we connect. The fact that I am
> face-to-face with a counterparty does not help me find a "good" node, nor
> does my ability to PGP email a payment address or to send a stealth address
> in the clear.
>
> But the fact that you raise this point is itself instructive. The solution
> that was devised to resolve the problem of verifying that a counterparty is
> who one thinks it is ended up being based on the use of certificate
> authorities - despite the fact the the BIP did not require this. Some
> people consider this extremely dangerous for Bitcoin, enough so that Peter
> Todd recently proposed scrapping the BIP.
>
> It's not clear to me how the Bitcoin community intends to establish what
> nodes are good nodes. But one thing is certain, any anonymous node may be
> an undetectable attacker.
>
> >> then there is no reason to expect any effective improvement, since
> nodes will necessarily have to connect with anonymous peers.
> >
> > They're not required to _only_ connect with anonymous peers. And
> partition resistance requires that you have any one good link.
>
> As a minimum requirement, it implies that only need only to connect to one
> or more "good" peers. Anonymous peers are gravy for partition resistance,
> yet they are potential attackers for tx tainting. In other words the
> logical topology is to only connect to good peers. That is a problem.
>
> >> Anyone with a node and the ability to monitor traffic should remain
> very effective.
> >
> > Not via passive observation.
>
> See above commentary on the irrelevance of this distinction.
>
> >> Defining an auth implementation is not a hard problem, nor is it the
> concern I have raised.
> >
> > Glad you agree.
>
> I don't get your point here. It seems like you are just trying to
> antagonize.
>
> > We seem to be looping now. Feel free to not implement this proposal,
>
> At this point I think it's fair for me to say that nobody needs your
> permission.
>
> > no one suggests making it mandatory.
>
> Have you ever debated an optional feature proposal?
>
> e
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 12400 bytes --]

Re: [bitcoin-dev] BIP 151

[Alfie John]

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 the
> security of the bitcoin network itself /and/ (eventually) of things like
> transmission of bitcoin addresses.

There already exists an unutilised WoT of "good" actors within the network -
miners via the coinbase transaction. Bootstrapping their own "trusted" pool of
IP addresses would be possible via the 100 bytes coinbase script.

> *Then* you can slap an encryption layer on top of it.   Once you have
> identity & P2P verified pub keys for nodes, encryption becomes easy.

A miner's WoT will give you this.

Alfie

-- 
Alfie John
https://www.alfie.wtf

Re: [bitcoin-dev] BIP 151

[Eric Voskuil]

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 <pieter.wuille@gmail.com> wrote:
> 
> On Thu, Jun 30, 2016 at 11:57 AM, Eric Voskuil via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> 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 already being used widely, and in a very
> inadvisable way:
> * Since forever there have been lists of 'good nodes' to pass in
> addnode= configuration options.
> * Various people run multiple nodes in different geographic locations,
> peering with each other.
> * Various pieces of infrastructure exist that relies on connecting to
> well-behaving nodes (miner relay networks, large players peering
> directly with each other, ...)

Yes, libbitcoin also provides these options on an IP basis.

> * Several lightweight clients support configuring a trusted host to connect to.

I explicitly exclude client-server behavior as I believe the proper resolution is to isolate clients from the P2P protocol. Libbitcoin does this already.

> Perhaps you deplore that fact, but I believe it is inevitable that different pieces of the network will make different choices here. You can't prevent people from create connections along preexisting trust lines. That does not mean that the network as a whole relies on first establishing trust everywhere.

Of course, the network operates just fine without universal trust. My concern is not that it is required, but that it may grow significantly and will have a tendency to gravitate towards more effective registration mechanisms for what is a "good" peer. Even an informal but pervasive web of trust may make it difficult for untrusted parties to connect.

> And I do think there are advantages.
> 
> BIP 151 on its own gives you opportunistic encryption. You're very right to point out that this does not give you protection from active attackers, and that active attacking is relatively easy through sybil attacks. I still prefer my attacker to actually do that over just listening in on my connection.

We agree, and the ease of this attack must be acknowledged. And given that the protection is weak it is not unreasonable to consider the potential downside of creeping node identity.

> And yes, we should also work on improving the privacy nodes and wallets have orthogonal to encryption, but nothing will make everything perfectly private.

I agree, and I doubt this proposal will have much impact on an advanced persistent threat, or even lesser threats. People should understand that there is both a risk and a limited benefit to this proposal.

> BIP 151 plus a simple optional pre-shared-secret authentication extension can improve upon pure IP-based authentication, as well as simplify things like SSL tunnels, and onion addresses purely used as identity. This will still require explicit configuration, but not more than now.

I agree - I consider tunneling the legitimate use case for this proposal. Yet when nodes become closely coupled they are not fully independent. I have a concern with these practices being promoted for general use while at the same time being strongly implemented.

> BIP 151 plus a non-leaking public key authentication scheme (where peers can query "are you the peer with pubkey X?" but don't learn anything if the answer is no) with keys specific to the IP addresses can give a TOFU-like security. Nodes already remember IP addresses they've succesfully interacted with in the past, and ban IP addresses that misbehave. Being able to tell whether a node you connect to is the same as one you've connected to before is a natural extension of this,

With this I disagree. There is no way to know that a node is one you have connected to previously unless that node wants you to know (apart from relying on the IP address). This is of no value in detecting misbehaving nodes that do not want to be detected. Ones that don't care (eg broken nodes) can be sufficiently managed by IP address.

> and does not require establishing any real-world identity beyond what we're already implicitly relying on.
> 
> Perhaps these use cases and their security assumptions should be spelled out more clearly in the BIP.

Absolutely.

> If there is a misunderstanding, it should be clearly stated that BIP 151 is only a building block for further improvements
> 
>> Secondarily I am concerned about users operating under a false assumption about the strength of privacy.
> 
> This is a widespread problem, but it exists far outside the scope of this proposal. The privacy properties of Bitcoin are often
> misrepresented and even used as advertizements. The solution is education, not avoiding improvements because they may be misunderstood.

Yes, let's not make it worse. This is a secondary concern. I remain primarily concerned about growth of node identity in a vain attempt to make transaction submission private in the P2P protocol (and to patch the other client-server features, specifically Bloom filters). As you imply, we cannot stop people from turning Bitcoin into a private network - but let's not facilitate it either.

>> The complexity of the proposed construction is comparable to that of Bitcoin itself.
> 
> I really think this is an exaggeration. It's a diffie-hellman handshake and a stream cipher (both very common constructions), that apply to individual connections. There are no consensus risks nor a
> requirement for coordinated change through the network. The
> cryptographic code can be directly reused from a well-known project
> (OpenSSH), and is very small in size.

I believe you have misinterpreted my comments on distributed anonymous credentials (and the like) as commentary on the construction of BIP151 (and a subsequent auth proposal). As such your observation that it is exaggerated would make sense, but it is not what I intended. Encryption and auth are straightforward. Preventing bad nodes from participating in an anonymous distributed system is not.

e

Re: [bitcoin-dev] BIP 151

[Eric Voskuil]

> On Jun 30, 2016, at 2:43 PM, Jonas Schnelli <dev@jonasschnelli.ch> 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 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?
>> 
>> It is not clear to me why you believe an attack on privacy by an anonymous peer is detectable.
> 
> If Mallory has substituted the ephemeral keys in both directions, at the
> point where Alice and Bob will do an authentication, they can be sure
> Mallory is listening.

I understand the mechanics of a tunnel between trusting parties that have a secure side channel. But this assumes that no other peer can connect to these two nodes. How then do they maintain the chain?

The "middle" in this sense does not have to be the wire directly between these two peers. It can be between either of them and any anonymous connection they (must) allow.

Of course this creates pressure to expand their tunnel. Hence the problem of expanding node identity in an effort to preserve privacy. The protection will remain weak until the entire network is "secure". At that point it would necessarily be a private network.

As Pieter rightly observes, there are and always will be tunnels between trusting nodes. Often these are groups of nodes that are in collaboration, so logically they are one node from a system security standpoint. But if people become generally reliant on good node registration, it will become the registrar who controls access to the network. So my concern rests I this proposal becoming widely adopted.

> Simple dummy example:
> 1.) Encryption setup with ECDH with ephemeral keys after BIP151
> 2.) Mallory is MITMling the connection. He is substituting both direction with its own keys
> 3.) Connection is successfully MITMled
> 4.) Alice tells Bob "prove me that you are Bob, please sign the session-ID with your identity key"
> 5.) Bob signs the sessionID (ECDH secret) with his identity key which
> will be unusable for Mallory who has a substituted sessionID in both directions.
> 6.) Alice has successfully detected the Mallory
> 
> Disclaimer: 4) and 5) are _not_ authentication proposals :-)
> 
> </jonas>
> 

Re: [bitcoin-dev] BIP 151

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 2409 bytes --]

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 <dev@jonasschnelli.ch> 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 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?
> >> 
> >> It is not clear to me why you believe an attack on privacy by an anonymous peer is detectable.
> > 
> > If Mallory has substituted the ephemeral keys in both directions, at the
> > point where Alice and Bob will do an authentication, they can be sure
> > Mallory is listening.
> 
> I understand the mechanics of a tunnel between trusting parties that have a secure side channel. But this assumes that no other peer can connect to these two nodes. How then do they maintain the chain?
> 
> The "middle" in this sense does not have to be the wire directly between these two peers. It can be between either of them and any anonymous connection they (must) allow.
> 
> Of course this creates pressure to expand their tunnel. Hence the problem of expanding node identity in an effort to preserve privacy. The protection will remain weak until the entire network is "secure". At that point it would necessarily be a private network.
> 
> As Pieter rightly observes, there are and always will be tunnels between trusting nodes. Often these are groups of nodes that are in collaboration, so logically they are one node from a system security standpoint. But if people become generally reliant on good node registration, it will become the registrar who controls access to the network. So my concern rests I this proposal becoming widely adopted.

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
proposes. And we're shipping that in production as of 0.12.0, and by default
Tor onion support is enabled and will be automatically setup if you have a
recent version of Tor installed.

Does that "create pressure to expand node identity"?

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [bitcoin-dev] BIP 151

[Eric Voskuil]

> On Jun 30, 2016, at 6:52 PM, Peter Todd <pete@petertodd.org> 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 <dev@jonasschnelli.ch> 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 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?
>>>> 
>>>> It is not clear to me why you believe an attack on privacy by an anonymous peer is detectable.
>>> 
>>> If Mallory has substituted the ephemeral keys in both directions, at the
>>> point where Alice and Bob will do an authentication, they can be sure
>>> Mallory is listening.
>> 
>> I understand the mechanics of a tunnel between trusting parties that have a secure side channel. But this assumes that no other peer can connect to these two nodes. How then do they maintain the chain?
>> 
>> The "middle" in this sense does not have to be the wire directly between these two peers. It can be between either of them and any anonymous connection they (must) allow.
>> 
>> Of course this creates pressure to expand their tunnel. Hence the problem of expanding node identity in an effort to preserve privacy. The protection will remain weak until the entire network is "secure". At that point it would necessarily be a private network.
>> 
>> As Pieter rightly observes, there are and always will be tunnels between trusting nodes. Often these are groups of nodes that are in collaboration, so logically they are one node from a system security standpoint. But if people become generally reliant on good node registration, it will become the registrar who controls access to the network. So my concern rests I this proposal becoming widely adopted.
> 
> 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 proposes.

BIP151 is self-admittedly insufficient to protect against a MITM attack. It proposes node identity to close this hole (future BIP required). The yet-to-be-specified requirement for node identity is the basis of my primary concern. This is not self-authentication.

> And we're shipping that in production as of 0.12.0, and by default Tor onion support is enabled and will be automatically setup if you have a recent version of Tor installed.
> 
> Does that "create pressure to expand node identity"?

The orthogonal question of whether Tor is safe for use with the Bitcoin P2P protocol is a matter of existing research.

e

Re: [bitcoin-dev] BIP 151

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1560 bytes --]

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 proposes.
> 
> BIP151 is self-admittedly insufficient to protect against a MITM attack. It proposes node identity to close this hole (future BIP required). The yet-to-be-specified requirement for node identity is the basis of my primary concern. This is not self-authentication.
> 
> > And we're shipping that in production as of 0.12.0, and by default Tor onion support is enabled and will be automatically setup if you have a recent version of Tor installed.
> > 
> > Does that "create pressure to expand node identity"?
> 
> The orthogonal question of whether Tor is safe for use with the Bitcoin P2P protocol is a matter of existing research.

I don't think you answered my question.

Again, we _already have_ the equivalent of BIP151 functionality in Bitcoin
Core, shipping in production, but implemented with a Tor dependency.

BIP151 removes that dependency on Tor, enabling encrypted connections
regardless of whether or not you have Tor installed.

So any arguments against BIP151 being implemented, are equally arguments
against our existing Tor onion support. Are you against that support? Because
if you aren't, you can't have any objections to BIP151 being implemented
either.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [bitcoin-dev] BIP 151

[Eric Voskuil]

> On Jun 30, 2016, at 9:06 PM, Peter Todd <pete@petertodd.org> 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
>>> addresses, which are self-authenticated in the exact same way as BIP151 proposes.
>> 
>> BIP151 is self-admittedly insufficient to protect against a MITM attack. It proposes node identity to close this hole (future BIP required). The yet-to-be-specified requirement for node identity is the basis of my primary concern. This is not self-authentication.
>> 
>>> And we're shipping that in production as of 0.12.0, and by default Tor onion support is enabled and will be automatically setup if you have a recent version of Tor installed.
>>> 
>>> Does that "create pressure to expand node identity"?
>> 
>> The orthogonal question of whether Tor is safe for use with the Bitcoin P2P protocol is a matter of existing research.
> 
> I don't think you answered my question.
> 
> Again, we _already have_ the equivalent of BIP151 functionality in Bitcoin
> Core, shipping in production, but implemented with a Tor dependency.
> 
> BIP151 removes that dependency on Tor, enabling encrypted connections
> regardless of whether or not you have Tor installed.
> 
> So any arguments against BIP151 being implemented, are equally arguments
> against our existing Tor onion support. Are you against that support? Because
> if you aren't, you can't have any objections to BIP151 being implemented

Neither Tor nor Bitcoin Core are part of this BIP (or its proposed dependency on node identity).

But again, given that node identity is not part of the Bitcoin Core Tor integration, my objection to the presumption of node identity by BIP151 is unrelated to Bitcoin Core's Tor integration.

e

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

[Rusty Russell]

Ethan Heilman <eth3rs@gmail.com> 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 have a tag y = SHA256(key|cipher-type|mesg), I can without
> knowing key or msg compute a value y' such that
> y' = SHA256(key|cipher-type|mesg|any values I want).

Not quite, there's an important subtlety that SHA256 appends the
bitlength, so you can only create:

y' = SHA256(key|cipher-type|mesg|padding|bitlength|any values I want).

But we're not using this for a MAC in BIP151, we're using this to
generate the encryption keys.

Arthur Chen <arthur.chen@btcc.com> said:
> 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 Authentication
> Code) rather than custom construction

Bitcoin already relies on SHA256's robustness, but again, we don't need
a MAC here.

I'm happy to buy "we just copied ssh" if that's the answer, and I can't
see anything wrong with using HMAC here, it just seems odd...

Thanks!
Rusty.

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

[Zooko Wilcox]

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
decisions, so you can see why they did it (very slightly) differently
than the various constructions proposed up-thread.

https://eprint.iacr.org/2010/264

Also, of course, it is a great idea to re-use a standard
(https://tools.ietf.org/html/rfc5869) and widely-understood crypto
algorithm to reduce risk of both cryptographer errors and implementor
errors.

Of course, the cost of that is the you sometimes end up computing
something that is a tiny bit more complicated or inefficient than a
custom algorithm for our current use case. IMHO that's a cheap price
to pay.

Regards,

Zooko

Re: [bitcoin-dev] BIP 151

[Chris Priest]

On 6/30/16, Erik Aronesty via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> 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 of any kind (full, spv, mobile wallets) can
> /optionally/ accumulate trust over time and are capable of verifying the
> identity of other nodes in that web.
>

Isn't the system already functioning in this way already? Bitcoin
exchanges and block explorers already have a reputation earned by so
many years of serving the community. Their HTTPS certificate acts like
a public/private key, and when your wallet makes a request to their
server, the keys are automatically checked for validity by the
underlying http library.

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

[Arthur Chen]

[-- Attachment #1: Type: text/plain, Size: 1418 bytes --]

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
> 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
> decisions, so you can see why they did it (very slightly) differently
> than the various constructions proposed up-thread.
>
> https://eprint.iacr.org/2010/264
>
> Also, of course, it is a great idea to re-use a standard
> (https://tools.ietf.org/html/rfc5869) and widely-understood crypto
> algorithm to reduce risk of both cryptographer errors and implementor
> errors.
>
> Of course, the cost of that is the you sometimes end up computing
> something that is a tiny bit more complicated or inefficient than a
> custom algorithm for our current use case. IMHO that's a cheap price
> to pay.
>
> Regards,
>
> Zooko
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>



-- 
Xuesong (Arthur) Chen
Senior Principle Engineer
BlockChain Technologist
BTCC

[-- Attachment #2: Type: text/html, Size: 2375 bytes --]

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

[Arthur Chen]

[-- Attachment #1: Type: text/plain, Size: 1707 bytes --]

https://www.schneier.com/crypto-gram/archives/1998/1015.html#cipherdesign

On Mon, Jul 4, 2016 at 1:23 AM, Arthur Chen <arthur.chen@btcc.com> wrote:

> 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
>> 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
>> decisions, so you can see why they did it (very slightly) differently
>> than the various constructions proposed up-thread.
>>
>> https://eprint.iacr.org/2010/264
>>
>> Also, of course, it is a great idea to re-use a standard
>> (https://tools.ietf.org/html/rfc5869) and widely-understood crypto
>> algorithm to reduce risk of both cryptographer errors and implementor
>> errors.
>>
>> Of course, the cost of that is the you sometimes end up computing
>> something that is a tiny bit more complicated or inefficient than a
>> custom algorithm for our current use case. IMHO that's a cheap price
>> to pay.
>>
>> Regards,
>>
>> Zooko
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
>
> --
> Xuesong (Arthur) Chen
> Senior Principle Engineer
> BlockChain Technologist
> BTCC
>



-- 
Xuesong (Arthur) Chen
Senior Principle Engineer
BlockChain Technologist
BTCC

[-- Attachment #2: Type: text/html, Size: 3157 bytes --]

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

[Jonas Schnelli]

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

> 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
> decisions, so you can see why they did it (very slightly) differently
> than the various constructions proposed up-thread.

Thanks Zooko

I think HKDF instead of a single HMAC_SHA512 seams reasonable and
something we should consider.

I'll try to evaluate the implications of using HKDF over HMAC_SHA512 and
will update the BIP if there are no concerns about it.

</jonas>


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

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

[Jonas Schnelli]

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

Hi Arthur
> 
>     I strongly agree!
>     In crypto we should always follow well-studied open standard rather
>     than custom construction.

I totally agree.
BIP151 does not introduce new cipher types.
The BIP uses ECDH together with ChaCha20-Poly1305@openssh.
Both very well known and broad used crypo.

/jonas


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

Re: [bitcoin-dev] BIP 151

[Pieter Wuille]

Hello Eric,

I felt like I still owed you a response to the points below.

On Thu, Jun 30, 2016 at 5:10 PM, Eric Voskuil <eric@voskuil.org> wrote:
> 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 <pieter.wuille@gmail.com> wrote:
>>
>> On Thu, Jun 30, 2016 at 11:57 AM, Eric Voskuil via bitcoin-dev
>> <bitcoin-dev@lists.linuxfoundation.org> 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 already being used widely, and in a very
>> inadvisable way:
>> * Since forever there have been lists of 'good nodes' to pass in
>> addnode= configuration options.
>> * Various people run multiple nodes in different geographic locations,
>> peering with each other.
>> * Various pieces of infrastructure exist that relies on connecting to
>> well-behaving nodes (miner relay networks, large players peering
>> directly with each other, ...)
>
> Yes, libbitcoin also provides these options on an IP basis.
>
>> * Several lightweight clients support configuring a trusted host to connect to.
>
> I explicitly exclude client-server behavior as I believe the proper resolution is to isolate clients from the P2P protocol. Libbitcoin does this already.

I think that's a false dichotomy. There is no reason why the P2P
network consists of purely servers (full nodes) and clients
(lightweight nodes). Where does a client fit that is SPV at startup,
but upgrades in the background to a full node? It seems strange that
such a client would use a 'client protocol' for initial connections,
but the P2P protocol for syncing with history, when both come from the
same peers, and transmit the same kind of information.

What would make sense IMHO is a protocol split between the different
kinds of transmission:
1) Historical block download
2) Block synchronization at the tip
3) Transaction relay
...

(1) prefers high bandwidth, has no connectivity concerns, and does not
care about latency and has no privacy concerns. (2) needs
partition-resistance, low latency and has also no privacy concerns.
(3) needs moderate latency, reliability of propagation and privacy.

If there were to be separate protocols for these, I would argue that
(3) should use opportunistic encryption always to increase transaction
source privacy, and (2) and (3) need authentication when one of the
peers is not fully validating.

BIP 150/151 give the tools to construct these.

>> Perhaps you deplore that fact, but I believe it is inevitable that different pieces of the network will make different choices here. You can't prevent people from create connections along preexisting trust lines. That does not mean that the network as a whole relies on first establishing trust everywhere.
>
> Of course, the network operates just fine without universal trust. My concern is not that it is required, but that it may grow significantly and will have a tendency to gravitate towards more effective registration mechanisms for what is a "good" peer. Even an informal but pervasive web of trust may make it difficult for untrusted parties to connect.

Maybe, but I'm very unconvinced that that will happen more than how
today IP and DNS-based "authentication" is used already (in very
inadvisable ways).

>> And I do think there are advantages.
>>
>> BIP 151 on its own gives you opportunistic encryption. You're very right to point out that this does not give you protection from active attackers, and that active attacking is relatively easy through sybil attacks. I still prefer my attacker to actually do that over just listening in on my connection.

> I agree, and I doubt this proposal will have much impact on an advanced persistent threat, or even lesser threats. People should understand that there is both a risk and a limited benefit to this proposal.

I believe the risk is only in misunderstanding what it is good for,
and there significant benefits to a network that encrypts connections
by default, as it excludes purely passive attackers.

> I believe you have misinterpreted my comments on distributed anonymous credentials (and the like) as commentary on the construction of BIP151 (and a subsequent auth proposal). As such your observation that it is exaggerated would make sense, but it is not what I intended. Encryption and auth are straightforward. Preventing bad nodes from participating in an anonymous distributed system is not.

Preventing bad nodes from participating is a very hard problem, if not
impossible. That doesn't mean we can't improve the current situation:
people are relying on node identity already, and doing so in ways that
have unclear attack vectors (IP spoofing, DNS poisoning, BGP routing
attacks). Adding optional and non-discoverable cryptographic
identities can improve this.

-- 
Pieter