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
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.
--
Dive into the World of
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
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 pe...@worcel.com wrote:
Where would you
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
On Feb 2, 2015, at 11:53 AM, Mike Hearn m...@plan99.net wrote:
In sending the first-signed transaction to another for second signature, how
does the first signer authenticate to the second without compromising the
independence of the two factors?
Not sure what you mean. The idea is the
One clarification below.
e
On 02/02/2015 02:54 PM, Eric Voskuil wrote:
On Feb 2, 2015, at 11:53 AM, Mike Hearn wrote:
In sending the first-signed transaction to another for second
signature, how does the first signer authenticate to the second
without compromising the independence of the
On 02/02/2015 11:58 AM, Brian Erdelyi 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
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.
--
Do you have anything that is NOT some web application?
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
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
In sending the first-signed transaction to another for second signature, how
does the first signer authenticate to the second without compromising the
independence of the two factors?
Sent from my iPhone
On Feb 2, 2015, at 10:40 AM, Brian Erdelyi brian.erde...@gmail.com wrote:
Another
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
In sending the first-signed transaction to another for second signature,
how does the first signer authenticate to the second without compromising
the independence of the two factors?
Not sure what you mean. The idea is the second factor displays the
transaction and the user confirms it
I think what he is saying is that there is no point in having three
signatures if they are not segregated in a secure manner. This is to
say, if you use your computer as one factor, and a third party website
as another, but you use the same computer to access the website, there
is no gain in
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
Do you have anything that is NOT some web application?
2015-02-02 18:59 GMT+01:00 Mike Hearn m...@plan99.net:
We're way ahead of you guys ;)
On Mon, Feb 2, 2015 at 6:54 PM, Martin Habovštiak
martin.habovst...@gmail.com wrote:
Good idea. I think this could be even better:
instead of using
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
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
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
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
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)?
No. It cannot be done in the Bitcoin context. Your wallet
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
TREZOR does not support BIP70. I think they planned to work on it after
multi-sig support, which is now done, so I'm hoping that it's next on their
roadmap.
The signing features of BIP70 have (fortunately!) been implemented by
payment processors quite early, before we really have the client side
This video demonstrates how HSBC uses a security token to verify
transactions online. https://www.youtube.com/watch?v=Sh2Iha88agE.
Since it's not very widely used outside of Austria and Germany, this may
be interesting for some: there is a second factor scheme called
cardTAN or chipTAN where
Den 31 jan 2015 23:17 skrev Brian Erdelyi brian.erde...@gmail.com:
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
Den 1 feb 2015 00:05 skrev Brian Erdelyi brian.erde...@gmail.com:
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
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
Den 1 feb 2015 00:37 skrev Natanael natanae...@gmail.com:
To bruteforce 8 decimals, on average you need (10^8)/2 = 50 000 000
tries. log(50M)/log(2) = 25.6 bits of entropy.
Oops. Used the wrong number in the entropy calculation. Add one bit, the
division by 2 wasn't supposed to be used in the
29 matches
Mail list logo
