BGP hijacks Live Bitcoin News

A few stories about Brian Krebs: The independent cybercrime journalist who exposes criminals on the internet

First, a bit of introduction before we get into the living drama that is Brian Krebs.
Brian Krebs has been a journalist for decades, starting in the late 90s. He got his start at The Washington Post, but what he's most famous for are his exposes on criminal businesses and individuals who perpetuate cyber crime worldwide. In 2001, he got his interest in cybercrime piqued when a computer worm locked him out of his own computer. In 2005, he shifted from working as a staff writer at The Washington Post's tech newswire to writing for their security blog, "Security Wire". During his tenure there, he started by focusing on the victims of cybercrime, but later also started to focus on the perpetrators of it as well. His reporting helped lead to the shutdown of McColo, a hosting provider who provided service to some of the world's biggest spammers and hackers. Reports analyzing the shutdown of McColo estimated that global spam volume dropped by between 40 and 70 percent. Further analysis revealed it also played host to child pornography sites, and the Russian Business Network, a major Russian cybercrime ring.
In 2009, Krebs left to start his own site, KrebsOnSecurity. Since then, he's been credited with being the first to report on major events such as Stuxnet and when Target was breached, resulting in the leakage of 40 million cards. He also regularly investigates and reveals criminals' identities on his site. The latter has made him the bane of the world of cybercrime, as well as basically a meme, where criminals will include references like Made by Brian Krebs in their code, or name their shops full of stolen credit cards after him.
One of his first posts on his new site was a selection of his best work. While not particularly dramatic, they serve as an excellent example of dogged investigative work, and his series reveal the trail of takedowns his work has documented, or even contributed to.
And now, a selection of drama involving Krebs. Note, all posts are sarcastically-tinged retellings of the source material which I will link throughout. I also didn't use the real names in my retellings, but they are in the source material. This took way too long to write, and it still does massively condense the events described in the series. Krebs has been involved with feuds with other figures, but I'd argue these tales are the "main" bits of drama that are most suited for here.

Fly on the Wall

By 2013, Krebs was no stranger to cybercriminals taking the fight to the real world. He was swatted previously to the point where the police actually know to give him a ring and see if there'd actually been a murder, or if it was just those wacky hackers at it again. In addition, his identity was basically common knowledge to cybercriminals, who would open lines of credit in his name, or find ways to send him money using stolen credit cards.
However, one particular campaign against him caught his eye. A hacker known as "Fly" aka "Flycracker" aka "MUXACC1" posted on a Russian-language fraud forum he administered about a "Krebs fund". His plan was simple. Raise Bitcoin to buy Heroin off of a darknet marketplace, address it to Krebs, and alert his local police via a spoofed phone call. Now, because Krebs is an investigative journalist, he develops undercover presences on cybercrime forums, and it just so happened he'd built up a presence on this one already.
Guys, it became known recently that Brian Krebs is a heroin addict and he desperately needs the smack, so we have started the "Helping Brian Fund", and shortly we will create a bitcoin wallet called "Drugs for Krebs" which we will use to buy him the purest heroin on the Silk Road. My friends, his withdrawal is very bad, let’s join forces to help the guy! We will save Brian from the acute heroin withdrawal and the world will get slightly better!
Fly had first caught Krebs' attention by taunting him on Twitter, sending him Tweets including insults and abuse, and totally-legit looking links. Probably either laced with malware, or designed to get Krebs' IP. He also took to posting personal details such as Krebs' credit report, directions to his house, and pictures of his front door on LiveJournal, of all places.
So, after spotting the scheme, he alerted his local police that he'd probably have someone sending him some China White. Sure enough, the ne'er-do-wells managed to raise 2 BTC, which at the time was a cool $200 or so. They created an account on the premiere darknet site at the time, The Silk Road under the foolproof name "briankrebs7". They found one seller who had consistently high reviews, but the deal fell through for unknown reasons. My personal theory is the seller decided to Google where it was going, and realized sending a gram of dope into the waiting arms of local law enforcement probably wasn't the best use of his time. Still, the forum members persevered, and found another seller who was running a buy 10 get 2 free promotion. $165 of Bitcoin later, the drugs were on their way to a new home. The seller apparently informed Fly that the shipment should arrive by Tuesday, a fact which he gleefully shared with the forum.
While our intrepid hero had no doubt that the forum members were determined to help him grab the tail of the dragon, he's not one to assume without confirmation, and enlisted the help of a graduate student at UCSD who was researching Bitcoin and anonymity on The Silk Road, and confirmed the address shared by Fly was used to deposit 2 BTC into an account known to be used for money management on the site.
By Monday, an envelope from Chicago had arrived, containing a copy of Chicago confidential. Taped inside were tiny baggies filled with the purported heroin. Either dedicated to satisfied customers, or mathematically challenged, the seller had included thirteen baggies instead of the twelve advertised. A police officer arrived to take a report and whisked the baggies away.
Now, Fly was upset that Krebs wasn't in handcuffs for drug possession, and decided to follow up his stunt by sending Krebs a floral arrangement shaped like a cross, and an accompanying threatening message addressed to his wife, the dire tone slightly undercut by the fact that it was signed "Velvet Crabs". Krebs' curiosity was already piqued from the shenanigans with the heroin, but with the arrival of the flowers decided to dive deeper into the сука behind things.
He began digging into databases from carding sites that had been hacked, but got his first major breakthrough to his identity from a Russian computer forensics firm. Fly had maintained an account on a now-defunct hacking forum, whose database was breached under "Flycracker". It turns out, the email Flycracker had used was also hacked at some point, and a source told Krebs that the email was full of reports from a keylogger Fly had installed on his wife's computer. Now, because presumably his wife wasn't part of, or perhaps even privy to her husband's illicit dealings, her email account happened to be her full legal name, which Krebs was able to trace to her husband. Now, around this time, the site Fly maintained disappeared from the web, and administrators on another major fraud forum started purging his account. This is a step they typically take when they suspect a member has been apprehended by authorities. Nobody knew for sure, but they didn't want to take any chances.
More research by Krebs revealed that the criminals' intuition had been correct, and Fly was arrested in Italy, carrying documents under an assumed name. He was sitting in an Italian jail, awaiting potential extradition to the United States, as well as potentially facing charges in Italy. This was relayed to Krebs by a law enforcement official who simply said "The Fly has been swatted". (Presumably while slowly removing a pair of aviator sunglasses)
While Fly may have been put away, the story between Krebs and Fly wasn't quite over. He did end up being extradited to the US for prosecution, but while imprisoned in Italy, Fly actually started sending Krebs letters. Understandably distrustful after the whole "heroin" thing, his contacts in federal law enforcement tested the letter, and found it to be clean. Inside, there was a heartfelt and personal letter, apologizing for fucking with Krebs in so many ways. He also forgave Krebs for posting his identity online, leading him to muse that perhaps Fly was working through a twelve-step program. In December, he received another letter, this time a simple postcard with a cheerful message wishing him a Merry Christmas and a Happy New Year. Krebs concluded his post thusly:
Cybercrooks have done some pretty crazy stuff to me in response to my reporting about them. But I don’t normally get this kind of closure. I look forward to meeting with Fly in person one day soon now that he will be just a short train ride away. And he may be here for some time: If convicted on all charges, Fly faces up to 30 years in U.S. federal prison.
Fly ultimately was extradited. He plead guilty and was sentenced to 41 months in jail

