5 ms·

That's a pretty clear description of an attack, thanks. > The honest source code has a change in the author signature I assume we're talking about the scenari

That's a pretty clear description of an attack, thanks. > The honest source code has a change in the author signature I assume we're talking about the scenario where a user has already-installed honest software that has validated the chain, but has been offline for a while? If we were talking about a new entrant, just the fact that users' internet is often controlled by an attacker 50% of the time would probably be enough to trick users into downloading malicious software. If 50% of connections are hijacked, most users would probably not check signatures and so ~50% of them would get malicious software, the users that do check signatures would get honest software 25% of the time, malicious software 25% of the time, and a sig mismatch 50% of the time. There's some bad things that can happen there for any software where security is important. So let's stick to the scenario where the user already has honest software. First I want to comment on the scenario, and then I'll outline a procedure allows the user to determine which is the honest chain. > The honest chain has a large-scale validator drop caused by an outage of AWS US East 1 The outage you mentioned lasted less than 2 hours. But I think we can consider an outage that lasts say, 1 week. Kind of an absurd amount of time for an outage that hits such a huge amount of people, but even a 1 month outage would not give an attacker an opportunity here. And how many validators would drop out in this scenario? 20%? 40%? Any significant percent seems highly unlikely, but let's say it is a 40% drop for 1 week. > The malicious chain has a large-scale validator drop at the same time caused by the malicious validator failing to include re-staking transactions VPoS doesn't do staking, but the equivalent here is that the malicious chain would simply have blocks submitted at longer intervals until the "difficulty" re-adjusts, which would both equivalently indicate fewer validators. > resulting in the malicious validator controlling 51% of the coins on the malicious chain The malicious validator can mint in secret and always control 100% of the coins actively minting on the chain, no? This still doesn't help tho, because the honest chain can be seen to have more active validators than the malicious chain. In a quorum-based system like Casper where the quorum chooses new randomness that determines the next quorum, it could be possible for an attacker to capture the quorum if they currently make up a large minority of the quorum and 40% of the rest of the quorum drops out. They'd have to have to make up at least 30% of the quorum, so that when they stop responding in the honest quorum, the honest quorum only has 30% left (matching their 30%). An attacker could 51% attack the honest chain in this scenario, no need for a separate malicious chain. This is the same in bitcion - if 40% of the hashpower went offline, an attacker with only 30% of the hashpower would turn into an attacker with 50% of the hashpower. VPoS isn't quorum-based, but it would have the same problem if 40% of minters lose access to their coins for a period of time. Am I misunderstanding your scenario here? Seems like the move would be to 51% attack the honest network rather than try to attack a smaller set of nodes that are probably lower value. > there are a lot of missed blocks on the honest chain, so traffic eventually falls back to a different validator to allow the blockchain to progress I'm not sure about other PoS protocols, but in VPoS, there is no "fall back". The block progression simply slows and "difficulty" readjusts over time. The set of validators and how they're chosen wouldn't change. But let me suggest a different attack scenario: let's say the attacker finds, creates, or buys old keys that collectively contain as much coins as the total coins minting honestly (a history attack). No need for an amazon outage. The attacker simply creates a chain from the point where those addresses collectively had as much minting power as the honest chain. After a time, they would capture all the randomness, and could put even more coins to work minting (with the use of stake grinding), which could look like a heavier chain (with more validators) than the honest chain. > The honest chain has blocks validated every 20 seconds (this number pulled from Cardano), which were validated at that rate because honest nodes wouldn't accept a block earlier than the allotted time. The malicious chain has blocks that were all created in a span 20 minutes and signed by staking addresses controlled. It sounds like you mean that the honest chain has one block every 20 seconds, whereas the malicious chain has a potentially unlimited number of blocks per second. Is that what you're saying? I think in every PoS protocol, there is some verifiable time limiation. Yes an attacker could create an alternate chain starting from from 5 years ago in arbitrarily little time. However, they could not create more blocks in their fake 5 years of time than the honest chain did in real 5 years. And nodes obviously won't accept blocks with timestamps significantly in the future. Protocols have adjustments made when blocks have timestamps that are too close together, just like bitcoin. Any attacker that creates a chain with timestamps too close together will reduce their ability to create blocks proportionately. But maybe you could clarify what you mean here. In any case, to answer your primary question, this is a process that could happen: 1. User downloads honest software in 2021 and runs it continuously and/or regularly. 2. The user shuts down their software in 2022 and gets hit by a car and goes into a coma or something. 3. The user wakes up in 2026 and of course the first thing they do is start up their computer along with the currency software. 4. The software tells the user its been disconnected from the chain for too long and needs a new checkpoint. 5. The user goes to the website they're used to and downloads a new checkpoint and a signature for it (or ideally a battery of signatures). 6. The user uploads the checkpoint and signature(s) into the software. The software checks the signatures against the checkpoint and against its list of trusted public keys. Let's say none match. 7. So the user scours the internet and finds many (honest) articles that talk about how the dev group had a big change up and all the signatures are expected to be created with different keys now. 8. So the user goes and finds some new public keys to validate against. Chances are they go to a search engine and search a few places for keys. There's a 50% chance that they land on a malicious page, and they'll probably keep using that same page for subsequent searches. So 50% chance they get public keys from the attacker. If they're ultra careful, they could start a new web page (and connection) for each search and so only have a 50% chance of getting a malicious public key for each key - but lets just say they don't do that and so 50% of the users just get malicious keys. 9. The user puts in these keys and 50% of the time they match. In the case they don't match, an alarm is raised and they're alerted to the fact that they're possibly being scammed/attacked. 25% of users get malicious keys that matched the checkpoint data. 10. The software then connects to the network. While normally the software might use 8 connections like bitcoin does (tho double that is probably warranted), just for this case of validating the checkpoint, many more connections can be used. 100 wouldn't be very burdensome on the network, but would make it incredibly unlikely that a user would be eclipsed. Again 50% of these connections would be redirected to malicious nodes. Let's also say the attacker has a 50% Sybil in the network, so that even connections that aren't redirected by the attacker may still end up connecting to an attacker. So this is a 75% chance of connecting to an attacker. This results in a .75^100 chance that all their connections are to an attacker. If every person in the world tried to reconnect an old node during the attack window, there would be a probability of less than 0.3% that even a single person gets eclipsed. 11. The software asks these connections what their checkpoint is. If any don't match, an alarm is raised and the user is told they may be being attacked and told to verify out of band what the checkpoint is. Continued...

