The key fingerprint mentioned is 01EA5486DE18A882D4C2684590C8019E36C2E964. (Mirroring into comments to make life difficult for anyone who wants to modify bitcoin.org's web page).
Have you done the rest of the verification necessary to say this is legitimate?
* Wayback to some months ago for the download page [1]
* Confirm that the content presented matches the existing download content for the 0.12.1 release (or prior)
* Confirm that the content for the "0.11+ key" is the same [2]
* Confirm that the signed release for the 0.12.1 content is correct and valid
* Request that (full-length) key from a public GPG server
If you've done all of those things, it might be a good idea for you to sign that key and push it back up to a public GPG server - that help with web-of-trust, and somewhat legitimizes the key versus some arbitrary untrusted impostor. (I have done all of these steps, and signed with my key 9BB5251DE08569D4DEEA894C85D221C11DD01DF6)
>Shouldn't keys only be signed after meeting in person?
Keys should only be signed after establishing beyond resonable doubt that they belongs to the person indicated by the key. Since the userid of the key is usually a real name, checking the passport in person is one good way to accomplish that.
I would argue that by cross-referencing multiple sources I can establish beyond resonable doubt that a certain key indeed belongs to the person known to the community as Wladimir J. van der Laan. At the point where the person is sufficiently well known under a certain name it doesn't really matter if that's the name on their passport, since that's irrelevant for their public identity.
I can certify that this key is the same one that was used for the 0.12.1 release, and its content has been published on more than just the bitcoin.org website and more than just $TODAY.
I can see the same content on Reddit's /r/bitcoin wiki page or on Bitcoin Talk, with an identical signature. I would have to believe that either Bitcoin is already compromised, or that bitcoin.org, bitcointalk.org, reddit.com AND archive.org have all been hacked or coerced into changing content with accurate history intact.
I don't know, it feels like it poisons the web of trust. There's definitively something odd going on, and IF this was a coordinated attack, would it be too much to think the adversary has managed to post with some sock puppet accounts on a couple of forums - or even hack them? Or even hack your browser - a single compromised extension like an ad blocker could search&replace the key id in any web page rendered to you. I think that if you decide to sign keys just from an hour's worth of browsing around you are damaging the reputation of your own key to be honest.
I'll accept the "damage" to my own key - Realize what you're claiming:
Someone compromised the Bitcoin site > 4 months ago without it being discovered.
Someone continues to compromise the site today even after this public attention, since the same message is still there.
That same entity compromised my browser, curl, my Linux laptop, Windows desktop, Android phone and 3 different networks.
That same entity compromised Archive.org and Reddit 4+ months ago without being discovered.
That same entity created sockpuppet accounts to publicize the fact that this info was compromised and nobody discovered the discrepancy.
I don't believe that even the pre-Snowden NSA had all of those powers. If they did, fake signatures are probably the least of our problems.
It's no longer the original model of Person === Key that requires passport checks and face-to-face meetings. I would consider this better validation, in that it certifies real-world and historical usage.
Here's my alternate proposal: How difficult is it for the same attacker to create a fake passport and show up to a bitcoin meetup claiming to be this person?
I'm just saying that if you go out and verify all those things today (even looking at archive.org etc), then as long as you're using just one (type of) browser configuration, compromising a single extension could be enough to "blur your vision" when you decide to sign that key. A couple of regexes replacing a few variants of the real fingerprint with the fake fingerprint in all HTML documents - then every forum post you look at echoing the key might be a lie. Those scenarios are "OR", not "AND"... :)
Or, you know, for paranoia level 1000, your posts are the sockpuppet ;)
I'll agree this is all super unlikely and I'm not accusing you or anyone here of shenanigans. I'm just saying that signing keys shouldn't be taken lightly, because if people start getting sloppy then a lot of the trust in the web of trust is no longer water tight.
I don't run that kind of extension [0], but that's the reason I included this line:
> That same entity compromised my browser, curl, my Linux laptop, Windows desktop, Android phone and 3 different networks.
At least 3 platforms, potentially different 3 browsers, plus command-line.
If I want to do this "properly" it's a lot of work. I'd get 3 or more independent VPN providers and run the test while connected to each, independently or in series. I'd run everything in a VM that I created from a verified source 5+ years ago on hardware from 10+ years ago[1]. I would have to categorize and confirm that every vulnerability in all software was either fixable via configuration, or couldn't contribute to remote compromise of the box. I'd run the test with and without Tor, hard-resetting the VM to its initial state for every variation and comparing the results across every run to detect abnormalities. I'd confirm the content at Archive, CommonCrawl, Yahoo, Google and at least one foreign provider, Yandex or Baidu or whoever else I could track down. I'd look for that same string in all places I could find it (web, newsgroups, torrents, friends, friends-of-friends), and confirm that neither those pages nor any linked pages contain invalidations, or if any of them contain further evidence to support the identity of said key. By "linked" I mean both links from those pages, and anything I could discover via search engine pointing to those pages independently. I'd go find some old torrents or archives of older versions of the binaries and/or signatures, and confirm that their content matches the published content. I'd confirm that the old key was in use before 0.11, and that the new key is indeed the one that signed release 0.11+. I'm sure there are some further steps I could take to invalidate any known or theorized attacks from state-level agencies, but at this point it's probably more difficult to fake than a GPG signature.
And obviously I'm a sockpuppet - nobody should listen to random strangers on the internet without verifying their identity as well! You could look at my keybase profile, but A) that's easy to fake and B) that's not the key I used to sign above - clearly something hinkey is going on. ;)
When you sign a key, you can use the flag `--ask-cert-level` and it will prompt you to specify on a scale of 1-3 how careful you were. This would be a case when you could specify a lower number (namely, 1).
Personally, I save level 3 signatures for people I know personally, and only if they show my their fingerprint on a trusted device.
A lot of the developers have participated in key signing parties , and have keys with lots of history. Would be good if they could drop some signatures.
It would be great if the core devs used their PGP keys, many of which are very highly trusted in the PGP strong set, to sign this key so that it is obviously the real deal. Right now it's only signed by two keys, Wladimir J. van der Laan's and some unknown one. Stick a bunch of other core devs on it and re-post it!
Just to be clear, 01EA5486DE18A882D4C2684590C8019E36C2E964 is the fingerprint of the malicious tampered signature key. If the signing key has this fingerprint, it is likely confirmed tampered and any binary signed with it can be presumed compromised or worse.
(Mirroring TLDR into comments in case of DDOS or tampering with bitcoin.org's web page).
We strongly recommend that you download that key, which should have a fingerprint of 01EA5486DE18A882D4C2684590C8019E36C2E964. You should securely verify the signature and hashes before running any Bitcoin Core binaries. This is the safest and most secure way of being confident that the binaries you’re running are the same ones created by the Core Developers.
Sarcasm might not be a perfect choice for universal comprehension, but this does at least showcase what a cover-up might look like. To my knowledge this sort of thing hasn't been pulled off on any massive scale, but with high enough stakes (e.g., bitcoin) the plausibility starts to rise from zero.
To be absolute sure, you need to review and compile the code yourself.
Scratch that. Code up a brand new implementation, test it and deploy it to an air gapped network, and then nuke it from orbit. It's the only way to be sure. :)
they might remove the warning altogether and replace it with a page saying "Hello friends! Please download the latest version and enjoy a picture of a pony"
This is why I love the approach taken by Debian (and most other distros).
Although they provide binary packages, they insist on building everything from source, independently from the upstream projects such as Bitcoin. Moreover, the build process itself must be able to run entirely with Free Software. And the same must hold for all dependencies. Otherwise a package can't make into their "main" distribution (just into "contrib" or "non-free", but users of these parts are warned).
That way, an attacker can't simply tamper with binaries. They have to distribute the manipulates sources instead. Although that kind of attack may still be feasible, it requires a lot more openness from the attacker than just changing sources privately and distributing merely faulty binaries.
This will be futher hardened by Debian's initiative to provide reproducible builds, so that if one of their many build servers is compromised, this can be detected by simply comparing hashes of the resulting binary packages produced by other build servers and/or local build of the maintainers or any curious user:
Speaking of Debian, unfortunately Bitcoin never made it beyond Debian/Unstable (Sid), because the Bitcoin release process appears to be incompatible with the Debian release process, especially regarding backporting security fixes, so the Debian people decided to be better safe than sorry:
Here, bitcoin_0.11.2.orig.tar.gz is the original source tarball as downloaded from the Bitcoin project, and bitcoin_0.11.2-1.debian.tar.xz is the tarball that contains all Debian specific adjustments.
"For instance, when a maintainer uploads a (portable) source packages with binaries for the i386 architecture, it will be built for each of the other architectures, amounting to 11 more builds."https://www.debian.org/doc/manuals/developers-reference/pkgs...
I do not see how the quoted text snippets contradict what I wrote (that Debian builds binary packages fully indepdently from upstream, and prepares to have reproducible builds in the future).
Moreover, a single "huh?" comment is almost never helpful for a civil conversation.
how does debian developers independently building on their machines help? if anything it adds another point of failure. if you trust upstream enough to run their code, you implicitly trust the state of their hardware anyway (since nobody has the time to completely grasp any reasonably large codebase in its entirety); so it seems sensible to trust their builds more than some random debian maintainer
> if you trust upstream enough to run their code, you implicitly trust the state of their hardware anyway
No, these are fundamentally different levels of trust.
Note that we are talking about a breach-in into the webserver, not into a developer's private computer.
For example, some time ago there was a breach-in into the Linux Kernel website. It had almost no effect on the security of this project, because so many people had the sources, and because the Git commits are signed by the authors.
So not only were the attackers unable to distribute their binaries. They were also unable to place malicious commits into the source code. And this was mainly because every distro builds their Linux kernel on their own (and also because sources are signed by the developers and reviewed by multiple developers, although that's not the point of discussion here).
The breach-in into the Bitcoin webserver could have been similarily effect-less, if they were as well-organized as the Linux kernel and worked better together with the distros.
bitcoin.org does not implement HPKP. Any government that controls a CA can generate its own cert for bitcoin.org, hijack the site's IP and replace this page with their own fingerprint.
And China has a root CA under their control. I'm on my iPad at the moment so I can't provide the fingerprints of it right now, but I remember "un-trusting it" on all of my machines a long while back.
Yes, of course. There's something like, what, around 400 root CAs, I think?
I mentioned the .cn government (and their root CA(s)) because the article mentioned the .cn government, specifically, and the parent comment mentioned "any government that controls a CA".
Obviously, any government with a) control over a root CA and b) control over their entire country's Internet access could carry this out. The article we're commenting, however, called out .cn by name.
Yes, that's exactly what I did. I removed the "CNNIC" root certificate authority after some previous mishap (I want to say they issued certs for google.com, et al., but I may be thinking of a different incident).
The website is vulnerable in a much larger number of ways, since it involves significantly more infrastructure which is all vulnerable to state actors. A state could generate fake certificates, physically access hosting servers, or access the internet connections the website uses.
There is a much smaller attack surface for keys.
If you are talking about protecting the key fingerprint they posted on the website, the idea is by publishing them now that others can note the fingerprint and warning before any malicious actor would have a chance to respond.
This is also the same key they've used in the past I believe, so it can always be compared to prior releases.
Downloading by torrent hash link is nice because it cannot be altered after release, while this isn't true with a link to a binary file on a website.
However, you still have to verify the authenticity of the binary with keys if you don't trust the location you got the torrent hash from (ie, the bitcoin website). So yes, essentially the same problem I believe!
A state sponsored attacker can reasonably easy generate a valid ssl certificate to man-in-the-middle any website, and replace it with what ever they please. However, they wouldn't be able to forge a signature if checked against the right keys
> A state sponsored attacker can reasonably easy generate a valid ssl certificate to man-in-the-middle any website, and replace it with what ever they please
Doing this against bitcoin.org is probably taking a pretty big risk. Remember that misissued certificates represent proof of their own existence, and, if disclosed publicly, should result in an investigation of how the certificate was created.
They could also choose to start using HPKP and asking browsers to report pin failures. Then a browser that has visited the legitimate site before will report to someone if it encounters an inconsistent cert in the future. That would make using a misissued cert for this site into an even bigger risk.
> Doing this against bitcoin.org is probably taking a pretty big risk.
Although it wasn't by hijacking the public key infrastructure, it is worth noting that China has demonstrated in the past they have no issue performing country-wide man-in-the-middle attacks against a single site [1]. Given that some CA's are Chinese, it is not that unbelievable unfortunately...
An HTTPS MITM attack burns a CA; browsers will remove it from their trust stores. And we're getting close to the point that it can't go undetected, either; once browsers enforce Certificate Transparency for all CAs, it'll no longer be possible to conduct an undetected MITM attack.
When I was looking into Chinese browsers two years ago, a number of them did not correctly validate certificates on HTTPS sites. They might not need to burn a CA. It should also be noted that HPKP will ignore issues when the cert is signed by a locally installed CA.
It won't ignore issues for when the CA chains back to a OS preloaded one (when there is a distinction between user-added and preloaded, not sure in other case. ie Linux.) I agree somewhat more could be done on this front however if you're in a position where an adversary can add user-added CA's to your system you have bigger problems to worry about.
I feel irresponsible for submitting this since I'm told no one but the poster knows anything about this and this did not go through the normal checkin process for bitcoin.org.
CNNIC was the root of trust for a breach involving false certificates for gmail. They claim it was an accident. It might have been. It might not have been.
It's nothing special about this release, it's just that this is a release. There's normally a trickle of downloads, which wouldn't be worth attacking because you'd be discovered quickly and most of your targets would be newbie users who don't have much coin worth stealing. Attack right at the moment that a new version is released, however, and you end up with your compromised binary distributed to way more people before it's discovered.
Maybe they're attempting to make the peer-to-peer network resistant to partitions caused by what is commonly called the Great Firewall Of China? In that case, they are not crazy to think that would draw adversarial attention.
It may not be a matter of the release being particularly special; rather, they might've been tipped off to some insider information or otherwise be aware of some information they felt it'd be best not to describe in detail right now.
Unfortunately, none of the Bitcoin developers are currently aware of any "insider info" at all. This was force-pushed by a single individual who has not been communicating with anyone about this alert.
Is the concern here specifically related to the NSA Shadow Brokers hack (where they're supposedly auctioning the goods for bitcoin), or just more generally that a state adversaries will try to fully identify parties on the network?
So far, none of the others I have pinged about this has any info as to its veracity or background. Unlike most contributions to bitcoin.org, this one was pushed to the master branch without a corresponding pull request (a mechanism used to solicit review and feedback from others). https://github.com/bitcoin-dot-org/bitcoin.org/commit/5e0fd5...
I suggest skepticism. We should be cautious of anyone skipping peer review processes, even for security incidents. Poor handling of these situations can lead to unintentional panic where panic of any kind is unhelpful to resolving issues. However, everyone should always be encouraged to check the signatures regardless of alerts, of course. Multiple signatures should always be checked, and not just Wladimir's signature. Use the gitian signatures repository to get other signatures, and always verify public key and signature data through multiple independent channels.
One wonders: if publishing a key fingerprint on a website in advance is considered a reasonable warning, would a torrent magnet link prove just as effective?
0.13.0 isn't out yet, and I don't think you can create an "empty" torrent, publish the magnet link, then update the torrent with the actual file at a later date while keeping the magnet link the same.
That's correct. A Magnet link contains a hash of the file/s so it can be verified to be identical to the original during download. So you can't put the hash in there if you don't have the file yet.
No. A magnet link contains a hash of the torrent file, which is an extensible format[1]. One can simply add data to malicious torrent file until it collides with the target[2].
To do that, wouldn't you need to construct a file that simultaneously had two collisons for the same file: one collision for the torrent sha1, and one for the hash of the torrent (the magnet uri)?
The link you gave for finding a single collision in certain types of files (rar, sh, jpg) required putting garbage into the malicious file (eg, in comments in the sh file).
They didn't mention creating collisions in torrent files.
It seems exceedingly unlikely to me that you'd be able to construct a file containing two simultaneous collisions, unless there's a spot where you can add garbage without corrupting the file, both in the torrent file and also in the hash of the torrent.
I think the RIAA would be very interested if it was that easy to create fake torrents that hash the same.
Edit: Actually your second link doesn't even show a weakness in SHA1. So you can't create a malicious torrent using that method.
> To do that, wouldn't you need to construct a file that simultaneously had two collisons for the same file: one collision for the torrent sha1, and one for the hash of the torrent (the magnet uri)?
No.
The magnet URI only contains the hash of (part of) the torrent file. The portion that is hashed is extensible, so one could introduce additional content (like garbage or comments).
> I think the RIAA would be very interested if it was that easy to create fake torrents that hash the same.
Easy is subjective. It costs around £150k and a month to make one[1].
However I asked them, and they aren't. Or at least the MPAA isn't.
You're claiming that SHA1 has been broken, but it hasn't. Have a closer look at what's actually stated at [2].
Edit: from your [1] link I see that the hashing algorithm used in a mgnet link isn't actually fixed, and MD5 is one option. So yeah, I guess you actually can't trust the immutability of a magnet link without checking it's doesn't contain urn:md5 or urn:kzhash.
It has nothing to do with whether the hashing algorithm is "fixed" or not, it has to do with what you're hashing.
The thing being hashed (according to BEP0003) is the bencoded form of the info value from the metainfo file. What's the "info" value? Why it's a list of dictionaries that (are also bencoded) contain:
* pathnames for each file
* the length of each file
* a list of hashes for each chunk of each file
* whatever else you want: the thing is extensible.
If you can introduce whatever you want, you can start with something valid, and introduce invalid chunks until it collides. If you can do this, you can force a collision for around £150k and a month[2].
Bitcoin can not become a serious replacement currency, as no government can ever give up control over monetary policy and would rather put away lots of people than allow any threat to how things work.
If you know nothing of computers you might find articles that explain Bitcoin briefly and then point you to a "wallet" that you can download and to various exchanges where you can buy Bitcoin for real money. Why not give it a shot, and "invest" a bit? You need to know quite a bit to understand the unfixable problems with computer security, and read a little to learn of the cruelty of the cryptocurrency world: no password resets, no deposit protection, no sympathy when you lose your money.
It will take time... Computers, Internet and new techs in general aren't mainstream in their beginings. Do you expect it to be perfect from its inception? Even planes crashed on their first flights, and look at us now, flying everywhere.
Do not use "the bitcoin PPA". Launchpad compiles this on their own infrastructure outside of the gitian build process. If, for some insane reason, if you must use "the bitcoin PPA", always check hashes, always verify the binaries are correct, and always check signatures regarding those particular hashes.
Aren't all of Ubuntu's packages built on launchpad? It's interesting that you don't trust launchpad, should I not trust my OS either? And as far as checking signatures, that's what apt does automatically anyway, as I understand.
I know people like Moxie insist that it's only acceptable to have the (at least) software's author sign the software. Well, personally I'd rather trust a larger organization with more reputation to lose. (Ideally I'd have both, of course, when we get to deterministic builds.)
edit: Oh, deterministic builds is what gitian is. Okay I see your point :-) But still, why trust your OS at that point?
Launchpad build process for bitcoind is not the same as the gitian build process. My recommendation is specific to Bitcoin Core, although I have not evaluated the security of other PPAs on launchpad...
I wonder who is keeping their secret keys in Bitcoin Core? Are people doing this? I know, I am not. I am just running it as a full node.
What other attacks would be possible if nobody stored their secret keys in Bitcoin Core?
Probably only attacks that required a lot of installations to be compromised.