vDOS and Mirai Break The Internet

Criminals are none too happy when they find their businesses and identities on the front page of KrebsOnSecurity. It usually means law enforcement isn't far behind. One such business was known as vDOS. A DDOS-for-hire (also known as a "booter" or a "stresser") site that found itself hacked, with all their customer records still in their databases leaked. Analysis of the records found that in a four-month time span, the service had been responsible for about 8.81 years worth of attack time, meaning on average at any given second, there were 26 simultaneous attacks running. Interestingly, the hack of vDOS came about from another DDOS-for-hire site, who as it turns out was simply reselling services provided by vDOS. They were far from the only one. vDOS appeared to provide firepower to a large number of different resellers.
In addition to the attack logs, support messages were also among the data stolen. This contained some complaints from various clients who complained they were unable to launch attacks against Israeli IPs. This is a common tactic by hackers to try and avoid unwanted attention from authorities in their country of residence. This was confirmed when two men from Israel were arrested for their involvement in owning and running vDOS. However, this was just the beginning for this bit of drama.
The two men arrested went by the handles "applej4ck" and "Raziel". They had recently published a paper on DDOS attack methods in an online Israeli security magazine. Interestingly, on the same day the men were arrested, questioned, and released on bail, vDOS went offline. Not because it had been taken down by Israeli authorities, not because they had shut it down themselves, but because a DDOS protection firm, BackConnect Security, had hijacked the IP addresses belonging to the company. To spare a lot of technical detail, it's called a BGP hijack, and it basically works by a company saying "Yeah, those are our addresses." It's kind of amazing how much of the internet is basically just secured by the digital equivalent of pinky swears. You can read some more technical detail on Wikipedia. Anyway, we'll get back to BackConnect.
Following the publication of the story uncovering the inner workings of vDOS, KrebsOnSecurity was hit with a record breaking DDOS attack, that peaked at 620/Gbps, nearly double the most powerful DDOS attack previously on record. To put that in perspective, that's enough bandwidth to download 5 simultaneous copies of Interstellar in 4K resolution every single second, and still have room to spare. The attack was so devastating, Akamai, one of the largest providers of DDOS protection in the world had to drop Krebs as a pro bono client. Luckily, Google was willing to step in and place his site under the protection of Google's Project Shield, a free service designed to protect the news sites and journalists from being knocked offline by DDOS attacks.
This attack was apparently in retaliation for the vDOS story, since some of the data sent in the attack included the string "freeapplej4ck". The attack was executed by a botnet of Internet of Things (or IoT) devices. These are those "smart" devices like camera systems, routers, DVRs. Basically things that connect to the cloud. An astounding amount of those are secured with default passwords that can be easily looked up from various sites or even the manufacturers' websites. This was the start of a discovery of a massive botnet that had been growing for years.
Now time for a couple quick side stories:
Dyn, a company who provides DNS to many major companies including Twitter, Reddit, and others came under attack, leaving many sites (including Twitter and Reddit) faltering in the wake of it. Potentially due to one of their engineers' collaboration with Krebs on another story. It turned out that the same botnet that attacked Krebs' site was at least part of the attack on Dyn
And back to BackConnect, that DDOS protection firm that hijacked the IP addresses from vDOS. Well it turns out BGP Hijacks are old hat for the company. They had done it at least 17 times before. Including at least once (purportedly with permission) for the address 1.3.3.7. Aka, "leet". It turns out one of the co-founders of BackConnect actually posted screenshots of him visiting sites that tell you your public IP address in a DDOS mitigation industry chat, showing it as 1.3.3.7. They also used a BGP Hijack against a hosting company and tried to frame a rival DDOS mitigation provider.
Finally, another provider, Datawagon was interestingly implicated in hosting DDOS-for-hire sites while offering DDOS protection. In a Skype conversation where the founder of Datawagon wanted to talk about that time he registered dominos.pizza and got sued for it, he brings up scanning the internet for vulnerable routers completely unprompted. Following the publication of the story about BackConnect, in which he was included in, he was incensed about his portrayal, and argued with Krebs over Skype before Krebs ultimately ended up blocking him. He was subsequently flooded with fake contact requests from bogus or hacked Skype accounts. Shortly thereafter, the record-breaking DDOS attack rained down upon his site.
Back to the main tale!
So, it turns out the botnet of IoT devices was puppeteered by a malware called Mirai. How did it get its name? Well, that's the name its creator gave it, after an anime called Mirai Nikki. How did this name come to light? The creator posted the source code online. (The name part, not the origin. The origin didn't come 'til later.) The post purported that they'd picked it up from somewhere in their travels as a DDOS industry professional. It turns out this is a semi-common tactic when miscreants fear that law enforcement might come looking for them, and having the only copy of the source code of a malware in existence is a pretty strong indicator that you have something to do with it. So, releasing the source to the world gives a veneer of plausible deniability should that eventuality come to pass. So who was this mysterious benefactor of malware source? They went by the name "Anna-senpai".
As research on the Mirai botnet grew, and more malware authors incorporated parts of Mirai's source code into their own attacks, attention on the botnet increased, and on the people behind it. The attention was presumably the reason why Hackforums, the forum where the source code was posted, later disallowed ostensible "Server Stress Tester" services from being sold on it. By December, "Operation Tarpit" had wrought 34 arrests and over a hundred "knock and talk" interviews questioning people about their involvement.
By January, things started to come crashing down. Krebs published an extensive exposé on Anna-senpai detailing all the evidence linking them to the creation of Mirai. The post was so big, he included a damn glossary. What sparked the largest botnet the internet had ever seen? Minecraft. Minecraft servers are big business. A popular one can earn tens of thousands of dollars per month from people buying powers, building space, or other things. It's also a fiercely competitive business, with hundreds of servers vying for players. It turns out that things may have started, as with another set of companies, two rival DDOS mitigation providers competing for customers. ProTraf was a provider of such mitigation technology, and a company whose owner later worked for ProTraf had on at least one occasion hijacked addresses belonging to another company, ProxyPipe. ProxyPipe had also been hit with DDOS attacks they suspected to be launched by ProTraf.
While looking into the President of ProTraf, Krebs realized he'd seen the relatively uncommon combination of programming languages and skills posted by the President somewhere else. They were shared by Anna-senpai on Hackforums. As Krebs dug deeper and deeper into Anna-senpai's online presence, he uncovered other usernames, including one he traced to some Minecraft forums where a photoshopped picture of a still from Pulp Fiction contained the faces of BackConnect, which was a rival to ProTraf's DDOS mitigation business, and another face. A hacker by the name of Vyp0r, who another employee of ProTraf claimed betrayed his trust and blackmailed him into posting the source of another piece of malware called Bashlite. There was also a third character photoshopped into the image. An anime character named "Yamada" from a movie called B Gata H Hei.
Interestingly, under the same username, Krebs found a "MyAnimeList" profile which, out of 9 titles it had marked as watched, were B Gata H Hei, as well as Mirai Nikki, the show from which Mirai derived its name. It continues on with other evidence, including DDOS attacks against Rutgers University, but in short, there was little doubt in the identity of "Anna-senpai", but the person behind the identity did contact Krebs to comment. He denied any involvement in Mirai or DDOS attacks.
"I don’t think there are enough facts to definitively point the finger at me," [Anna-senpai] said. "Besides this article, I was pretty much a nobody. No history of doing this kind of stuff, nothing that points to any kind of sociopathic behavior. Which is what the author is, a sociopath."
He did, however, correct Krebs on the name of B Gata H Kei.
Epilogue
Needless to say, the Mirai botnet crew was caught, but managed to avoid jailtime thanks to their cooperation with the government. That's not to say they went unpunished. Anna-senpai was sentenced to 6 months confinement, 2500 hours of community service, and they may have to pay up to $8.6 million in restitution for their attacks on Rutgers university.