billytetrud 5y ago
... So all said and told here, any given user trying to reconnect after a long time during the attack window has a 3 in 10 trillion chance of being successfully duped without an alarm being raised. And those aren't the only fractions at play. The number of users trying to reconnect after a long time during the attack window is probably pretty tiny as well. In any case, the one item up there that opens up a further attack opportunity is item 11. An attacker could create malcious public nodes that act like honest nodes until they're asked what their snapshot is by a new connection. When asked, they give some nonsense snapshot hash. A small number of public nodes could cause a bit of chaos. But that chaos could only affect applicable reconnecting nodes that would need to go through the above process. So what nodes are those exactly? Well, the attack is only cheaper than a normal 51% attack when the attacker can obtain old addresses that used to contain coins cheaper than they can contain actual coins. In VPoS, the randomness that decides who can mint is hidden for a period of time and is afterward active for a period of time. If the period of time that the randomness is hidden for is longer than the frequency at which new checkpoints are released. A 1 year timespan seems reasonable for both. So because that possibility can be closed off, the other history attack possible is a longer-range history attack from before the checkpoint - which requires tricking users into accepting a malicious checkpoint. So the attacker might attempt to obtain addresses that contained coins a year ago (but no longer do). However, the only nodes that could even potentially fall for this trick are ones that have been offline for over a year. How many nodes go offline for that long? Probably almost none. But whatever that number is: that's the number that must go through the above process and that's the number that could be griefed by a malicious actor that releases fake data in step 11 above. These steps do hinge on "raising an alarm" being sufficient to prompt people to do some deeper digging as to what chain is the right one. This could be as easy as calling up some trusted friends and asking them to read out a hash to you from their software. It could be asking the merchants you deal with most often, or your employer. I'd argue that similar steps to the above would be incredibly valuable to add to the bitcoin software upon update, since similar issues can happen if you install malicious softare (worse issues really). There are also other mitigations that wouldn't stop an immediate attack, but would help prevent the attack from scamming a user for a long period of time. If successful, the attacker could simply mirror all transactions from the normal chain on their malicious chain. So the victim could get paid and pay honest people, but the attacker could be paying the victim for things with just fake coins on the malicious chain. However there is an idea that has been discussed before of putting a recent block hash in the transction, so that transctions are pinned to a particular chain and the attacker can't build a malicious chain with honest transactions. If transactions required recent block hashes, the victim would be alterted to the malicious chain as soon as they tried to pay someone honest or get paid by someone honest. But I think there are still some things to clarify, since I may have not correctly understood a couple items in your attack scenario.

