* [Bitcoin-development] Blitcoin? (Black Hat 2011) @ 2011-08-04 10:56 John Smith 2011-08-04 14:14 ` Matt Corallo 2011-08-04 14:38 ` Luke-Jr 0 siblings, 2 replies; 12+ messages in thread From: John Smith @ 2011-08-04 10:56 UTC (permalink / raw) To: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 505 bytes --] L.S. Some bitcoin "security vulnerabilities" have been discussed by Dan Kaminsky at BH 2011, there is one article about this dated yesterday: http://searchsecurity.techtarget.com/news/2240039221/Black-Hat-2011-Dan-Kaminsky-reveals-network-security-research-topics The article is very unspecific though. They talk about a tool called "blitcoin" that "unmasks" both sides of a bitcoin transaction. A google search also turned up nothing, except some misspellings. Does anyone have more information? JS [-- Attachment #2: Type: text/html, Size: 711 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bitcoin-development] Blitcoin? (Black Hat 2011) 2011-08-04 10:56 [Bitcoin-development] Blitcoin? (Black Hat 2011) John Smith @ 2011-08-04 14:14 ` Matt Corallo 2011-08-04 14:38 ` Luke-Jr 1 sibling, 0 replies; 12+ messages in thread From: Matt Corallo @ 2011-08-04 14:14 UTC (permalink / raw) To: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 919 bytes --] Sounds like Dan wrote a tool which attempts to connect inputs/outputs and make a map of a person on the network, or at least thats my blind guess. Something people have been saying was easily possible for some time, but for some reason people insist on refusing their precious Bitcoin isnt anonymous. Matt On Thu, 2011-08-04 at 10:56 +0000, John Smith wrote: > L.S. > > Some bitcoin "security vulnerabilities" have been discussed by Dan > Kaminsky at BH 2011, there is one article about this dated yesterday: > > http://searchsecurity.techtarget.com/news/2240039221/Black-Hat-2011-Dan-Kaminsky-reveals-network-security-research-topics > > The article is very unspecific though. They talk about a tool called > "blitcoin" that "unmasks" both sides of a bitcoin transaction. A > google search also turned up nothing, except some misspellings. > > Does anyone have more information? > > JS [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bitcoin-development] Blitcoin? (Black Hat 2011) 2011-08-04 10:56 [Bitcoin-development] Blitcoin? (Black Hat 2011) John Smith 2011-08-04 14:14 ` Matt Corallo @ 2011-08-04 14:38 ` Luke-Jr 2011-08-05 1:16 ` Gavin Andresen 1 sibling, 1 reply; 12+ messages in thread From: Luke-Jr @ 2011-08-04 14:38 UTC (permalink / raw) To: bitcoin-development On Thursday, August 04, 2011 6:56:42 AM John Smith wrote: > L.S. > > Some bitcoin "security vulnerabilities" have been discussed by Dan Kaminsky > at BH 2011, there is one article about this dated yesterday: > > http://searchsecurity.techtarget.com/news/2240039221/Black-Hat-2011-Dan-Kam > insky-reveals-network-security-research-topics > > The article is very unspecific though. They talk about a tool called > "blitcoin" that "unmasks" both sides of a bitcoin transaction. A google > search also turned up nothing, except some misspellings. Well, that certainly doesn't sound like a security vulnerability at all. It's by design that everyone knows about every transaction. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bitcoin-development] Blitcoin? (Black Hat 2011) 2011-08-04 14:38 ` Luke-Jr @ 2011-08-05 1:16 ` Gavin Andresen 2011-08-05 5:37 ` John Smith 2011-08-05 13:07 ` Andy Parkins 0 siblings, 2 replies; 12+ messages in thread From: Gavin Andresen @ 2011-08-05 1:16 UTC (permalink / raw) To: Luke-Jr; +Cc: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 1128 bytes --] Dan gave a brief explanation of "blitcoin" on the forums: https://bitcointalk.org/index.php?topic=34458.0 "As reported, I've got a BitCoin deanonymization mechanism. It's not complicated. Connect to every node in the cloud, discoverable via sweeping/IRC/get_peers messages. The first IP to consistently relay transactions for a given identity, is the given identity. Of course the entire BitCoin cloud doesn't allow inbound connections (although you can do rather evil stuff with UPNP to force that open too). But this isn't a problem -- there's only about 3000 to 8000 IPs that are BitCoin nodes that accept inbound connections. Since everyone else depends on them, you just need to create your own mass cluster of IPs that are a decent chunk of the P2P network. Nodes on average have seven outbound connections, so it should take only a few hundred unique to be one of the first-hop peers even for the outbound-only set." ... so it is a de-anonymize-via IP address not de-anonymize-via Bitcoin address. And might go partway to explaining why we're having trouble with network connectivity... -- -- Gavin Andresen [-- Attachment #2: Type: text/html, Size: 2216 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bitcoin-development] Blitcoin? (Black Hat 2011) 2011-08-05 1:16 ` Gavin Andresen @ 2011-08-05 5:37 ` John Smith 2011-08-05 5:52 ` Jeff Garzik 2011-08-05 5:55 ` John Smith 2011-08-05 13:07 ` Andy Parkins 1 sibling, 2 replies; 12+ messages in thread From: John Smith @ 2011-08-05 5:37 UTC (permalink / raw) To: Gavin Andresen; +Cc: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 1310 bytes --] On Fri, Aug 5, 2011 at 1:16 AM, Gavin Andresen <gavinandresen@gmail•com>wrote: > > ... so it is a de-anonymize-via IP address not de-anonymize-via Bitcoin > address. And might go partway to explaining why we're having trouble with > network connectivity... > Well it's good that the bitcoin network is seeing some security testing. So I understand that we have a combination of problems at the moment: 1) A DDoS possibility (if this is really the cause of the network connectivity problems) 2) An attacker can figure out which node first broadcasted a transaction, by connecting to the entire network or having everyone connect to his node(s) 3) The recipient re-broadcasts transactions (is Theymos right here?), allowing both the sender and recipient to be found Drawok's suggestion about using UDP packets with spoofed sender addresses is interesting, as UDP has another advantage; you can open up an "inbound" UDP port on almost any NAT router without any UPNP magic: just send out an UDP packet, the router will wait a certain time for answers (on a mapped port number) and relay these back. It also has some potential issues; the client needs special privileges to spoof sender addresses, and some ISPs might filter out packets with non-matching sender addriess (unsure how common this is). JS [-- Attachment #2: Type: text/html, Size: 1720 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bitcoin-development] Blitcoin? (Black Hat 2011) 2011-08-05 5:37 ` John Smith @ 2011-08-05 5:52 ` Jeff Garzik 2011-08-05 12:01 ` Joel Joonatan Kaartinen 2011-08-05 5:55 ` John Smith 1 sibling, 1 reply; 12+ messages in thread From: Jeff Garzik @ 2011-08-05 5:52 UTC (permalink / raw) To: John Smith; +Cc: bitcoin-development On Fri, Aug 5, 2011 at 1:37 AM, John Smith <witchspace81@gmail•com> wrote: > Well it's good that the bitcoin network is seeing some security testing. Yep. > 1) A DDoS possibility (if this is really the cause of the network > connectivity problems) Unfortunately the nodes accepting incoming connections are small enough in number (7000?) that you can shut down a lot by attacking those nodes. This was part of the motivation of turning on upnp by default in the GUI version, but maybe we need to go further than that... > 3) The recipient re-broadcasts transactions (is Theymos right here?), > allowing both the sender and recipient to be found Yes, that is correct. Bitcoin resends wallet transactions with zero confirmations, and both sent and received transactions fall within the "wallet tx" superset. TBH I had forgotten about the resend on the receiver side, though. It, of course, makes plenty of sense in the context of importing transactions from foreign sources, e.g. receiving transactions via a USB flash drive. > Drawok's suggestion about using UDP packets with spoofed sender addresses is > interesting, as UDP has another advantage; you can open up an "inbound" UDP > port on almost any NAT router without any UPNP magic: just send out an UDP > packet, the router will wait a certain time for answers (on a mapped port > number) and relay these back. > > It also has some potential issues; the client needs special privileges to > spoof sender addresses, and some ISPs might filter out packets with > non-matching sender addriess (unsure how common this is). Well, it -is- possible to implement TCP over UDP <grin> The TCP connection sequence over UDP helps to work against spoofing, while UDP helps to open an inbound UDP port as you describe. Not that I'm endorsing a bitcoin-internal TCP stack... just sayin' :) -- Jeff Garzik exMULTI, Inc. jgarzik@exmulti•com ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bitcoin-development] Blitcoin? (Black Hat 2011) 2011-08-05 5:52 ` Jeff Garzik @ 2011-08-05 12:01 ` Joel Joonatan Kaartinen 2011-08-05 12:58 ` Christian Decker 0 siblings, 1 reply; 12+ messages in thread From: Joel Joonatan Kaartinen @ 2011-08-05 12:01 UTC (permalink / raw) To: Jeff Garzik; +Cc: bitcoin-development On Fri, 2011-08-05 at 01:52 -0400, Jeff Garzik wrote: > Yes, that is correct. Bitcoin resends wallet transactions with zero > confirmations, and both sent and received transactions fall within the > "wallet tx" superset. > > TBH I had forgotten about the resend on the receiver side, though. > It, of course, makes plenty of sense in the context of importing > transactions from foreign sources, e.g. receiving transactions via a > USB flash drive. Could every node do the resends? Alternatively, could we implement a TOR like tunneling system just for the first leg of the transactions (overkill?). Then again, maybe just a TOR gateway if that's desired. > > Drawok's suggestion about using UDP packets with spoofed sender addresses is > > interesting, as UDP has another advantage; you can open up an "inbound" UDP > > port on almost any NAT router without any UPNP magic: just send out an UDP > > packet, the router will wait a certain time for answers (on a mapped port > > number) and relay these back. This is a nice idea but sounds rather unreliable. > Well, it -is- possible to implement TCP over UDP <grin> The TCP > connection sequence over UDP helps to work against spoofing, while UDP > helps to open an inbound UDP port as you describe. There's already an implementation of this, called UTP. If we do decide that using UDP is worthwhile, this library is probably better than implementing something ourselves. - Joel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bitcoin-development] Blitcoin? (Black Hat 2011) 2011-08-05 12:01 ` Joel Joonatan Kaartinen @ 2011-08-05 12:58 ` Christian Decker 2011-08-05 13:11 ` John Smith 0 siblings, 1 reply; 12+ messages in thread From: Christian Decker @ 2011-08-05 12:58 UTC (permalink / raw) To: Bitcoin Development [-- Attachment #1: Type: text/plain, Size: 2901 bytes --] While I do think that anonymity (or pseudonymity) is a nice feature, I don't think it deserves the full focus of the developers. The core of the protocol is about making transactions in a secure and fast way, not allowing everybody to be anonymous, whether they want to or not. TOR already is a good options for those that want to stay anonymous, and there is no need to pull support into the main client, if only a few will use it. I think very few of the developers actually claimed that Bitcoin is anonymous, and has never been a big advertising point from the "official" side of Bitcoin, network analysis has been always known to break anonymity. I see no need for action from the developer side. -cdecker On Fri, Aug 5, 2011 at 2:01 PM, Joel Joonatan Kaartinen < joel.kaartinen@gmail•com> wrote: > On Fri, 2011-08-05 at 01:52 -0400, Jeff Garzik wrote: > > Yes, that is correct. Bitcoin resends wallet transactions with zero > > confirmations, and both sent and received transactions fall within the > > "wallet tx" superset. > > > > TBH I had forgotten about the resend on the receiver side, though. > > It, of course, makes plenty of sense in the context of importing > > transactions from foreign sources, e.g. receiving transactions via a > > USB flash drive. > > Could every node do the resends? Alternatively, could we implement a TOR > like tunneling system just for the first leg of the transactions > (overkill?). Then again, maybe just a TOR gateway if that's desired. > > > > Drawok's suggestion about using UDP packets with spoofed sender > addresses is > > > interesting, as UDP has another advantage; you can open up an "inbound" > UDP > > > port on almost any NAT router without any UPNP magic: just send out an > UDP > > > packet, the router will wait a certain time for answers (on a mapped > port > > > number) and relay these back. > > This is a nice idea but sounds rather unreliable. > > > Well, it -is- possible to implement TCP over UDP <grin> The TCP > > connection sequence over UDP helps to work against spoofing, while UDP > > helps to open an inbound UDP port as you describe. > > There's already an implementation of this, called UTP. If we do decide > that using UDP is worthwhile, this library is probably better than > implementing something ourselves. > > - Joel > > > > > ------------------------------------------------------------------------------ > BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA > The must-attend event for mobile developers. Connect with experts. > Get tools for creating Super Apps. See the latest technologies. > Sessions, hands-on labs, demos & much more. Register early & save! > http://p.sf.net/sfu/rim-blackberry-1 > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > [-- Attachment #2: Type: text/html, Size: 3776 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bitcoin-development] Blitcoin? (Black Hat 2011) 2011-08-05 12:58 ` Christian Decker @ 2011-08-05 13:11 ` John Smith 0 siblings, 0 replies; 12+ messages in thread From: John Smith @ 2011-08-05 13:11 UTC (permalink / raw) To: Christian Decker; +Cc: Bitcoin Development [-- Attachment #1: Type: text/plain, Size: 1325 bytes --] On Fri, Aug 5, 2011 at 12:58 PM, Christian Decker < decker.christian@gmail•com> wrote: > While I do think that anonymity (or pseudonymity) is a nice feature, I > don't think it deserves the full focus of the developers. The core of the > protocol is about making transactions in a secure and fast way, not allowing > everybody to be anonymous, whether they want to or not. TOR already is a > good options for those that want to stay anonymous, and there is no need to > pull support into the main client, if only a few will use it. I think very > few of the developers actually claimed that Bitcoin is anonymous, and has > never been a big advertising point from the "official" side of Bitcoin, > network analysis has been always known to break anonymity. > Yes. Optionally layering Bitcoin over Tor/I2P is a much better option than trying to replicate an onion network in Bitcoin itself. For one, traffic analysis is much more difficult if your onion routing network contains multiple kinds of traffic. Also it would complicate the core algorithm and waste developer time. Doing anonymity *right* is very hard. So let's leave it to the Tor/I2P people that know what they're doing. > > I see no need for action from the developer side. > Except the part about making the client/network more resistant against DDoS. JS [-- Attachment #2: Type: text/html, Size: 1761 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bitcoin-development] Blitcoin? (Black Hat 2011) 2011-08-05 5:37 ` John Smith 2011-08-05 5:52 ` Jeff Garzik @ 2011-08-05 5:55 ` John Smith 1 sibling, 0 replies; 12+ messages in thread From: John Smith @ 2011-08-05 5:55 UTC (permalink / raw) To: Gavin Andresen; +Cc: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 510 bytes --] > 3) The recipient re-broadcasts transactions (is Theymos right here?), > allowing both the sender and recipient to be found > Hm this would potentially allow getting the IP for any recipient Bitcoin address, given that a client with the private key connects to the network once in a while. Send them a transaction that is guaranteed to not be written into a block by a miner, then monitor who rebroadcasts it over a few days/weeks. I guess this could also be used to find out who has the stolen coins. JS [-- Attachment #2: Type: text/html, Size: 746 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bitcoin-development] Blitcoin? (Black Hat 2011) 2011-08-05 1:16 ` Gavin Andresen 2011-08-05 5:37 ` John Smith @ 2011-08-05 13:07 ` Andy Parkins 2011-08-05 13:19 ` John Smith 1 sibling, 1 reply; 12+ messages in thread From: Andy Parkins @ 2011-08-05 13:07 UTC (permalink / raw) To: bitcoin-development [-- Attachment #1: Type: Text/Plain, Size: 800 bytes --] On 2011 August 05 Friday, Gavin Andresen wrote: > "As reported, I've got a BitCoin deanonymization mechanism. It's not > complicated. > > Connect to every node in the cloud, discoverable via sweeping/IRC/get_peers > messages. The first IP to consistently relay transactions for a given > identity, is the given identity. Transaction forwarding could be randomised slightly, by randomising the outgoing relay order; and adding a random delay between each forward. Even the massively connected monitor can't represent _all_ the connections on every real node, so it would have no way of knowing whether it got any transaction from the originator or because it got a fast path through the first N nodes to receive it. Andy -- Dr Andy Parkins andyparkins@gmail•com [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bitcoin-development] Blitcoin? (Black Hat 2011) 2011-08-05 13:07 ` Andy Parkins @ 2011-08-05 13:19 ` John Smith 0 siblings, 0 replies; 12+ messages in thread From: John Smith @ 2011-08-05 13:19 UTC (permalink / raw) To: Andy Parkins; +Cc: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 772 bytes --] On Fri, Aug 5, 2011 at 1:07 PM, Andy Parkins <andyparkins@gmail•com> wrote: > On 2011 August 05 Friday, Gavin Andresen wrote: > > Transaction forwarding could be randomised slightly, by randomising the > outgoing relay order; and adding a random delay between each forward. Even > the massively connected monitor can't represent _all_ the connections on > every > real node, so it would have no way of knowing whether it got any > transaction > from the originator or because it got a fast path through the first N nodes > to > receive it. > Right, while it doesn't warrant completely changing the transport protocol to UDP or implementing onion routing, I'm all for simple timing and order randomization changes if they can make attacks like this less effective. JS [-- Attachment #2: Type: text/html, Size: 1089 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2011-08-05 13:19 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-08-04 10:56 [Bitcoin-development] Blitcoin? (Black Hat 2011) John Smith 2011-08-04 14:14 ` Matt Corallo 2011-08-04 14:38 ` Luke-Jr 2011-08-05 1:16 ` Gavin Andresen 2011-08-05 5:37 ` John Smith 2011-08-05 5:52 ` Jeff Garzik 2011-08-05 12:01 ` Joel Joonatan Kaartinen 2011-08-05 12:58 ` Christian Decker 2011-08-05 13:11 ` John Smith 2011-08-05 5:55 ` John Smith 2011-08-05 13:07 ` Andy Parkins 2011-08-05 13:19 ` John Smith
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox