5 ms·

DDoSCoin: Cryptocurrency with a Malicious Proof-Of-Work [pdf]

81 points by gwern 10y ago

pul 10y ago
Can anyone think of defences not listed in the paper?
- CapacitorSet 10y ago
  I can't think of more defences, but they briefly mention the possibility for websites to mine DDoS coins against themselves and I think it's an interesting perspective. I don't know the algorithms involved in the key exchange well enough, but if they support bulk optimizations like RSA does (it's faster to do thousands of signatures in a single operation, rather than one operation at a time) then the server has a noticeable advantage on clients - to the point where it could drive the difficulty insanely high and make it unprofitable to mine DDoS coins.
  - pul 10y ago
    Making it unprofitable would be the best defense against for-profit ddos attacks IMO. If using a botnet to mine regular coins yields more than ddoscoins the insentive is gone.
- deleted 10y ago
  [deleted]
libeclipse 10y ago
Off topic but I'm interested, what software is used to create these papers? Almost all research papers have the same, very aesthetically pleasing, layout that is hard to recreate.
- hrrsn 10y ago
  LaTeX - https://www.latex-project.org https://www.latex-project.org
- deleted 10y ago
  [deleted]
CapacitorSet 10y ago
Tldr on page 4: * The miner generates a random nonce * It initiates a TLS 1.2 connection to the victim server, and uses the nonce as `client_random` * The server generates an ephemeral public key (eg. using ephemeral DH or ephemeral ECDH), and responds with a 32-byte `server_random` * The server sends its certificate chain as well as its public key, and signs the DH key exchange parameters along with `client-random` and `server-random`. This is the proof of work * The client computes the SHA256 hash of the DH params, the signature and the nonce, and does the usual difficulty check; if it passes, it is used to make a block
sheerun 10y ago
I'm not sure this currency will take off but how about the following: Instead of network paying for DDoSing TLS connection let it pay for relaying TLS connections. The principle of would the same as in DDoSCount, but miners relay connections of certain users until it results in signature of given difficulty. After obtaining such signature, miner would be able to withdraw from user's account certain amount of coins. The probability dictates miners would withdraw randomly from all users.
- CapacitorSet 10y ago
  A bit like Torcoin, basically.
  - detaro 10y ago
    Link to the Torcoin paper, for other people like me who hadn't heard about it: https://petsymposium.org/2014/papers/Ghosh.pdf https://petsymposium.org/2014/papers/Ghosh.pdf
  - chatmasta 10y ago
    Hey, I wrote that :) The big challenge for any kind of decentralized "proof of bandwidth" scheme is verifiability. How do you know two actors are not colluding to say they are producing bandwidth? Or how do you resolve conflicts when a client thinks he transferred 1gb but the host thinks he transferred 10gb? Our solution was to use a verifiable shuffle, where all relays and clients submit their public keys into a matrix, which the shuffle then transforms into routing paths. The result is that the client gets a "path" (e.g. A tor circuit, but it could be any routing path) that is privately addressable but publicly verifiable. So each node on the path only knows the IP address of its neighbor node, but all nodes on the path can sign bandwidth calculations with a group signature. That said it was two years ago for my senior thesis... hardly a work of art :P I'm still pursuing the ideas in one form or another.
Uptrenda 10y ago
I'm currently working on something similar. It's a blockchain for verifiable exploits against open source software. The idea is that you can represent bug bounties as a series of smart contracts and have exploits run deterministically against a test case within a virtual machine. That way researchers are always guaranteed payment for working exploits and vendors can be forced to release patches on time. I wrote more about the protocol and rational here if anyone is interested: http://roberts.pm/exploit_markets http://roberts.pm/exploit_markets It's still very much in the brain storming phase so any feedback at all is appreciated.
- drvdevd 10y ago
  Very interesting. I need to read up on smart contracts to better understand your post but the first question that comes to mind is: if you use virtual machines to run the code and test the exploits, against which platform(s) would those VMs be built? Would the idea be to standardize on one virtual infrastructure (and therefore class of exploits) or would you allow just about anything? I ask because I can imagine some (or many) PoCs would require hardware and software of a different platform than usual e.g. qemu+x86_64 vs ARM vs MIPS. So, I guess I see a somewhat complex infrastructure problem that this would need to have solved. Perhaps the VM for running the exploit and exploited code in question should be wrapped around the binary that the vendor distributes, with an intention that it be e.g. ELF on x64 Linux 4.x, statically compiled?
  - Uptrenda 10y ago
    True. What I can imagine is that when the smart contract is being setup the vendor chooses a list of templates for the platforms / environments used to setup the virtual machines. If they're running their own software on their own infrastructure they can always provide a scale image that reflects what they intend to run in production. (Thanks for the feedback, by the way. It's hard to stand out for anything these days.)