billytetrud 5y ago

... So all said and told here, any given user trying to reconnect after a long time during the attack window has a 3 in 10 trillion chance of being successfully duped without an alarm being raised. And those aren't the only fractions at play. The number of users trying to reconnect after a long time during the attack window is probably pretty tiny as well. In any case, the one item up there that opens up a further attack opportunity is item 11. An attacker could create malcious public nodes that act like honest nodes until they're asked what their snapshot is by a new connection. When asked, they give some nonsense snapshot hash. A small number of public nodes could cause a bit of chaos. But that chaos could only affect applicable reconnecting nodes that would need to go through the above process. So what nodes are those exactly? Well, the attack is only cheaper than a normal 51% attack when the attacker can obtain old addresses that used to contain coins cheaper than they can contain actual coins. In VPoS, the randomness that decides who can mint is hidden for a period of time and is afterward active for a period of time. If the period of time that the randomness is hidden for is longer than the frequency at which new checkpoints are released. A 1 year timespan seems reasonable for both. So because that possibility can be closed off, the other history attack possible is a longer-range history attack from before the checkpoint - which requires tricking users into accepting a malicious checkpoint. So the attacker might attempt to obtain addresses that contained coins a year ago (but no longer do). However, the only nodes that could even potentially fall for this trick are ones that have been offline for over a year. How many nodes go offline for that long? Probably almost none. But whatever that number is: that's the number that must go through the above process and that's the number that could be griefed by a malicious actor that releases fake data in step 11 above. These steps do hinge on "raising an alarm" being sufficient to prompt people to do some deeper digging as to what chain is the right one. This could be as easy as calling up some trusted friends and asking them to read out a hash to you from their software. It could be asking the merchants you deal with most often, or your employer. I'd argue that similar steps to the above would be incredibly valuable to add to the bitcoin software upon update, since similar issues can happen if you install malicious softare (worse issues really). There are also other mitigations that wouldn't stop an immediate attack, but would help prevent the attack from scamming a user for a long period of time. If successful, the attacker could simply mirror all transactions from the normal chain on their malicious chain. So the victim could get paid and pay honest people, but the attacker could be paying the victim for things with just fake coins on the malicious chain. However there is an idea that has been discussed before of putting a recent block hash in the transction, so that transctions are pinned to a particular chain and the attacker can't build a malicious chain with honest transactions. If transactions required recent block hashes, the victim would be alterted to the malicious chain as soon as they tried to pay someone honest or get paid by someone honest. But I think there are still some things to clarify, since I may have not correctly understood a couple items in your attack scenario.