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 be
>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 w
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 Authenticati
Jonas Schnelli writes:
>> To quote:
>>
>>> HMAC_SHA512(key=ecdh_secret|cipher-type,msg="encryption key").
>>>
>>> K_1 must be the left 32bytes of the HMAC_SHA512 hash.
>>> K_2 must be the right 32bytes of the HMAC_SHA512 hash.
>>
>> This seems a weak reason to introduce SHA512 to the mix. Can
On Tue, Jun 28, 2016 at 11:33 PM, Eric Voskuil wrote:
> I don't follow this comment. The BIP aims quite clearly at "SPV" wallets as
> its justifying scenario.
It cites SPV as an example, doesn't mention bloom filters.. and sure--
sounds like the bip text should make the
>> Without something lik
>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 n
>> On Jun 29, 2016, at 12:22 AM, Gregory Maxwell wrote:
>>
>> On Tue, Jun 28, 2016 at 9:59 PM, Eric Voskuil wrote:
>> Passing the session ID out of band is authentication. As this is explicitly
>> not part of BIP151 it cannot be that BIP151 provides the tools to detect a
>> attack (the point
On Jun 28, 2016, at 9:55 PM, Gregory Maxwell via bitcoin-dev
wrote:
>> I understand the use, when coupled with a yet-to-be-devised identity system,
>> with Bloom filter features. Yet these features
>
> This is a bit of a strawman, you've selected a single narrow usecase which
> isn't proposed
On Jun 28, 2016, at 10:06 PM, Jonas Schnelli wrote:
>>> In my opinion, the question should be "why would you _not_ encrypt".
>>
>> 1) creation of a false sense of security
>
> False sense of security is mostly a communication issue.
> BIP151 does focus on encryption (not trust).
>
> Are users
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,
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
Hi Cameron, good to hear from you!
> On Jun 28, 2016, at 11:40 PM, Cameron Garnham wrote:
>
> Unauthenticated link level encryption is wonderful! MITM attacks are
> overrated; as they require an active attacker.
This is not really the case with Bitcoin. A MITM attack does not require that
the
> On Jun 28, 2016, at 11:36 PM, Gregory Maxwell wrote:
>
> On Tue, Jun 28, 2016 at 9:22 PM, Eric Voskuil via bitcoin-dev
> wrote:
>> An "out of band key check" is not part of BIP151.
>
> It has a session ID for this purpose.
Passing the session ID out of band is authentication. As this is ex
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 prob
On Tue, Jun 28, 2016 at 9:22 PM, Eric Voskuil via bitcoin-dev
wrote:
> An "out of band key check" is not part of BIP151.
It has a session ID for this purpose.
> It requires a secure channel and is authentication. So BIP151 doesn't provide
> the tools to detect an attack, that requires authentic
> On Jun 28, 2016, at 10:36 PM, Peter Todd wrote:
>
>> On Tue, Jun 28, 2016 at 10:29:54PM +0200, Eric Voskuil wrote:
>>
>>
On Jun 28, 2016, at 10:14 PM, Peter Todd wrote:
On Tue, Jun 28, 2016 at 08:35:26PM +0200, Eric Voskuil wrote:
Hi Peter,
What in this BIP m
On Tue, Jun 28, 2016 at 10:29:54PM +0200, Eric Voskuil wrote:
>
>
> > On Jun 28, 2016, at 10:14 PM, Peter Todd wrote:
> >
> >> On Tue, Jun 28, 2016 at 08:35:26PM +0200, Eric Voskuil wrote:
> >> Hi Peter,
> >>
> >> What in this BIP makes a MITM attack easier (or easy) to detect, or
> >> increa
> On Jun 28, 2016, at 10:14 PM, Peter Todd wrote:
>
>> On Tue, Jun 28, 2016 at 08:35:26PM +0200, Eric Voskuil wrote:
>> Hi Peter,
>>
>> What in this BIP makes a MITM attack easier (or easy) to detect, or
>> increases the probability of one being detected?
>
> BIP151 gives users the tools to
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
>> 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 s
> 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 mu
Hi Peter,
What in this BIP makes a MITM attack easier (or easy) to detect, or increases
the probability of one being detected?
e
> On Jun 28, 2016, at 8:22 PM, Peter Todd wrote:
>
> On Tue, Jun 28, 2016 at 06:45:58PM +0200, Eric Voskuil via bitcoin-dev wrote:
>>> 1) Transaction censorship
>>>
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 ca
continued from previous post...
> On Jun 28, 2016, at 2:13 PM, Jonas Schnelli via bitcoin-dev
> wrote:
>
> Hi Eric
>
> Sorry for not directly addressing your points.
No problem. Thanks for the detailed replies.
> I try to be more precise in this follow up email:
>
>> I understand the use, w
Hi Jonas, I'll follow up in your second reply as well. Responses inline:
> On Jun 28, 2016, at 10:26 AM, Jonas Schnelli via bitcoin-dev
> wrote:
>
> Hi Eric
>
>> I haven't seen much discussion here on the rationale behind BIP 151.
>> Apologies if I missed it. I'm trying to understand why libb
Thanks for Peter Todd’s detailed report:
https://petertodd.org/2016/segwit-consensus-critical-code-review
I have the following response.
>Since the reserve value is only a single, 32-byte value, we’re setting
>ourselves up for the same problem again7.
Please note that unlimited space has been r
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) suppor
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=e
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 feat
> 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
-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 sys
31 matches
Mail list logo