- uhhyeahdude 10y ago
  That's a fascinating concept, and something akin to what you are proposing is certainly needed in that particular niche. I read the your description page, and agree with most of your points regarding the rationale behind the project. I wonder if you might lose the attention of potential contributors/supporters by the inclusion of an underlying threat of reprisal implied by your wording. You are right about so much, and both industry and "researchers" have much to gain by a model that guarantees payment for work within agreed timeframes, etc... While consumers certainly would benefit from a better patch release process, I'm not so sure you can force a company to ship a patch by a certain date to avoid disclosure; that leads to bad patches, more bugs, and resources devoted to the wrong things. Obviously, this is great for the researcher who understands the bigger picture. One might use the word blackmail. If not blackmail, then it sounds like a great way to abuse bounties in general, and make it easier to take advantage and profit off of the bounty vendor. It could also make "responsible disclosure"/bounties (not conflating, but they are the equivalent of "silver or lead") a more profitable endeavor than less legal activities doing the same thing. advantage of a systemic, nuanced design issue, by reporting a bug that one can exploit via one facet of said systemic issue, iterate, get paid, disclose bug1 (or not), report bug2... Someone will realize what is going on at some point, but the payment/disclosure windows will prevent them from properly fixing the issue. Each patch released to meet the deadline is a potential new attack surface. The inclusion of a paragraph regarding a zero-knowledge exploit market is definitely relevant, and germane, but in in the context of what is ostensibly a proposed method for implementing smart contracts between historically antagonistic parties, it comes off as a threat. Neat project. I harbor no illusions about the ethics of certain prominent entities in this space, and if your project helps make it so that ethics are not necessary for a decent system to exist, then you have done something good.

81 points by gwern 10y ago

pul 10y ago

Can anyone think of defences not listed in the paper?

CapacitorSet 10y ago
I can't think of more defences, but they briefly mention the possibility for websites to mine DDoS coins against themselves and I think it's an interesting perspective. I don't know the algorithms involved in the key exchange well enough, but if they support bulk optimizations like RSA does (it's faster to do thousands of signatures in a single operation, rather than one operation at a time) then the server has a noticeable advantage on clients - to the point where it could drive the difficulty insanely high and make it unprofitable to mine DDoS coins.
- pul 10y ago
  Making it unprofitable would be the best defense against for-profit ddos attacks IMO. If using a botnet to mine regular coins yields more than ddoscoins the insentive is gone.
deleted 10y ago
[deleted]

libeclipse 10y ago

Off topic but I'm interested, what software is used to create these papers? Almost all research papers have the same, very aesthetically pleasing, layout that is hard to recreate.

hrrsn 10y ago
LaTeX - https://www.latex-project.org https://www.latex-project.org
deleted 10y ago
[deleted]

CapacitorSet 10y ago

Tldr on page 4: * The miner generates a random nonce * It initiates a TLS 1.2 connection to the victim server, and uses the nonce as `client_random` * The server generates an ephemeral public key (eg. using ephemeral DH or ephemeral ECDH), and responds with a 32-byte `server_random` * The server sends its certificate chain as well as its public key, and signs the DH key exchange parameters along with `client-random` and `server-random`. This is the proof of work * The client computes the SHA256 hash of the DH params, the signature and the nonce, and does the usual difficulty check; if it passes, it is used to make a block

sheerun 10y ago

I'm not sure this currency will take off but how about the following: Instead of network paying for DDoSing TLS connection let it pay for relaying TLS connections. The principle of would the same as in DDoSCount, but miners relay connections of certain users until it results in signature of given difficulty. After obtaining such signature, miner would be able to withdraw from user's account certain amount of coins. The probability dictates miners would withdraw randomly from all users.