Other Stories

I don't have the time or energy to write another effortpost, and as is I'm over 20,000 characters, so here's a few other tidbits of Krebs' clashes with miscreants.
submitted by HereComesMyDingDong to internetdrama [link] [comments]

Part 5. I'm writing a series about blockchain tech and possible future security risks. This is the fifth part of the series talking about an advanced vulnerability of BTC.

The previous parts will give you usefull basic blockchain knowledge and insights on quantum resistance vs blockchain that are not explained in this part.
Part 1, what makes blockchain reliable?
Part 2, The mathematical concepts Hashing and Public key cryptography.
Part 3, Quantum resistant blockchain vs Quantum computing.
Part 4A, The advantages of quantum resistance from genesis block, A
Part 4B, The advantages of quantum resistance from genesis block, A

Why BTC is vulnerable for quantum attacks sooner than you would think.
Content:
The BTC misconception: “Original public keys are not visible until you make a transaction, so BTC is quantum resistant.”
Already exposed public keys.
Hijacking transactions.
Hijacks during blocktime
Hijacks pre-blocktime.
MITM attacks

- Why BTC is vulnerable for quantum attacks sooner than you would think. -

Blockchain transactions are secured by public-private key cryptography. The keypairs used today will be at risk when quantum computers reach a certain critical level: Quantum computers can at a certain point of development, derive private keys from public keys. See for more sourced info on this subject in part 3. So if a public key can be obtained by an attacker, he can then use a quantum computer to find the private key. And as he has both the public key and the private key, he can control and send the funds to an address he owns.
Just to make sure there will be no misconceptions: When public-private key cryptography such as ECDSA and RSA can be broken by a quantum computer, this will be an issue for all blockchains who don't use quantum resistant cryptography. The reason this article is about BTC is because I take this paper as a reference point: https://arxiv.org/pdf/1710.10377.pdf Here they calculate an estimate when BTC will be at risk while taking the BTC blocktime as the window of opportunity.
The BTC misconception: “Original public keys are not visible until you make a transaction, so BTC is quantum resistant.”
In pretty much every discussion I've read and had on the subject, I notice that people are under the impression that BTC is quantum resistant as long as you use your address only once. BTC uses a hashed version of the public key as a send-to address. So in theory, all funds are registered on the chain on hashed public keys instead of to the full, original public keys, which means that the original public key is (again in theory) not public. Even a quantum computer can't derive the original public key from a hashed public key, therefore there is no risk that a quantum computer can derive the private key from the public key. If you make a transaction, however, the public key of the address you sent your funds from will be registered in full form in the blockchain. So if you were to only send part of your funds, leaving the rest on the old address, your remaining funds would be on a published public key, and therefore vulnerable to quantum attacks. So the workaround would be to transfer the remaining funds, within the same transaction, to a new address. In that way, your funds would be once again registered on the blockchain on a hashed public key instead of a full, original public key.
If you feel lost already because you are not very familiar with the tech behind blockchain, I will try to explain the above in a more familiar way:
You control your funds through your public- private key pair. Your funds are registered on your public key. And you can create transactions, which you need to sign to be valid. You can only create a signature if you have your private key. See it as your e-mail address (public key) and your password (Private key). Many people got your email address, but only you have your password. So the analogy is, that if you got your address and your password, then you can access your mail and send emails (Transactions). If the right quantum computer would be available, people could use that to calculate your password (private key), if they have your email address (public key).
Now, because BTC doesn’t show your full public key anywhere until you make a transaction. That sounds pretty safe. It means that your public key is private until you make a transaction. The only thing related to your public key that is public is the hash of your public key. Here is a short explanation of what a hash is: a hash is an outcome of an equation. Usually one-way hash functions are used, where you can not derive the original input from the output; but every time you use the same hash function on the same original input (For example IFUHE8392ISHF), you will always get the same output (For example G). That way you can have your coins on public key "IFUHE8392ISHF", while on the chain, they are registered on "G".
So your funds are registered on the blockchain on the "Hash" of the public key. The Hash of the public key is also your "email address" in this case. So you give "G" as your address to send BTC to.
As said before: since it is, even for a quantum computer, impossible to derive a public key from the Hash of a public key, your coins are safe for quantum computers as long as the public key is only registered in hashed form. The obvious safe method would be, never to reuse an address, and always make sure that when you make a payment, you send your remaining funds to a fresh new address. (There are wallets that can do this for you.) In theory, this would make BTC quantum resistant, if used correctly. This, however, is not as simple as it seems. Even though the above is correct, there is a way to get to your funds.
Already exposed public keys.
But before we get to that, there is another point that is often overlooked: Not only is the security of your personal BTC is important, but also the security of funds of other users. If others got hacked, the news of the hack itself and the reaction of the market to that news, would influence the marketprice. Or, if a big account like the Satoshi account were to be hacked and dumped, the dump itself, combined with the news of the hack, could be even worse. An individual does not have the control of other people’s actions. So even though one might make sure his public key is only registered in hashed form, others might not do so, or might no know their public key is exposed. There are several reasons why a substantial amount of addresses actually have exposed full public keys:
In total, about 36% of all BTC are on addresses with exposed public keys Of which about 20% is on lost addresses. and here
Hijacking transactions.
But even if you consider the above an acceptable risk, just because you yourself will make sure you never reuse an address, then still, the fact that only the hashed public key is published until you make a transaction is a false sense of security. It only works, if you never make a transaction. Why? Public keys are revealed while making a transaction, so transactions can be hijacked while being made.
Here it is important to understand two things:
1.) How is a transaction sent?
The owner has the private key and the public key and uses that to log into the secured environment, the wallet. This can be online or offline. Once he is in his wallet, he states how much he wants to send and to what address.
When he sends the transaction, it will be broadcasted to the blockchain network. But before the actual transaction will be sent, it is formed into a package, created by the wallet. This happens out of sight of the sender.
That package ends up carrying roughly the following info: the public key to point to the address where the funds will be coming from, the amount that will be transferred, the address the funds will be transferred to (depending on the blockchain this could be the hashed public key, or the original public key of the address the funds will be transferred to). This package also carries the most important thing: a signature, created by the wallet, derived from the private- public key combination. This signature proves to the miners that you are the rightful owner and you can send funds from that public key.
Then this package is sent out of the secure wallet environment to multiple nodes. The nodes don’t need to trust the sender or establish the sender’s "identity”, because the sender proofs he is the rightful owner by adding the signature that corresponds with the public key. And because the transaction is signed and contains no confidential information, private keys, or credentials, it can be publicly broadcast using any underlying network transport that is convenient. As long as the transaction can reach a node that will propagate it into the network, it doesn’t matter how it is transported to the first node.
2.) How is a transaction confirmed/ fulfilled and registered on the blockchain?
After the transaction is sent to the network, it is ready to be processed. The nodes have a bundle of transactions to verify and register on the next block. This is done during a period called the block time. In the case of BTC that is 10 minutes.
If we process the information written above, we will see that there are two moments where you can actually see the public key, while the transaction is not fulfilled and registered on the blockchain yet.
1: during the time the transaction is sent from the sender to the nodes
2: during the time the nodes verify the transaction. (The blocktime)
Hijacks during blocktime
This paper describes how you could hijack a transaction and make a new transaction of your own, using someone else’s address and send his coins to an address you own during moment 2: the time the nodes verify the transaction:
https://arxiv.org/pdf/1710.10377.pdf
"(Unprocessed transactions) After a transaction has been broadcast to the network, but before it is placed on the blockchain it is at risk from a quantum attack. If the secret key can be derived from the broadcast public key before the transaction is placed on the blockchain, then an attacker could use this secret key to broadcast a new transaction from the same address to his own address. If the attacker then ensures that this new transaction is placed on the blockchain first, then he can effectively steal all the bitcoin behind the original address." (Page 8, point 3.)
So this means that BTC obviously is not a quantum secure blockchain. Because as soon as you will touch your funds and use them for payment, or send them to another address, you will have to make a transaction and you risk a quantum attack.
Hijacks pre-blocktime.
The story doesn't end here. The paper doesn't describe the posibility of a pre-blocktime hijack.
So back to the paper: as explained, while making a transaction your public key is exposed for at least the transaction time. This transaction time is 10 minutes where your transaction is being confirmed during the 10 minute block time. That is the period where your public key is visible and where, as described in the paper, a transaction can be hijacked, and by using quantum computers, a forged transaction can be made. So the critical point is determined to be the moment where quantum computers can derive private keys from public keys within 10 minutes. Based on that 10 minute period, they calculate (estimate) how long it will take before QC's start forming a threat to BTC. (“ By our most optimistic estimates, as early as 2027 a quantum computer could exist that can break the elliptic curve signature scheme in less than 10 minutes, the block time used in Bitcoin.“ This is also shown in figure 4 on page 10 and later more in depth calculated in appendix C, where the pessimistic estimate is around 2037.) But you could extend that 10 minutes through network based attacks like DDoS, BGP routing attacks, NSA Quantum Insert, Eclipse attacks, MITM attacks or anything like that. (And I don’t mean you extend the block time by using a network based attack, but you extend the time you have access to the public key before the transaction is confirmed.) Bitcoin would be earlier at risk than calculated in this paper.
Also other Blockchains with way shorter block times imagine themselves safe for a longer period than BTC, but with this extension of the timeframe within which you can derive the private key, they too will be vulnerable way sooner.
Not so long ago an eclipse attack demonstrated it could have done the trick. and here Causing the blockchain to work over max capacity, means the transactions will be waiting to be added to a block for a longer time. This time needs to be added on the blocktime, expanding the period one would have time to derive the private key from the public key.
That seems to be fixed now, but it shows there are always new attacks possible and when the incentive is right (Like a few billion $ kind of right) these could be specifically designed for certain blockchains.
MITM attacks
An MITM attack could find the public key in the first moment the public key is exposed. (During the time the transaction is sent from the sender to the nodes) So these transactions that are sent to the network, contain public keys that you could intercept. So that means that if you intercept transactions (and with that the private keys) and simultaneously delay their arrival to the blockchain network, you create extra time to derive the private key from the public key using a quantum computer. When you done that, you send a transaction of your own before the original transaction has arrived and is confirmed and send funds from that stolen address to an address of your choosing. The result would be that you have an extra 10, 20, 30 minutes (or however long you can delay the original transactions), to derive the public key. This can be done without ever needing to mess with a blockchain network, because the attack happens outside the network. Therefore, slower quantum computers form a threat. Meaning that earlier models of quantum computers can form a threat than they assume now.
When MITM attacks and hijacking transactions will form a threat to BTC, other blockchains will be vulnerable to the same attacks, especially MITM attacks. There are ways to prevent hijacking after arrival at the nodes. I will elaborate on that in the next article. At this point of time, the pub key would be useless to an attacker due to the fact there is no quantum computer available now. Once a quantum computer of the right size is available, it becomes a problem. For quantum resistant blockchains this is differetn. MITM attacks and hijacking is useless to quantum resistant blockchains like QRL and Mochimo because these projects use quantum resistant keys.
submitted by QRCollector to CryptoTechnology [link] [comments]

