Fake PGP Keys For Crypto Developers Found 110
IamTheRealMike (537420) writes "In recent months fake PGP keys have been found for at least two developers on well known crypto projects: Erinn Clark, a Tor developer and Gavin Andresen, the maintainer of Bitcoin. In both cases, these PGP keys are used to sign the downloads for popular pieces of crypto software. PGP keys are supposed to be verified through the web of trust, but in practice it's very hard to find a trust path between two strangers on the internet: one reply to Erinn's mail stated that despite there being 30 signatures [attached to] her key, [the respondent] couldn't find any trust paths to her. It's also very unclear whether anyone would notice a key substitution attack like this. This leaves three questions: who is doing this, why, and what can be done about it? An obvious candidate would be intelligence agencies, who may be trying to serve certain people with backdoored binaries via their QUANTUMTHEORY man-in-the-middle system. As to what can be done about it, switching from PGP to X.509 code signing would be an obvious candidate. Both Mac and Windows support it, obtaining a forged certificate is much harder than simply uploading a fake PGP key, and whilst X.509 certs can be issued in secret until Google's Certificate Transparency system is fully deployed, finding one would be strong evidence that an issuing CA had been compromised: something that seems plausible but for which we currently lack any evidence. Additionally, bad certificates can be revoked when found whereas beyond making blog posts, not much can be done about the fake PGP keys."
The chain of trust is broken. (Score:1)
The chain of trust is broken. This because today a certificate is only authorized by a single source, not by several. In addition to this the model has the flaw that it does not easily allow a point to point scenario where only two parties are involved.
Re:The chain of trust is broken. (Score:4, Informative)
Re:The chain of trust is broken. (Score:5, Interesting)
Well; interestingly enough, the summary is proposing moving to X.509 which would rely on the chain of trust and which would be vulnerable. Exactly the problem of simple chains of trust is what meant that the Stuxnet virus had device drivers that only required a single signature from a company authorized by Microsoft in order to be automatically loaded by Windows.
This is probably a false-flag operation trying to trick software developers into moving over to X.509 where a false certificate attack like this might never be detected.
Re: (Score:2)
You may have something there. Alarm bells were going off in my head when I saw the summary advocating a move toward not away from X.509. If someone wants us to move toward the tech used by (famously subverted) PKI, they better damn well spell out how PKIs mistakes won't affect verification procedures.
Transitivity of trust (Score:5, Insightful)
Re: (Score:3)
Just because you trust somebody doesn't mean you trust him or her to trust others.
Very true! If I meet a person face-to-face, they hand me their PGP/GPG public key, and they show me plausible-looking picture ID that matches the identity that their key claims to represent, then I can mark their key in my keychain as one that I'm confident is not a forgery. If they are otherwise a stranger to me with no well-known reputation, then I can register in my keychain that their signature on somebody else's key doesn't count for much. Or if they are a well-known person with a reputation of being v
Re: (Score:2)
> Very true! If I meet a person face-to-face, they hand me their PGP/GPG public key, and they show me plausible-looking picture ID that matches the identity that their key claims to represent,
And I've stolen private GPG keys, stored in unsecured home directories or on backup tapes, precisely to demonstrate some of the current problems with the web of trust. It's particularly useful to steal poorly secured GPG keys that are part of an automated build process, since the build process must be able to unlock
Keypair expiry (Score:2)
How does stealing GPG private keys differ from stealing any other private part of a keypair?
Typically in X.509, a keypair is expected to expire. (Technically, a certificate expires, but at least in the use of X.509 for TLS, it is common to make a new key and CSR for the new cert.)
Re: (Score:2)
so you could do a two-step auth. look at your trust paths, ask yourself how much verification each person may have done to the next.
Or try to get shorter trust paths. And more.
Re: (Score:2)
look at your trust paths, ask yourself how much verification each person may have done to the next.
Good luck training enough end users to do that.
Or try to get shorter trust paths. And more.
Good luck with that without getting on an airplane and dealing with tourist visa hassles to go to keysigning parties in other countries.
Re: (Score:2)
so, what are your alternatives?
- trust paths: good luck with the transitivity
- personal meetings: always the best choice, if your privacy is important
- trusting a central instance. Good luck chosing one.
Re: (Score:2)
And in this case, the fake key has zero signatures whatsoever. If it had any, they would either be a blob of also-fake unconnected keys, or someone proving his guilt this way.
Re: (Score:2)
And in this case, the fake key has zero signatures whatsoever. If it had any, they would either be a blob of also-fake unconnected keys, or someone proving his guilt this way.
Just to be pedantic, a fake key may also be signed by a real, correctly-identified individual who had no intention of subterfuge, but who isn't careful about whose keys he or she signs. Of course, once discovered, that person should from then on be distrusted to validate other keys just as much as somebody who deliberately tried to deceive others.
A scarier but less likely possibility would be a malicious actor who creates a forged key for some other person, and then attends key-signing parties where they pr
Re: (Score:2)
To do that, the attacker would also need to be able to intercept mail sent towards the real person. You can sign a key without using mail, but that's not what is done during usual keysigning, and asking an innocent person to do so would raise a suspicion. Yeah, intercepting mail is possible if you're resourceful enough, especially without DANE, but that's quite a hoop to jump through. This usually implies an organization, and with that resources, it's simpler for the attacker to find a bunch of shadier p
Re: (Score:2)
Another approach is to create fictional IDs with generic email addresses (gmail or similar), create keys for the fictional IDs and get them signed. Then use the keys associated with fictional IDs to sign the keys you plan to use for impersonation.
This is more work than just having shady people use their real IDs to sign the impersonation keys but reduces the risk of your accomplices being found out.
Re: (Score:3)
The problem is that trust diminishes. If I trust you 80%, and you trust Joe 75%, and Joe trusts Jennifer 90% and Jennifer trusts Josh 80% and Josh signs that key, then my total trust in that signature is only 43% - worse than flipping a coin.
The web needs to be a lot thicker than it is so that I have multiple paths towards the key in question that add up. If the web is as thin as it still is, despite decades of keysigning parties and such, then it is utterly useless.
It's a good theoretical concept, but we s
Re: (Score:2)
Re: (Score:2)
Outside the city? Pfft. Try world-wide. Once you go across the ocean, the whole web hangs on a comparatively small number of individuals.
Re: (Score:2)
Use Tor and some other proxies, sample multiple times.
Re: (Score:2)
Re: (Score:2)
How do you trust these proxies not to be run by state intelligence organizations?
1. The attackers can't be omnipresent at all times
2. Doing a MITM against all randomly-located HTTPS links is probably impossible to do without being discovered.
3. Some orgs like Torproject have an .onion address. Then you don't have to worry about MITM as long as your original copy of Tor was OK. If you're worried about Tor or other program being tampered with, try using one or more Linux Live CDs: Boot, update then install Tor or other secure proxy, then download keys and certs... leverage the built-in ke
Re: (Score:2)
its kind of a routing problem.
Re: (Score:2)
Re: (Score:2)
The other problem is what "trust" means here. Most people would, in the absence of other context, say it means something like "Joe is a good guy and I don't think he's bad or malicious". But what trust really means in the PGP sense is "Joe is capable of securing his private key and verifying identities reliably". That is totally different and impossible to judge based just on social knowledge.
In the CA world we build trust in "Joe" through audits and standards processes to ensure that private keys are stor
Re: (Score:2)
You should meet Jennifer. (Side-effect: both Josh and Joe will be grateful.) Until then, 43% may be worse than flipping a coin but it's still a whole lot better than zero, and it's the best thing we have.
People have been trying to think of something better. And it always comes back to you meeting Jennifer, or for some group of people (or entities) to step up and start meeting a whole lot more people (perhaps state governments or even .. (my idea here) banks should be prolific signers), and for Joe to tea
Re: (Score:2)
The technology to finally create the web of trust exists: cell phones, NFC/barcode scanner on phone, push notification (to nag you to connect to nearby friends)
The technology for more secure communication and authentication exists: smart cards (not yet compatible with cell phones)
There is clearly not a need yet for users to join the web of trust.
Re: (Score:2)
And, shit, I'm surprised I still can't get legally-admissible PDF account statements from my bank online.
Re: (Score:2)
This is a critical problem with the suggested "solution"; X.500 code signing.
Re:The chain of trust is broken. (Score:4, Insightful)
The chain of trust is broken because cryptographers, a class of developers with a long track record of being utterly incapable [gaudior.net] of building software that's usable for regular humans, has been left in charge of building iit.
When the problem is taken up by other, more UX knowledgable, developers we'll get a solution to the problem [blogspot.com].
Re: (Score:3)
Agreed!
Personally I'm actually kind of excited to see the security requirements for Bitcoin usage and Bitcoin-related development push more developers and users to learn about and understand OpenPGP and the web-of-trust. It's been a real backwater for years now, but there's so much that can be done to improve UI's for understanding how the web-of-trust works and using it. That no-one has made even a simple "mass-and-springs" visualization tool for WoT signatures is sad, yet even something as simple as that
Re: (Score:2)
It ought to start by making certs and keys first-class GUI objects, starting with file browsers. Seriously, people should not see a blank square when they are copying or otherwise manipulating a key.
Further, there should be write-once devices that allow us to add keys and other identity info without worrying an attack will subvert that data.
Re: (Score:2)
If you do not understand what you are doing you do not get security. There is _no_ way around that. "Cryptographers" are not to blame, you own intellectual laziness is. PGP/GnuPG is quite usable for normal users, but it may take a few hours of reading because unless you understand the mechanisms, they are are worthless. If you insist on having a GUI that does it all for you with a click, you get exactly the security level that click is worth.
Re: (Score:2)
That is exactly the attitide that keeps personal cryptography in the usability dark ages.
Congratulations, you're personally helping to reduce the security of billions of internet users around the world.
Re: (Score:2)
It is not an attitude, it is a description of facts. The attitude is on your side. Things should be as simple as possible but not simpler, because then they break. You want them simpler than possible. Just look at the last 20 years to find countless examples where "security" was made simple, including crypto. They all turned out out be worthless, including the SSL-certificate system, Skype encryption and many others.
Hence what you advocate not only fails to make people secure, it also tricks them into think
Re: (Score:2)
The chain of trust is broken. This because today a certificate is only authorized by a single source, not by several. In addition to this the model has the flaw that it does not easily allow a point to point scenario where only two parties are involved.
I like your implication. Often there's a legal requirement for multiple witnesses, such as the Hobbit's "10 witnesses signed in red ink", or in real-world cases, things like US treason or Sharia laws. Seems like this should be something that computer trust mechanisms should support as well.
We are assuming that the chain of Trust is reliable, all the way up because most top-level certs are well-known organizations, but we also know that the mechanism can be subverted. Maybe it's time for a "web of trust", in
You can't break what never worked (Score:2)
The chain of trust has not been broken. There was never a chain of trust to break.
The global internet has no chain of trust or secure* encryption technologies. We have, at best, a series or half-hearted attempts which make it difficult or minor private interests to intercept communications. But we have no-way whatsoever of dealing with NSA sized, centrally managed state backed and internet wide surveillance and control.
The CA system is by now a farce, and a default means of breaking security. The Web of Tru
Re: You can't break what never worked (Score:2)
Bitcoin is not an authentication mechanism. If you can prove that a CA is signing bogus certificates for intelligence agencies please do so - nobody had been able to show this so far and it would move the debate forward at a critical time.
Re: (Score:2)
Bitcoin is an authetication system for bitcoin transactions-- moreover a distributed one by default. The emergence of a small number of professional mining blocks mitigates this somewhat however.
I'm not a fan of Bitcoin the currency. But the methods it uses show up just how primitive most of the default security structures of the modern internet really are. We need to base a secure web, in particular critical elements like public keys, on the kind of distributed, t
Re: (Score:2)
Bitcoin is an authetication system for bitcoin transactions ... But the methods it uses show up just how primitive most of the default security structures of the modern internet really are.
Yes, +1000. Oh, if only I had mod points.
Both X509 and the "web-of-trust" are bloody terrible. Out of the two X509 is marginally better. If you are dealing with a shop unknown to you, X509 does give you a small amount of confidence their web sites cert is controlled by them. A GPG key signed by 100's of people you don't know doesn't. Unfortunately SSL then weakens this to being almost useless by not creating a new trust relationship with that store's cert, and ignoring the X509 PKI infrastructure from
Re: (Score:1)
"If you can prove that a CA is signing bogus certificates for intelligence agencies please do so - nobody had been able to show this so far and it would move the debate forward at a critical time."
Why would you have to show this? They HAVE been shown to sign bogus certificates for their own profit. So we have no reason -- none, zero -- to think they would not do it for other reasons too.
Re: (Score:2)
"The chain of trust is broken. This because today a certificate is only authorized by a single source, not by several. In addition to this the model has the flaw that it does not easily allow a point to point scenario where only two parties are involved."
The "web of trust" has always been broken, because it was designed broken. You have no choice but to trust Certificate Authorities, for example, but CAs have proven themselves over and over and over again to not be trustworthy. Sometimes in rather blatant ways.
Some CAs were caught issuing multiple certs to the same domain. Even worse, some were caught selling the SAME cert to multiple domains. And so on.
The problem is the same as it always has been, everywhere: people.
Re: (Score:2)
That is complete Nonsense, you have no clue how the web-of-trust works. Anybody can create a key with any name+email in there they like. What gives it trust is that other people sign the key.
For Erinn's key, one possible way to do this is:
1. Attend a talk by Roger Dingledine
2. Get a Business card from Roger
3. The business card has the fingerprint of Roger's key. Download and compare.
4. Erinn's key has a signature from Roger. Verify.
After this, you have a trust chain and unless Roger has been coerced or is a
Re: (Score:2)
Do you really know, he's the real one? he's handing out correct cards, nobody tempered with? Do you watch the cards all the time, so nobody could swap them, when you look away for a moment? You need to max out your paranoia.
Re: (Score:2)
He does not need to be the real one. That he is the same guy I met more than 10 years ago is enough. And at a talk he gives, chances are somebody in the audience would recognize a swap. Swapping the cards also has a high change of being detected.
This really is not about making absolutely sure, it is about detecting attacks.
Re: (Score:1)
Probably the NSA or similar agency finding PGP a PITA to crack and want people to move to something they have control over.
x.509 WTF? (Score:5, Insightful)
The CA model for X.509 certificates has been shown to be utterly broken for protection against intellengence agencies, they clearly have both access to some of the private keys of "trusted" CAs as well as the leverage to have "trusted" CAs issue arbitrary certificates in their home jurisdiction. There is no way in which this would get better by switching to X.509 compared to PGP.
We have already have plenty of malware with valid signatures backed by trusted CAs using stolen keys etc, check stuxnet/duqu for instance.
Now, I know it can be hard to bootstrap a PGP web of trust, and there is certainly plenty of work to be done there to make it easier and user friendlier. But chucking out the one piece of actually working low-level technology for real security in favour of one that is utterly broken, and has been shown to be broken for years, is just plain stupid.
Nice (Score:2)
Re: Nice (Score:2)
Re: x.509 WTF? (Score:5, Interesting)
The thing is, you're wrong and your own post shows that.
Firstly, we have no evidence of any CA being compromised by intelligence agencies despite the obvious appeal to them of doing so. This is remarkable. Despite the huge number of Snowden documents so far none of them have even hinted at compromise of the CA infrastructure. What we have seen a lot of discussion of is ways of circumventing it by stealing private keys directly from end users, and doing MITM on non-SSLd connections of which there are plenty.
Nobody can rule out that some CA is in fact minting false certificates for intelligence agencies. But so far nobody has presented any evidence of it.
Your Stuxnet example proves my point and disproves yours. They didn't use a false certificate there - they hacked the end user (a hardware manufacturer) to obtain their private key. Well guess what, you can steal PGP keys in the same way, nothing magical about that.
Re: (Score:2)
Indeed, it makes little sense to compromise a CA because when it eventually discovered (and it will be, either by the public or by other intelligence agencies) every dodgy cert you minted will become invalid overnight. Stolen keys are also much more deniable, much harder to trace back to the agency that stole them.
Re: (Score:2)
then it's just too late. and how many people will actually remove a compromised CA from their CA list? like 0.1%?
Re: (Score:2)
Re: (Score:2)
transparent updating is another issue. You grant a program the the right to install arbitrary binary code. And in case of firefox on windows, even with administrator rights (chrome gets it better with user privileges, but the interesting data is in your home anyway).
ASCII (Score:2)
transparent updating is another issue. You grant a program the the right to install arbitrary binary code.
Huh... no.
Certificate update is *certainly not* binary code installation.
First of all, it's not binary, it's a collection of text files (containing base64 data, so not even full ASCII).
And most importantly, certificates are not executable code. They are just static data.
They can be sagely transparently updated without being a remote access risk.
Re: (Score:2)
I am talking about firefox updates.
Re: (Score:2, Insightful)
Of course attacking SSL on the protocol level is by far more useful, since you can just silently sit there and eat all the "secret" data, instead of having to actively MITM particular connections.
But do you really think there is a single US CA out there that would say no to a national security letter requiring them to issue a torproject.org certificate if they actually needed it? Especially given how Joseph Nacchio was treated for resisting voluntary assistance to the NSA? Or that the Chinese ones wouldn't
Re: (Score:3)
NSL's request data. You're probably thinking of a court order. And of course the answer is no, they'd follow the order. But what makes you think a person taking part in the WoT would refuse a court order where a CA would roll over? Jail time sucks the same for both. The idea that CA's are uniquely vulnerable doesn't really m
Re: (Score:2)
The WoT lets you resist this scenario. If you have multiple paths, then you can force your adversary to point guns at multiple people. Those people might not all be as easy to find or intimidate as one person (they might not all be in the same jurisdiction) and also, each one of them can more safely spill-the-beans without getting blamed. "I'm not the one who leaked that
Re: (Score:1)
I'd like to think the compromises of Digicert and TurkTrust were by governments, because if they weren't compromised by a security agency with lots of money, hackers on the payroll and silly laws requiring encryption keys the alternative is that Billy nobody did was using the bad certificates and that CAs can be compromised by anyone.
It's illegal in the UK to tell anyone if you have compromised your company and provided a private key to the police or security agencies and they can request any encryption key
Re: (Score:2)
on the other hand ... how often do your contacts look for revocations of your key? Most people do not ever refresh their keyring.
x.509 *iz* b0rked!! (Score:2)
Firstly, we have no evidence of any CA being compromised by intelligence agencies despite the obvious appeal to them of doing so. This is remarkable. Despite the huge number of Snowden documents so far none of them have even hinted at compromise of the CA infrastructure.
x509 has already been b0rked numerous times. Just look at the slashdot archives: there are a number of case where:
- stolen keys were used to sign malware
- a "legit" certificate was obtain from a CA for nefarious purposes.
(by "legit" I mean that it's a valid certificate signed by an official Certificate Authority. It's 100% legit as the identity signed there is completely wrong. Like a malware compagny getting a certificate issued for "Microsoft" by some obscure CA which isn't the one Microsoft is using, and
Re:x.509 WTF? (Score:4, Informative)
Never mind that we don't need to switch to X.509, we can add X.509 certs to OpenPGP.
When you think about it, in the web-of-trust model centralized certificate authorities are just entities that a lot of people happen to trust; there's absolutely nothing stopping us from taking X.509 certs and adding them to OpenPGP keys as just another type of signature and the X.509 certificate providers have no (technical) means of stopping people from doing that.
I've argued before to the Bitcoin community that what we really want is a "best of both worlds" solution where we support centralized certificate authorities via X.509 and OpenPGP for applications with low security needs while maintaining the ability to use the WoT for those applications with higher needs. It's totally OK if average user just uses software that automatically checks the X.509 cert or OpenPGP signature issued by a certificate authority when they download some wallet software or make a payment to someone. Meanwhile advanced users, and particularly developers, can check all the signatures, WoT, certificate authority, whatever, to be sure they have the right software when they're downloading "clean" copies for their Bitcoin exchange, or making high-value payments.
What really amazes me is how people seem to think this is a binary decision, centralized PKI or WoT. It's not at all! Heck lots of organizations already apply the central certificate authority model with OpenPGP - just looks at all the Linux distributions that have master OpenPGP keys to sign packages. That's a certificate authority, but with OpenPGP technology.
Mike Hearn has been lately going on a bit of a war-path trying to push Bitcoin into a model of blind reliance on singular centralized PKI authorities and frankly it's just nuts. He's even gone as far as to strongly advocate that we don't even support multiple X.509 certs for applications, which would at least require an attacker to compromise more than one certificate authority. This is particularly crazy when at the same time he has advocated that websites, e.g. bitcointalk, reddit, slashdot, etc. sign cryptographic certificates linking usernames to identities. The idea here is if I want to pay "IamTheRealMike" my wallet software could have, say, slashdot's certificate pre-loaded and trusted, and then I'd tell it to give the funds to that username. But why would I do that? I want to pay Mike Hearn. I happen to know he's "IamTheRealMike" on slashdot.org, and "Mike Hearn" on bitcointalk, so obviously if it's a non-trivial sum of money I'd want to be able to check that both sites have stated that they're the same person, and maybe I'll check WoT too, and, say, his countries passport office. It just makes so much sense to give people options like that, but we're rather mysteriously seeing resistance. If anything, I think it's kinda insulting to the professionals in this space, both developers and finance people, to tell them "We're all too stupid to learn about anything more complex than trusting the magic green checkbox". If I was running a big Bitcoin-related business I sure as hell would want more assurance than that; when I'm writing software used by others I sure as hell want more assurance than that.
Anyway, in the OpenPGP world I'm really excited to see KeyBase [keybase.io] pop up. It's not perfect - the functionality probably should have been just an add-on to OpenPGP rather than a website - but it's a great step in the right direction of giving flexibility and user-friendlyness to the WoT. It also works great as a local application, so if you choose to you aren't relying on their website/service for the guarantees it provides.
Re: (Score:2)
Regarding binary and source code distribution, there's nothing to fix really - both source and binaries are already protected by X.509 certificates by virtue of being hosted on SSL-using websites: https://www.mail-archive.com/b... [mail-archive.com] Secondly PGP keys are hosted on https://bitcoin.org/ [bitcoin.org] which gives users a manual way to get them securely, verified by X.509. We should check that certificate pinning is being used, and it'd be good to have a second code repo beyond github, but we're in pretty good shape already. I
Re: (Score:2)
Regarding binary and source code distribution, there's nothing to fix really - both source and binaries are already protected by X.509 certificates by virtue of being hosted on SSL-using websites: https://www.mail-archive.com/b... [mail-archive.com]
This in no way prevents the server from being compromised and serving a malicious installer package. It prevents a MitM attack from compromising the package in transit, but that's it.
Code signing and SSL are protections against completely different attacks, and are not interchangeable.
Re: (Score:2)
Re: (Score:2)
"The CA model for X.509 certificates has been shown to be utterly broken for protection against intellengence agencies, they clearly have both access to some of the private keys of "trusted" CAs as well as the leverage to have "trusted" CAs issue arbitrary certificates in their home jurisdiction. There is no way in which this would get better by switching to X.509 compared to PGP."
Exactly. Ultimately the problem -- as I have mentioned elsewhere in this thread -- is not so much the encryption, but people. Sooner or later it comes down to trusting somebody. A person. And they have repeatedly shown to not be trustworthy.
If there is a way to get people out of the equation altogether, that would be a huge boon.
(By the way: if she thought it was important, Erinn could have written a script to periodically access the files in question and verify their contents with a simple hash, then
Checksums? (Score:1)
Isn't a checksum of a file posted to a mailing list replicated enough where it can not be manipulated, so it avoids all the trust problems currently found with attempts to sign binary files?
Seven people who hold the keys. (Score:2)
Re: OP's a fucking idiot. (Score:2)
So can you find a path to the genuine keys through your personal web of trust?
Re: (Score:1)
I don't want to defend his rudeness (I don't like it), but when you don't find the answer in your WoT you should notice it and extend it appropriately.
Many people here understand what it means to trust a CA and we all know how big companies are treated in the US (they are not even allowed to speak about it and I always assumed that such situation you can find only in the most shittiest countries in the world).
I still prefer to trust my WoT because it is ME who gives trust to others and not some people
Re: (Score:2)
Extend it how? Facebook has the densest social graph in the world and they think two strangers can reach each other within 4 hops, mostly. But that's what it'd be if "everyone in the world" (or close to it) was a part of the WoT. This will never happen or even get close. So in practice you probably don't have a great way to extend your WoT in this way unless you happen to be a part of the very small security geek community, and even then, it's probably not easy.
Re: x509 code? (Score:2)
You're sort of getting close to what the certificate transparency project does.
The dilemma is the very design of a certificate (Score:4, Insightful)
Why do you think the Russians went back to typewriters? Anything electronic can be snooped, the level of compromise so great that it is nearly impossible to protect against attacks.
So what can you do? Set up multiple checks across the globe, out of control. If there is discrepancy, then consider yourself compromised or a target.
The fact that the PGP fakes have shown up means that there have been man in the middle attacks.
Your personal router has a back door? Probably if it is commercially sold.
Your internet provider has been backdoored? Most likely, or is easily done with a device brought in the front door with a security letter.
Your local internet backbone has an intercept? Definitely
You can be served faked certs and ip addresses, fake windows updates? Proven
Commercial routers have back door? Proven, the very fabric of the internet is polluted.
You have to containerize your internet now via VPN, and those keys can be secured in the U.S. with a security letter. With quantum computing, it can be broken.
Not broken, just fud-ed (Score:2)
What if the intention isn't on cracking it but just on spreading FUD?
People are pissed off right now. That Snowden thing just isn't going away and people are looking into encrypted email options. Even people who never thought of using pgp (or regarded it as something for paranoid conspiracy theory nuts) would use it now, if it just came as an easy clickable option.
If you're some government agency, that doesn't look desirable. To make things worse, it's a web of trust, one of these pesky decentralized
Re: (Score:2)
Quite possible. The key itself is not even an attack. Anybody can make a key for Erinn and publish it. Takes a few minutes and no hacking or anything like it at all. The only problem is that people are unwilling to invest the few hours it takes to understand PGP and the web-of-trust and are complaining about this non-attack because it breaks their completely worthless "security procedures" (i.e. "download key with matching name from keyserver"). Security is hard. It requires understanding something. Most pe
All SSL certs need to be public (Score:2)
Google is on the right track with their "certificate transparency" scheme, with a public log of all certificate generations, but, like most Google schemes, it involves Google as a central party. The public log needs to be decentralized.
We know how to do this. The Bitcoin block chain is just such a decentralized public log. The Bitcoin block chain could be used to secure the cert log, by putting the Merkle tree into a Bitcoin transaction every 10 minutes or so. Then there can be multiple copies of the pub
doh? (Score:3)
obtaining a forged certificate is much harder than simply uploading a fake PGP key,
Not for an intelligence agency.
would be strong evidence that an issuing CA had been compromised: something that seems plausible but for which we currently lack any evidence.
Uh, no? Short memory? We already had CAs compromised. Was it last year or the one before, I'm not sure.
Re: (Score:2)
That is BS. Uploading a fake PGP key takes 5 minutes and no approvals from anybody and anybody can do it. Getting a fake certificate at the very least requires a plan-of-use and a sign-off for that plan. Say a few days of work.
Define "fake" (Score:2)
This are keys issued in a person's name. Names tend to not be unique, many people share the same given name(s)/surname combination. The same accounts for company names, where it's even easier to get a key with the exact same name as anyone can register a company in the same name as the company they want to copy.
Those keys are perfectly valid. CA's do not have to be compromised for this kind of "attack", they do their job and issue keys in the actual name of the applicant. It can't be that they refuse a key
Re: (Score:2)
Keys (and certs) contain email addresses.
Re: (Score:2)
Of course you know exactly which e-mail address belongs to which name, so it's no problem for you to recognise a fake.
Re: (Score:2)
Another one that does not get it: These keys are not "issued". They are self-generated and the one generating them can put in whatever they like. The "fake" here is that somebody put in Erinn's email addresses, and they are unique. The effort for faking these keys is however almost zero, anybody who actually looked into the PGP documentation knows that the name in the key is just there for convenience and is not a security feature.
For CA generated keys, you have more in there than a name. In fact there are
Re: (Score:2)
And how am I, a simple end user, to know that the Microsoft that the key says it is issued to (or who generated it), is not the same Microsoft that built the Windows the computer runs? Because the mailing address in the key is different? An e-mail address is different? I don't usually know which one is the "real" one. And that's about a well-known company, not an obscure software developer that I never heard the name of.
Re: (Score:2)
You have to invest some effort. That may look like really bad design, but it is a limitation of this physical reality: If you want to verify the identity of some entity, you have to do it yourself. Any automated mechanism can and has been compromised. Anybody you pay for doing it for you can be compromised.
But you are right, for Microsoft certificates it is basically impossible to verify certificates, as there have been "real" ones made by ex-employees around. Your chances of verifying Erinn's PGP key relia
S/MIME is worse (Score:2)
you have to trust big authorities. You DO trust many by default. Everyone can issue wrong certifcates and you will not notice it, you are not required to review new certificates for them to work.
And you CAN revote wrong PGP key. There is an option so sign them with "I DO NOT trust". Just do it. Do it from your right key, get other people, which verified you, to do the same.
How to find trust paths? (Score:2)
I know several webinterfaces ... but how do you do it yourself? Do you need to scrape the whole web of trust, until you have all keys on your keyring to do then a search on the graph?
Ridiculous "solution" (Score:2)
The "obviously stupid" candidate, maybe. Surely that idea doesn't stay on the table for more than a second or two before everyone starts laughing.
Whatever it is that you do, in order to be able to trust an X.509 CA, you can do the same exact thing to trust a PGP CA. Go meet them.
The difference is that if you're not quite able to do that (as is the case for many many people; i.e. nearly everyone; I have
Toward a solution: Increase encryption rate (Score:1)
The first step toward a solution is probably to have many more people use encryption. Only then will the web of trust thicken enough. Then there will be interest in developing more advanced protocols and software.
That first step is doable: Enhance (or fork) Mozilla Thunderbird as follows. People will learn that if they use Thunderbird, and their friends use Thunderbird too, the mail exchanges will automatically and transparently be encrypted, and there is nothing the users need to learn or do differently.
Re: (Score:1)
To automate generation of a web of trust, the mail client may compute an "auto-trust score" based on how long you have been using the same key, and how many times you have responded to responses to encrypted messages. Extend the keyserver protocols to make room for such auto-trust score records. Of course, this requires permission from the user, since it publishes that the two do communicate.
Another vector: Have the mail client show the user a QR code (or similar with enough capcacity) containing the publ
Why Google? (Score:1)
Re: (Score:2)
What's with all the Jew talk today?
The topic brings out the conspiracy nuts.
Crypto.
Crypt
Freemasons
Jews