CapacitorSet 10y ago
A bit like Torcoin, basically.
- detaro 10y ago
  Link to the Torcoin paper, for other people like me who hadn't heard about it: https://petsymposium.org/2014/papers/Ghosh.pdf https://petsymposium.org/2014/papers/Ghosh.pdf
- chatmasta 10y ago
  Hey, I wrote that :) The big challenge for any kind of decentralized "proof of bandwidth" scheme is verifiability. How do you know two actors are not colluding to say they are producing bandwidth? Or how do you resolve conflicts when a client thinks he transferred 1gb but the host thinks he transferred 10gb? Our solution was to use a verifiable shuffle, where all relays and clients submit their public keys into a matrix, which the shuffle then transforms into routing paths. The result is that the client gets a "path" (e.g. A tor circuit, but it could be any routing path) that is privately addressable but publicly verifiable. So each node on the path only knows the IP address of its neighbor node, but all nodes on the path can sign bandwidth calculations with a group signature. That said it was two years ago for my senior thesis... hardly a work of art :P I'm still pursuing the ideas in one form or another.

Uptrenda 10y ago

I'm currently working on something similar. It's a blockchain for verifiable exploits against open source software. The idea is that you can represent bug bounties as a series of smart contracts and have exploits run deterministically against a test case within a virtual machine. That way researchers are always guaranteed payment for working exploits and vendors can be forced to release patches on time. I wrote more about the protocol and rational here if anyone is interested: http://roberts.pm/exploit_markets http://roberts.pm/exploit_markets It's still very much in the brain storming phase so any feedback at all is appreciated.

drvdevd 10y ago
Very interesting. I need to read up on smart contracts to better understand your post but the first question that comes to mind is: if you use virtual machines to run the code and test the exploits, against which platform(s) would those VMs be built? Would the idea be to standardize on one virtual infrastructure (and therefore class of exploits) or would you allow just about anything? I ask because I can imagine some (or many) PoCs would require hardware and software of a different platform than usual e.g. qemu+x86_64 vs ARM vs MIPS. So, I guess I see a somewhat complex infrastructure problem that this would need to have solved. Perhaps the VM for running the exploit and exploited code in question should be wrapped around the binary that the vendor distributes, with an intention that it be e.g. ELF on x64 Linux 4.x, statically compiled?
- Uptrenda 10y ago
  True. What I can imagine is that when the smart contract is being setup the vendor chooses a list of templates for the platforms / environments used to setup the virtual machines. If they're running their own software on their own infrastructure they can always provide a scale image that reflects what they intend to run in production. (Thanks for the feedback, by the way. It's hard to stand out for anything these days.)
uhhyeahdude 10y ago
That's a fascinating concept, and something akin to what you are proposing is certainly needed in that particular niche. I read the your description page, and agree with most of your points regarding the rationale behind the project. I wonder if you might lose the attention of potential contributors/supporters by the inclusion of an underlying threat of reprisal implied by your wording. You are right about so much, and both industry and "researchers" have much to gain by a model that guarantees payment for work within agreed timeframes, etc... While consumers certainly would benefit from a better patch release process, I'm not so sure you can force a company to ship a patch by a certain date to avoid disclosure; that leads to bad patches, more bugs, and resources devoted to the wrong things. Obviously, this is great for the researcher who understands the bigger picture. One might use the word blackmail. If not blackmail, then it sounds like a great way to abuse bounties in general, and make it easier to take advantage and profit off of the bounty vendor. It could also make "responsible disclosure"/bounties (not conflating, but they are the equivalent of "silver or lead") a more profitable endeavor than less legal activities doing the same thing. advantage of a systemic, nuanced design issue, by reporting a bug that one can exploit via one facet of said systemic issue, iterate, get paid, disclose bug1 (or not), report bug2... Someone will realize what is going on at some point, but the payment/disclosure windows will prevent them from properly fixing the issue. Each patch released to meet the deadline is a potential new attack surface. The inclusion of a paragraph regarding a zero-knowledge exploit market is definitely relevant, and germane, but in in the context of what is ostensibly a proposed method for implementing smart contracts between historically antagonistic parties, it comes off as a threat. Neat project. I harbor no illusions about the ethics of certain prominent entities in this space, and if your project helps make it so that ethics are not necessary for a decent system to exist, then you have done something good.