I decided to post this here as I saw some questions on the QRL discord.

Is elliptic curve cryptography quantum resistant?
No. Using a quantum computer, Shor's algorithm can be used to break Elliptic Curve Digital Signature Algorithm (ECDSA). Meaning: they can derive the private key from the public key. So if they got your public key, they got your private key, and they can empty your funds. https://en.wikipedia.org/wiki/Elliptic-curve_cryptography#Quantum_computing_attacks https://eprint.iacr.org/2017/598.pdf
Why do people say that BTC is quantum resistant, while they use elliptic curve cryptography? (Here comes the idea from that never reusing a private key from elliptic curve cryptography (and public key since they form a pair) would be quantum resistant.)
Ok, just gonna start with the basics here. Your address, where you have your coins stalled, is locked by your public- private key pair. See it as your e-mail address (public key) and your password (Private key). Many people got your email address, but only you have your password. If you got your address and your password, then you can access your mail and send emails (Transactions). Now if there would be a quantum computer, people could use that to calculate your password/ private key, if they have your email address/ public key.
What is the case with BTC: they don't show your public key anywhere, untill you make a transaction. So your public key is private untill you make a transaction. How do they do that while your funds must be registered on the ledger? Wel, they only show the Hash of your public key (A hash is an outcome of an equation. Usually one-way hash functions are used, where you can not derive the original input from the output. But everytime you use the same hash function on the same original input (For example IFUHE8392ISHF), you will always get the same output (For example G). That way you can have your coins on public key IFUHE8392ISHF, while on the chain, they are on G.) So your funds are registered on the blockchain on the "Hash" of the public key. The Hash of the public key is also your "email address" in this case. So you give "G" as your address to send BTC to.
By the way, in the early days you could use your actual public key as your address. And miners would receive coins on their public key, not on the hashed public key. That is why all the Satoshi funds are vulnerable to quantum attacks even though these addresses have never been used to make transactions from. These public keys are already public instead of hashed. Also certain hard forks have exposed the public keys of unused addresses. So it's really a false sense of security that most people hang on to in the first place.
But it's actually a false sense of security over all.
Since it is impossible to derive a public key from the Hash of a public key, your coins are safe for quantum computers as long as you don't make any transaction. Now here follows the biggest misconseption: Pretty much everyone will think, great, so BTC is quantum secure! It's not that simple. Here it is important to understand two things:
1 How is a transaction sent? The owner has the private key and the public key and uses that to log into the secured environment, the wallet. This can be online or offline. Once he is in his wallet, he states how much he wants to send and to what address.
When he sends the transaction, it will be broadcasted to the blockchain network. But before the actual transaction that will be sent, it is formed into a package, created by the wallet. This happens out of sight of the sender.
That package ends up carrying roughly the following info: The public key to point to the address where the funds will be coming from, the amount that will be transferred, the public key of the address the funds will be transferred to.
Then this package caries the most important thing: a signature, created by the wallet, derived from the private- public key combination. This signature proves to the miners that you are the rightfull owner and you can send funds from that public key.
So this package is then sent out of the secure wallet environment to multiple nodes. The nodes don’t need to trust the sender or establish the sender’s "identity." And because the transaction is signed and contains no confidential information, private keys, or credentials, it can be publicly broadcast using any underlying network transport that is convenient. As long as the transaction can reach a node that will propagate it into the network, it doesn’t matter how it is transported to the first node.
2 How is a transaction confirmed/ fullfilled and registered on the blockchain?
After the transaction is sent to the network, it is ready to be processed. The nodes have a bundle of transactions to verify and register on the next block. This is done during a period called the block time. In the case of BTC that is 10 minutes.
If you comprehend the information written above, you can see that there are two moments where you can actually see the public key, while the transaction is not fullfilled and registered on the blockchain yet.
1: during the time the transaction is sent from the sender to the nodes
2: during the time the nodes verify the transaction.
This paper describes how you could hijack a transaction and make a new transaction of your own, using someone elses address to send his coins to an address you own during moment 2: the time the nodes verify the transaction:
https://arxiv.org/pdf/1710.10377.pdf
"(Unprocessed transactions) After a transaction has been broadcast to the network, but before it is placed on the blockchain it is at risk from a quantum attack. If the secret key can be derived from the broadcast public key before the transaction is placed on the blockchain, then an attacker could use this secret key to broadcast a new transaction from the same address to his own address. If the attacker then ensures that this new transaction is placed on the blockchain first, then he can effectively steal all the bitcoin behind the original address."
So this means that practically, you can't call BTC a quantum secure blockchain. Because as soon as you will touch your coins and use them for payment, or send them to another address, you will have to make a transaction and you risk a quantum attack.
Why would Nexus be any differtent?
If you ask the wrong person they will tell you "Nexus uses a combination of the Skein and Keccak algorithms which are the 2 recognized quantum resistant algorithms (keccal is used by the NSA) so instead of sha-256, Nexus has SK-1024 making it much harder to break." Which would be the same as saying BTC is quantum resistant because they use a Hashing function to hash the private key as long as no transaction is made.
No, this is their sollid try to be quantum resistant: Nexus states it's different because they have instant transactions (So there wouldn't be a period during which time the nodes verify the transaction. This period would be instant.) Also they use a particular order in which the miners verify transactions: First-In-First-Out (FIFO) (So even if instant is not instant after all, and you would be able to catch a public key and derive the private key, you would n't be able to have your transaction signed before the original one. The original one is first in line, and will therefore be confirmed first. Also for some reason Nexus has standardized fees which are burned after a transaction. So if FIFO wouldn't do the trick you would not be able to use a higher fee to get prioritized and get an earlyer confirmation.
So, during during the time the nodes verify the transaction, you would not be able to hijack a transaction. GREAT, you say? Yes, great-ish. Because there is still moment # 1: during the time the transaction is sent from the sender to the nodes. This is where network based attacks could do the trick:
There are network based attacks that can be used to delay or prevent transactions to reach nodes. In the mean time the transactions can be hijacked before they reach the nodes. And thus one could hijack the non quantum secure public keys (they are openly included in sent signed transactions) who then can be used to derive privatekeys before the original transaction is made. So this means that even if Nexus has instant transactions in FIFO order, it is totally useless, because the public key would be obtained by the attacker before they reach the nodes. Conclusion: Nexus is Nnot quantum resistant. You simply can't be without using a post quantum signature scheme.
Performing a DDoS attack or BGP routing attacks or NSA Quantum Insert attacks on a peer to peer newtork would be hard. But when provided with an opportunitiy to steal billions, hackers would find a way. For example:
https://bitcoinmagazine.com/articles/researchers-explore-eclipse-attacks-ethereum-blockchain/
For BTC:
https://eprint.iacr.org/2015/263.pdf
"An eclipse attack is a network-level attack on a blockchain, where an attacker essentially takes control of the peer-to-peer network, obscuring a node’s view of the blockchain."
That is exactly the receipe for what you would need to create extra time to find public keys and derive private keys from them. Then you could sign transactions of your own and confirm them before the originals do.
By the way, yes this seems to be fixed now, but it most definately shows it's possible. And there are other creative options. Either you stop tranasctions from the base to get out, while the sender thinks they're sent, or you blind the network and catch transactions there. There are always options, and they will be exploited when billions are at stake. The keys can also be hijacked when a transaction is sent from the users device to the blockchain network using a MITM attack. The result is the same as for network based attacks, only now you don't mess with the network itself. These attacks make it possible to 1) retrieve the original public key that is included in the transaction message. 2) Stop or delay the transaction message to arrive at the blockchain network. So, using a quantum computer, you could hijack transactions and create forged transactions, which you then send to the nodes to be confirmed before the nodes even receive the original transaction. There is nothing you could change to the Nexus network to prevent this. The only thing they can do is implement a quantum resistant signature scheme. They plan to do this in the future, like any other serious blockchain project. Yet Nexus is the only of these future quantum resistant projects to prematurely claim to be quantum resistant. There is only one way to get quantum resistancy: POST QUANTUM SIGNATURE SCHEMES. All the rest is just a shitty shortcut that won't work in the end.
(If you use this info on BTC, you will find that the 10 minutes blocktime that is used to estimate when BTC will be vulnerable for quantum attacks, can actually be more then 10 minutes if you catch the public key before the nodes receive them. This makes BTC vulnerable sooner thatn the 10 min blocktime would make you think.)
By the way, Nexus using FIFO and standadrized fees which are burned after the transaction comes with some huge downsides:
Why are WOTS+ signatures (and by extension XMSS) more quantum resistant?
First of all, this is where the top notch mathematicians work their magic. Cryptography is mostly maths. As Jackalyst puts it talking about post quantum signature schemes: "Having papers written and cryptographers review and discuss it to nauseating levels might not be important for butler, but it's really important with signature schemes and other cryptocraphic methods, as they're highly technical in nature."
If you don't believe in math, think about Einstein using math predicting things most coudldn't even emagine, let alone measure back then.
Then there is implementing it the right way into your blockchain without leaving any backdoors open.
So why is WOTS+ and by extension XMSS quantum resistant? Because math papers say so. With WOTS it would even take a quantum computer too much time to derive a private key from a public key. https://en.wikipedia.org/wiki/Hash-based_cryptography https://eprint.iacr.org/2011/484.pdf
What is WOTS+?
It's basiclally an optimized version of Lamport-signatures. WOTS+ (Winternitz one-time signature) is a hash-based, post-quantum signature scheme. So it's a post quantum signature scheme meant to be used once.
What are the risks of WOTS+?
Because each WOTS publishes some part of the private key, they rapidly become less secure as more signatures created by the same public/private key are published. The first signature won't have enough info to work with, but after two or three signatures you will be in trouble.
IOTA uses WOTS. Here's what the people over at the cryptography subreddit have to say about that:
https://www.reddit.com/crypto/comments/84c4ni/iota_signatures_private_keys_and_address_reuse/?utm_content=comments&utm_medium=user&utm_source=reddit&utm_name=u_QRCollector
With the article:
http://blog.lekkertech.net/blog/2018/03/07/iota-signatures/
Mochimo uses WOTS+. They kinda solved the problem: A transaction consists of a "Source Address", a "Destination Address" and a "Change Address". When you transact to a Destination Address, any remaining funds in your Source Address will move to the Change Address. To transact again, your Change Address then becomes your Source Address.
But what if someone already has your first address and is unaware of the fact you already send funds from that address? He might just send funds there. (I mean in a business environment this would make Mochimo highly impractical.) They need to solve that. Who knows, it's still a young project. But then again, for some reason they also use FIFO and fixed fees, so there I have the same objections as for Nexus.
How is XMSS different?
XMSS uses WOTS in a way that you can actually reuse your address. WOTS creates a quantum resistant one time signature and XMSS creates a tree of those signatures attached to one address so that the address can be reused for sending an asset.
submitted by QRCollector to QRL [link] [comments]

Future concerns for the Bitcoin Network.

Hi /Bitcoin ,
I am open to correction on any areas I have have misunderstood, but I do have some concerns for the future of mining and consensus.
Miners receive BTC for mining new blocks, these can be physical individual miners or logical mining pools. Block rewards will continue diminishing until all Bitcoins are in circulation, ETA the year 2140.
In the run up to this date, Bitcoin mining will become less and less feasible, and assuming BTC finds a stable price prior to this date then profitability will also decline. Without a large number of miners, the Bitcoin network could become more and more centralized over the years, allowing a single entity to reach consensus once more. Therefore the Network could be hijacked, resulting in the end of Bitcoin.
In an alternate scenario, mining fees continue to increase to combat the diminishing profitability of block rewards. As you are all aware, mining fees are already becoming a growing concern and are accelerating the deflationary nature of Bitcoin, i.e a wallet with $20 worth of BTC may find it impossible to move this BTC. This leads to an eventuality where millions of users can own and store BTC, but are unwilling to transact with it. The reduction of transactions reduces the mining fee income and profitability of miners, who cease operation and the Network becomes more centralized than ever.
In a final scenario, these concerns are addressed early and maintaining the hash power of the network becomes a recognized public utility, and Service-Provider are delegated the responsibility of hosting mining farms to validate transactions. Similar to BGP, the running of the full Internet Routing Table becomes a Service-Provider task. Individual miners cease operations, and the Network becomes more centralized than ever.
With the current state of the protocol, I see no future scenario where the Bitcoin Network can remain both usable and decentralized. Without one, the other is worthless.
Any feedback is appreciated.
submitted by Bloodwank to Bitcoin [link] [comments]

Of Wolves and Weasels - Day 214 - Weekly Wrapup #24

Hey all, GoodShibe here!
Here's your week in Dogecoin!
This Week's oWaWs
Announcements
Top Images/Memes of the Week
New Dogecoin Businesses
Businesses Now Accepting Dogecoin
Ongoing Dogecoin Projects
Dogecoin In The News
Did I forget anything? Of course I did! Please let me know in the comments and I'll add it here!
It's 9:30AM EST and we've found 89.42% of our initial 100 Billion DOGEs -- only 10.58% remains until our period of Hyper-inflation ends! Our Global Hashrate is up from ~43 to ~45 Gigahashes per second and our Difficulty is up from ~633 to ~773.
As always, I appreciate your support!
GoodShibe
submitted by GoodShibe to dogecoin [link] [comments]

Theo Baschak - BGP Hijacking Goes Mainstream BGP Hijack Explained Four years of breaking HTTPS with BGP hijacking BGP Path Hijacking Attack Demo - mininet - YouTube Hijacking The Internet Using A Bgp Mitm Attack (Defcon 16)

BGP hijacking has also given rise to hijacking of cryptocurrencies [9], [10], such as Bitcoin, as a new aspect of cybercrime. A recent finding has shown that BGP hijacking [11] can only be ... Bitcoin's have been gaining popularity left and right, every single day. Everyone wants to have a large amount of BTC in their wallet, no matter what it takes to get there. Of course, this also means that there are going to be hackers and other... In that case a complete BGP hijacking situation occurs, as BGP routers install more specific routes into their routing tables. As Maria Apostolaki in her paper claims, the vast majority of Bitcoin nodes are hosted in prefixes less than /24. Therefore, an attacker is announcing prefixes with length /24. Prefixes longer than /24 would be very likely filtered by upstream providers. Re-org protection just opened an attack vector for nation states and malicious/incompetent ISP's. Previously the incentives were for miners to... By hijacking a couple of the cornerstone protocols governing the Internet: DNS and BGP. This is exactly what unfolded on the morning of April 24th, around 5:00 am PST. The ultimate target, in this case, is believed to be a popular crypto wallet app—MyEtherWallet—as reported by security researcher Kevin

[index] [41504] [1522] [48988] [46374] [46621] [38755] [32785] [29885] [32743] [41529]

Theo Baschak - BGP Hijacking Goes Mainstream

Demo of BGP path Hijacking. 10 Fired WWE Wrestlers You WON'T Recognize After Shocking Body Transformations Since Leaving WWE - Duration: 4:50. TheSportsEntertainer Recommended for you AT&T Data Security Analysts discuss the challenges that the community faces when it comes to BGP. Originally recorded November 3rd, 2015. See the full episod... In this lab i use mininet labs to show BGP hijacking and how that can affect businesses and private citizens. BGP is the internet routing protocol, but we ar... BGP Route Leak Misdirects Google Cloud Traffic Through Russia & China - Duration: 4:30. ... Hijacking Bitcoin: Routing Attacks on Cryptocurrencies - Duration: 21:14. IEEE Symposium on Security and ... In past years talks Theo has talked extensively about BGP, and BGP hijacking. In 2018 we've seen several instances of where BGP hijacking has been combined with other methods to steal ...

#