Martin Habovštiak [ARCHIVE] on Nostr: 📅 Original date posted:2015-02-05 📝 Original message:-----BEGIN PGP SIGNED ...
📅 Original date posted:2015-02-05
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
I believe, we are still talking about transactions of physical people in physical world. So yes, it's proximity based - people tell the words by mouth. :)
In case of RedPhone, you read those words verbally over not-yet-verified channel relying on difficulty of spoofing your voice. Also the app remembers the public keys, so you don't need to verify second time.
I suggest you to try RedPhone (called Signal on iPhone) yourself. It's free/open source, Internet-based and end-to-end encrypted. You may find it useful some day. Also I'm willing to help you with trying it after I wake up. (~8 hours: Send me private e-mail if you want to.)
Dňa 6. februára 2015 1:22:23 CET používateľ Eric Voskuil <eric at voskuil.org> napísal:
>
>On 02/05/2015 04:04 PM, MⒶrtin HⒶboⓋštiak wrote:
>> That's exactly what I though when seeing the RedPhone code, but after
>> I studied the commit protocol I realized it's actually secure and
>> convenient way to do it. You should do that too. :)
>
>I was analyzing the model as you described it to me. A formal analysis
>of the security model of a particular implementation, based on
>inference
>from source code, is a bit beyond what I signed up for. But I'm
>perfectly willing to comment on your description of the model if you
>are
>willing to indulge me.
>
>> Shortly, how it works:
>> The initiator of the connection sends commit message containing the
>> hash of his temporary public ECDH part, second party sends back their
>> public ECDH part and then initiator sends his public ECDH part in
>> open. All three messages are hashed together and the first two bytes
>> are used to select two words from a shared dictionary which are
>> displayed on the screen of both the initiator and the second party.
>
>> The parties communicate those two words and verify they match.
>
>How do they compare words if they haven't yet established a secure
>channel?
>
>> If an attacker wants to do MITM, he has a chance of choosing right
>> public parts 1:65536. There is no way to brute-force it, since that
>> would be noticed immediately. If instead of two words based on the
>> first two bytes, four words from BIP39 wordlist were chosen, it would
>> provide entropy of 44 bits which I believe should be enough even for
>> paranoid people.
>>
>> How this would work in Bitcoin payment scenario: user's phone
>> broadcasts his name, merchant inputs amount and selects the name from
>> the list, commit message is sent (and then the remaining two
>> messages), merchant spells four words he sees on the screen and buyer
>> confirms transaction after verifying that words match.
>
>So the assumption is that there exists a secure (as in proximity-based)
>communication channel?
>
>e
>
>> 2015-02-06 0:46 GMT+01:00 Eric Voskuil <eric at voskuil.org>:
>>> On 02/05/2015 03:36 PM, MⒶrtin HⒶboⓋštiak wrote:
>>>>> A BIP-70 signed payment request in the initial broadcast can
>resolve the
>>>>> integrity issues, but because of the public nature of the
>broadcast
>>>>> coupled with strong public identity, the privacy compromise is
>much
>>>>> worse. Now transactions are cryptographically tainted.
>>>>>
>>>>> This is also the problem with BIP-70 over the web. TLS and other
>>>>> security precautions aside, an interloper on the communication,
>desktop,
>>>>> datacenter, etc., can capture payment requests and strongly
>correlate
>>>>> transactions to identities in an automated manner. The payment
>request
>>>>> must be kept private between the parties, and that's hard to do.
>>>>
>>>> What about using encryption with forward secrecy? Merchant would
>>>> generate signed request containing public ECDH part, buyer would
>send
>>>> back transaction encrypted with ECDH and his public ECDH part. If
>>>> receiving address/amount is meant to be private, use commit
>protocol
>>>> (see ZRTP/RedPhone) and short authentication phrase (which is hard
>to
>>>> spoof thanks to commit protocol - see RedPhone)?
>>>
>>> Hi Martin,
>>>
>>> The problem is that you need to verify the ownership of the public
>key.
>>> A MITM can substitute the key. If you don't have verifiable identity
>>> associated with the public key (PKI/WoT), you need a shared secret
>(such
>>> as a secret phrase). But the problem is then establishing that
>secret
>>> over a public channel.
>>>
>>> You can bootstrap a private session over the untrusted network using
>a
>>> trusted public key (PKI/WoT). But the presumption is that you are
>>> already doing this over the web (using TLS). That process is subject
>to
>>> attack at the CA. WoT is not subject to a CA attack, because it's
>>> decentralized. But it's also not sufficiently deployed for some
>scenarios.
>>>
>>> e
>>>
- --
Odoslané z môjho Android zariadenia pomocou K-9 Mail.
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1
iI8EAREKADcFAlTUDKEwHE1hcnRpbiBIYWJvdmF0aWFrIDxtYXJ0aW4uaGFib3Zz
dGlha0BnbWFpbC5jb20+AAoJED6C3NvqapyUfUgA/2j6jQELBtSrNsle7ybGq1D8
uWgGwevguCnjPd0pEpWgAP42sS/ekCqs1v9wbART9fLprZTBk4YPllwXifss+9sa
zQ==
=J4w/
-----END PGP SIGNATURE-----
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
I believe, we are still talking about transactions of physical people in physical world. So yes, it's proximity based - people tell the words by mouth. :)
In case of RedPhone, you read those words verbally over not-yet-verified channel relying on difficulty of spoofing your voice. Also the app remembers the public keys, so you don't need to verify second time.
I suggest you to try RedPhone (called Signal on iPhone) yourself. It's free/open source, Internet-based and end-to-end encrypted. You may find it useful some day. Also I'm willing to help you with trying it after I wake up. (~8 hours: Send me private e-mail if you want to.)
Dňa 6. februára 2015 1:22:23 CET používateľ Eric Voskuil <eric at voskuil.org> napísal:
>
>On 02/05/2015 04:04 PM, MⒶrtin HⒶboⓋštiak wrote:
>> That's exactly what I though when seeing the RedPhone code, but after
>> I studied the commit protocol I realized it's actually secure and
>> convenient way to do it. You should do that too. :)
>
>I was analyzing the model as you described it to me. A formal analysis
>of the security model of a particular implementation, based on
>inference
>from source code, is a bit beyond what I signed up for. But I'm
>perfectly willing to comment on your description of the model if you
>are
>willing to indulge me.
>
>> Shortly, how it works:
>> The initiator of the connection sends commit message containing the
>> hash of his temporary public ECDH part, second party sends back their
>> public ECDH part and then initiator sends his public ECDH part in
>> open. All three messages are hashed together and the first two bytes
>> are used to select two words from a shared dictionary which are
>> displayed on the screen of both the initiator and the second party.
>
>> The parties communicate those two words and verify they match.
>
>How do they compare words if they haven't yet established a secure
>channel?
>
>> If an attacker wants to do MITM, he has a chance of choosing right
>> public parts 1:65536. There is no way to brute-force it, since that
>> would be noticed immediately. If instead of two words based on the
>> first two bytes, four words from BIP39 wordlist were chosen, it would
>> provide entropy of 44 bits which I believe should be enough even for
>> paranoid people.
>>
>> How this would work in Bitcoin payment scenario: user's phone
>> broadcasts his name, merchant inputs amount and selects the name from
>> the list, commit message is sent (and then the remaining two
>> messages), merchant spells four words he sees on the screen and buyer
>> confirms transaction after verifying that words match.
>
>So the assumption is that there exists a secure (as in proximity-based)
>communication channel?
>
>e
>
>> 2015-02-06 0:46 GMT+01:00 Eric Voskuil <eric at voskuil.org>:
>>> On 02/05/2015 03:36 PM, MⒶrtin HⒶboⓋštiak wrote:
>>>>> A BIP-70 signed payment request in the initial broadcast can
>resolve the
>>>>> integrity issues, but because of the public nature of the
>broadcast
>>>>> coupled with strong public identity, the privacy compromise is
>much
>>>>> worse. Now transactions are cryptographically tainted.
>>>>>
>>>>> This is also the problem with BIP-70 over the web. TLS and other
>>>>> security precautions aside, an interloper on the communication,
>desktop,
>>>>> datacenter, etc., can capture payment requests and strongly
>correlate
>>>>> transactions to identities in an automated manner. The payment
>request
>>>>> must be kept private between the parties, and that's hard to do.
>>>>
>>>> What about using encryption with forward secrecy? Merchant would
>>>> generate signed request containing public ECDH part, buyer would
>send
>>>> back transaction encrypted with ECDH and his public ECDH part. If
>>>> receiving address/amount is meant to be private, use commit
>protocol
>>>> (see ZRTP/RedPhone) and short authentication phrase (which is hard
>to
>>>> spoof thanks to commit protocol - see RedPhone)?
>>>
>>> Hi Martin,
>>>
>>> The problem is that you need to verify the ownership of the public
>key.
>>> A MITM can substitute the key. If you don't have verifiable identity
>>> associated with the public key (PKI/WoT), you need a shared secret
>(such
>>> as a secret phrase). But the problem is then establishing that
>secret
>>> over a public channel.
>>>
>>> You can bootstrap a private session over the untrusted network using
>a
>>> trusted public key (PKI/WoT). But the presumption is that you are
>>> already doing this over the web (using TLS). That process is subject
>to
>>> attack at the CA. WoT is not subject to a CA attack, because it's
>>> decentralized. But it's also not sufficiently deployed for some
>scenarios.
>>>
>>> e
>>>
- --
Odoslané z môjho Android zariadenia pomocou K-9 Mail.
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1
iI8EAREKADcFAlTUDKEwHE1hcnRpbiBIYWJvdmF0aWFrIDxtYXJ0aW4uaGFib3Zz
dGlha0BnbWFpbC5jb20+AAoJED6C3NvqapyUfUgA/2j6jQELBtSrNsle7ybGq1D8
uWgGwevguCnjPd0pEpWgAP42sS/ekCqs1v9wbART9fLprZTBk4YPllwXifss+9sa
zQ==
=J4w/
-----END PGP SIGNATURE-----