Brian Erdelyi [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-01-31 to 2015-02-03
💬 Posted a total of 13 messages
📚 Participated in the following categories: Bitcoin-development
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 17:29:32

- reply

📅 Original date posted:2015-02-03
📝 Original message:> Regardless, I think a standard for passing partially signed transactions around might make sense (maybe a future extension to BIP70), with attention to both PC <-> small hardware devices and pushing stuff around on the Internet. It would be great if users had a choice of hardware signing devices, local software and third-party cosigning services that would all interoperate out of the box to enable easy multisig security, which in the BTC world subsumes the goals of 2FA.
I think a standard for passing partially signed transactions is a great idea as well. This would support interoperability of wallets/clients and third-party services (if users choose to use them).
Brian Erdelyi

2023-06-07 17:29:21

- reply

📅 Original date posted:2015-02-02
📝 Original message:Martin,
Yes, the second signing could be done by a mobile device that I owned and controlled (I wasn't thinking that initially). I was thinking that online services are popular because of convenience and there should be a better way to address security (privacy issues not withstanding).
I think these are practical approaches and just doing a sanity check. Thanks for the vote of confidence.
Brian Erdelyi
Sent from my iPad
> On Feb 2, 2015, at 1:54 PM, Martin Habovštiak <martin.habovstiak at gmail.com> wrote:
>
> Good idea. I think this could be even better:
>
> instead of using third party, send partially signed TX from computer
> to smartphone. In case, you are paranoid, make 3oo5 address made of
> two cold storage keys, one on desktop/laptop, one on smartphone, one
> using third party.
> If it isn't enough, add requirement of another four keys, so you have
> three desktops with different OS (Linux, Windows, Mac) and three
> mobile OS (Android, iOS, Windows Phone), third party and some keys in
> cold storage. Also, I forgot HW wallets, so at least Trezor and
> Ledger. I believe this scheme is unpenetrable by anyone, including
> NSA, FBI, CIA, NBU...
>
> Jokes aside, I think leaving out third party is important for privacy reasons.
>
> Stay safe!
>
> 2015-02-02 18:40 GMT+01:00 Brian Erdelyi <brian.erdelyi at gmail.com>:
>> Another concept...
>>
>> It should be possible to use multisig wallets to protect against malware. For example, a user could generate a wallet with 3 keys and require a transaction that has been signed by 2 of those keys. One key is placed in cold storage and anther sent to a third-party.
>>
>> It is now possible to generate and sign transactions on the users computer and send this signed transaction to the third-party for the second signature. This now permits the use of out of band transaction verification techniques before the third party signs the transaction and sends to the blockchain.
>>
>> If the third-party is malicious or becomes compromised they would not have the ability to complete transactions as they only have one private key. If the third-party disappeared, the user could use the key in cold storage to sign transactions and send funds to a new wallet.
>>
>> Thoughts?
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming. The Go Parallel Website,
>> sponsored by Intel and developed in partnership with Slashdot Media, is your
>> hub for all things parallel software development, from weekly thought
>> leadership blogs to news, videos, case studies, tutorials and more. Take a
>> look and join the conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 17:29:21

- reply

📅 Original date posted:2015-02-02
📝 Original message:> We're way ahead of you guys ;)
>
> https://www.bitcoinauthenticator.org/ <https://www.bitcoinauthenticator.org/> - does this already, currently in alpha
I’m just late to the party I guess. Thanks for the links.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150202/4adf4d36/attachment.html>

2023-06-07 17:29:20

- reply

📅 Original date posted:2015-02-02
📝 Original message:Transaction initiated and signed on device #1. Transaction is sent to device #2. On device #2 you verify the transaction and if authorized you provide the second signature.
Brian Erdelyi
Sent from my iPhone
> On Feb 2, 2015, at 5:09 PM, Pedro Worcel <pedro at worcel.com> wrote:
>
> Where would you verify that?
>
>> On 2/3/2015 10:03 AM, Brian Erdelyi wrote:
>> Joel,
>>
>> The mobile device should show you the details of the transaction (i.e. amount and bitcoin address). Once you verify this is the intended recipient and amount you approve it on the mobile device. If the address was replaced, you should see this on the mobile device as it won’t match where you were intending to send it. You can then not provide the second signature.
>>
>> Brian Erdelyi
>>
>>> On Feb 2, 2015, at 4:57 PM, Joel Joonatan Kaartinen <joel.kaartinen at gmail.com> wrote:
>>>
>>> If the attacker has your desktop computer but not the mobile that's acting as an independent second factor, how are you then supposed to be able to tell you're not signing the correct transaction on the mobile? If the address was replaced with the attacker's address, it'll look like everything is ok.
>>>
>>> - Joel
>>>
>>> On Mon, Feb 2, 2015 at 9:58 PM, Brian Erdelyi <brian.erdelyi at gmail.com> wrote:
>>>>
>>>> > Confusing or not, the reliance on multiple signatures as offering greater security than single relies on the independence of multiple secrets. If the secrets cannot be shown to retain independence in the envisioned threat scenario (e.g. a user's compromised operating system) then the benefit reduces to making the exploit more difficult to write, which, once written, reduces to no benefit. Yet the user still suffers the reduced utility arising from greater complexity, while being led to believe in a false promise.
>>>>
>>>> Just trying to make sure I understand what you’re saying. Are you eluding to that if two of the three private keys get compromised there is no gain in security? Although the likelihood of this occurring is lower, it is possible.
>>>>
>>>> As more malware targets bitcoins I think the utility is evident. Given how final Bitcoin transactions are, I think it’s worth trying to find methods to help verify those transactions (if a user deems it to be high-risk enough) before the transaction is completed. The balance is trying to devise something that users do not find too burdensome.
>>>>
>>>> Brian Erdelyi
>>>> ------------------------------------------------------------------------------
>>>> Dive into the World of Parallel Programming. The Go Parallel Website,
>>>> sponsored by Intel and developed in partnership with Slashdot Media, is your
>>>> hub for all things parallel software development, from weekly thought
>>>> leadership blogs to news, videos, case studies, tutorials and more. Take a
>>>> look and join the conversation now. http://goparallel.sourceforge.net/
>>>> _______________________________________________
>>>> Bitcoin-development mailing list
>>>> Bitcoin-development at lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming. The Go Parallel Website,
>> sponsored by Intel and developed in partnership with Slashdot Media, is your
>> hub for all things parallel software development, from weekly thought
>> leadership blogs to news, videos, case studies, tutorials and more. Take a
>> look and join the conversation now. http://goparallel.sourceforge.net/
>>
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150202/3d529fe0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2358 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150202/3d529fe0/attachment.p7s>

2023-06-07 17:29:19

- reply

📅 Original date posted:2015-02-02
📝 Original message:> There are a couple of attack vectors to consider:
>
> * The recipient's machine is compromised
> * The sender's machine is compromised
Excellent point of the recipient being compromised.

2023-06-07 17:29:18

- reply

📅 Original date posted:2015-02-02
📝 Original message:Joel,
The mobile device should show you the details of the transaction (i.e. amount and bitcoin address). Once you verify this is the intended recipient and amount you approve it on the mobile device. If the address was replaced, you should see this on the mobile device as it won’t match where you were intending to send it. You can then not provide the second signature.
Brian Erdelyi
> On Feb 2, 2015, at 4:57 PM, Joel Joonatan Kaartinen <joel.kaartinen at gmail.com> wrote:
>
> If the attacker has your desktop computer but not the mobile that's acting as an independent second factor, how are you then supposed to be able to tell you're not signing the correct transaction on the mobile? If the address was replaced with the attacker's address, it'll look like everything is ok.
>
> - Joel
>
> On Mon, Feb 2, 2015 at 9:58 PM, Brian Erdelyi <brian.erdelyi at gmail.com <mailto:brian.erdelyi at gmail.com>> wrote:
>
> > Confusing or not, the reliance on multiple signatures as offering greater security than single relies on the independence of multiple secrets. If the secrets cannot be shown to retain independence in the envisioned threat scenario (e.g. a user's compromised operating system) then the benefit reduces to making the exploit more difficult to write, which, once written, reduces to no benefit. Yet the user still suffers the reduced utility arising from greater complexity, while being led to believe in a false promise.
>
> Just trying to make sure I understand what you’re saying. Are you eluding to that if two of the three private keys get compromised there is no gain in security? Although the likelihood of this occurring is lower, it is possible.
>
> As more malware targets bitcoins I think the utility is evident. Given how final Bitcoin transactions are, I think it’s worth trying to find methods to help verify those transactions (if a user deems it to be high-risk enough) before the transaction is completed. The balance is trying to devise something that users do not find too burdensome.
>
> Brian Erdelyi
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/ <http://goparallel.sourceforge.net/>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net <mailto:Bitcoin-development at lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150202/ed32b523/attachment.html>

2023-06-07 17:29:18

- reply

📅 Original date posted:2015-02-02
📝 Original message:> Confusing or not, the reliance on multiple signatures as offering greater security than single relies on the independence of multiple secrets. If the secrets cannot be shown to retain independence in the envisioned threat scenario (e.g. a user's compromised operating system) then the benefit reduces to making the exploit more difficult to write, which, once written, reduces to no benefit. Yet the user still suffers the reduced utility arising from greater complexity, while being led to believe in a false promise.
Just trying to make sure I understand what you’re saying. Are you eluding to that if two of the three private keys get compromised there is no gain in security? Although the likelihood of this occurring is lower, it is possible.
As more malware targets bitcoins I think the utility is evident. Given how final Bitcoin transactions are, I think it’s worth trying to find methods to help verify those transactions (if a user deems it to be high-risk enough) before the transaction is completed. The balance is trying to devise something that users do not find too burdensome.
Brian Erdelyi

2023-06-07 17:29:17

- reply

📅 Original date posted:2015-02-02
📝 Original message:> Bitcoin Authenticator is a desktop app+mobile app pair. It pairs with your phone over wifi, cloud push, maybe Bluetooth as well. I forget exactly.
>
> It's done in the same way as Lighthouse, so it runs Win/Mac/Linux on desktop and Android on mobile.
>
> It could be adapted to use BitGo as a third party key holder with SMS authenticator relatively easily, I think. We did the bulk of all the needed work last year as part of the bitcoinj multisig work. Then you'd have a server involved, but not a web app.
I really like the concept of Bitcoin Authenticator and think it’s exactly what I was describing (without a third-party).
I think it’s a bit confusing when they describe Bitcoin Authenticator as 2FA. I think it may be more accurate to describe it as out of band transaction verification/signing or dual transaction signing. Regardless, it’s very exciting to see others are thinking about this too.
Brian Erdelyi

2023-06-07 17:29:16

- reply

📅 Original date posted:2015-02-02
📝 Original message:Another concept...
It should be possible to use multisig wallets to protect against malware. For example, a user could generate a wallet with 3 keys and require a transaction that has been signed by 2 of those keys. One key is placed in cold storage and anther sent to a third-party.
It is now possible to generate and sign transactions on the users computer and send this signed transaction to the third-party for the second signature. This now permits the use of out of band transaction verification techniques before the third party signs the transaction and sends to the blockchain.
If the third-party is malicious or becomes compromised they would not have the ability to complete transactions as they only have one private key. If the third-party disappeared, the user could use the key in cold storage to sign transactions and send funds to a new wallet.
Thoughts?

2023-06-07 17:29:15

- reply

📅 Original date posted:2015-02-01
📝 Original message:> BIP70 is quite safe agains MitB. If user copies URL belonging to other
> merchant, he would see the fact after entering it into his wallet
> application. The only problem is, attacker can buy from the same
> merchant with user's money. (sending him different URL) This can be
> mitigated by merchant setting "memo" to the description of the basket
> and some user info (e.g. address to which goods are sent).
I think BIP 70 does a good job at verifying where the payment request came from. I’m not convinced this is the same as verifying the transaction (ideally OOB).
> But if whole computer is compromised, you're already screwed. Trezor
> should help, but I'm not sure if it supports BIP70.
The reason for OOB verification is if the entire computer is compromised. Again, this may only be possible with a trusted intermediary or a web wallet.
Brian Erdelyi

2023-06-07 17:29:14

- reply

📅 Original date posted:2015-02-01
📝 Original message:In online banking, the banks generate account numbers. An attacker cannot generate their own account number and the likelihood of an attacker having the same account number that I am trying to transfer funds to is low and this is why OCRA is effective with online banking.
With Bitcoin, the Bitcoin address is comparable to the recipient’s bank account number. I now see how an an attacker can brute force the bitcoin address with vanitygen. Is there any way to generate an 8 digit number from the bitcoin address that can be used to verify transactions in such a way (possibly with hashing?) that brute forcing a bitcoin address would take longer than a reasonable period of time (say 60 seconds) so a system could time out if a transaction was not completed in that time?
I’ve also looked into BIP70 (Payment Protocol) that claims protection against man-in-the-middle/man-in-the-browser (MitB) based attacks. A common way to protect against this is with out-of-band transaction verification (http://en.wikipedia.org/wiki/Man-in-the-browser#Out-of-band_transaction_verification <http://en.wikipedia.org/wiki/Man-in-the-browser#Out-of-band_transaction_verification>). I see how BIP 70 verifies the payment request, however, is there any way to verify that the transaction signed by the wallet matches the request before it is sent to the blockchain (and how can this support out of band verification)? Perhaps this is something that can only be supported when sending money with web based wallets.
Brian Erdelyi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150201/608c2e89/attachment.html>

2023-06-07 17:29:12

- reply

📅 Original date posted:2015-01-31
📝 Original message:> See vanitygen. Yes, 8 characters can be brute forced.
>
Thank you for this reference. Interesting to see that there is a tool to generate a vanity bitcoin address.
I am still researching viruses that are designed to manipulate a bitcoin address. I suspect they are primitive in that they use a hardcoded rogue bitcoin address as opposed to dynamically generating one.
As a start, this would help protect against malware that uses a static rogue bitcoin address. The next thing would be for the malware to brute-force the legitimate bitcoin address and generate a rogue bitcoin address that would produce the same 8 digit code. Curious to know how long this brute force would take? Or perhaps, before converting to 8 digits there is some other hashing function that is performed.
Brian Erdelyi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150131/88a7c6ef/attachment.html>

2023-06-07 17:29:11

- reply

📅 Original date posted:2015-01-31
📝 Original message:Hello all,
The number of incidents involving malware targeting bitcoin users continues to rise. One category of virus I find particularly nasty is when the bitcoin address you are trying to send money to is modified before the transaction is signed and recorded in the block chain. This behaviour allows the malware to evade two-factor authentication by becoming active only when the bitcoin address is entered. This is very similar to how man-in-the-browser malware attack online banking websites.
Out of band transaction verification/signing is one method used with online banking to help protect against this. This can be done in a variety of ways with SMS, voice, mobile app or even security tokens. This video demonstrates how HSBC uses a security token to verify transactions online. https://www.youtube.com/watch?v=Sh2Iha88agE <https://www.youtube.com/watch?v=Sh2Iha88agE>.
Many Bitcoin wallets and services already use Open Authentication (OATH) based one-time passwords (OTP). Is there any interest (or existing work) in in the Bitcoin community adopting the OATH Challenge-Response Algorithm (OCRA) for verifying transactions?
I know there are other forms of malware, however, I want to get thoughts on this approach as it would involve the use of a decimal representation of the bitcoin address (depending on particular application). In the HSBC example (see YouTube video above), this was the last 8 digits of the recipient’s account number. Would it make sense to convert a bitcoin address to decimal and then truncate to 8 digits for this purpose? I understand that truncating the number in some way only increases the likelihood for collisions… however, would this still be practical or could the malware generate a rogue bitcoin address that would produce the same 8 digits of the legitimate bitcoin address?
Brian Erdelyi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150131/d4aee3b9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150131/d4aee3b9/attachment.sig>