You will never have cross-platform and user friendly signing software that also has bulletproof security. Let the people who are skilled enough to know what they are doing continue using GnuPG.
Example: Think of the simplicity and security of a cryptocurrency transaction as compared to a traditional bank. The crypto transaction is so much simpler, easier, and much much more secure.
I work in a bank, and there are so so many moving parts all with a myriad security weaknesses all chained together to make a transaction happen. First there's the web portal where the customer initiates the transaction. This is HTTPS which has well known flaws and so many things that could go wrong. Then his transaction goes into a SQL DB in the bank intranet, could be attacked hundreds of ways, then scripts process it into an ACH file, encrypt it with PGP, and SFTP it to the Fed. Those PGP keys were exchanged through unencrypted email, and the SFTP password was exchanged over the phone. Then the Fed uses a similar process to send it on to the destination bank, each step adding additional weak points.
The cryptocurrency transaction, on the other hand, is a well defined mathematical problem with no ambiguity, few variables, and a few easy concepts to understand. Yes, there are a handful of things that could go wrong, but they are well define and well understood. In comparison to the bank transaction, the whole thing is just so simple, beautiful, and easy.
Or was the parity wallet multi-sig attack something that most lay-people knew about as a risk before it happened?
IMO that's more of a problem with smart contracts than with cryptocurrencies as a whole. if you allow anyone to write code that controls millions of dollars, there's going to be ten different implementations and a hack in one of them is virtually guaranteed. on the other hand if the multisig mechanism is part of the network protocol, there's only 1 implementation which will be better scrutinized. even if there was a bug, at least the intention is clearly conveyed and can be fixed with a non-controversial hard fork. see: bitcoin's block reward integer underflow hack vs ethereum's DAO hack.
Or the network could be compromised through any of hundreds of other ways: email, USB stick, insider attack, etc. etc. etc...
And that's just my bank. Any given transaction will go through several all with similar weak points, and some of them with firewall admins even less competent than myself.
To me there's just no comparison. The scale of failure modes or attack points for a bank is way way bigger than any cryptocurrency. The reason it works at all is banks have well-paid guys like myself pouring over every detail and keeping things working.
But if something goes wrong in cryptocurrency, whoops, guess I should have just known better.
What would be an example?
From my own experience it seems easy until you actually get into the details.
Pgp is an ingredient, it’s not the recipe. You can build a lot of great things out of it, but I’m not sure why you’re attacking letting notaries use it if they want to. It’s a perfectly adequate system that requires attention to detail, just like any alternative.
Of course you're right, real life gets complicated and messy, and things are never as simple as it seems they should be. Nevertheless, I do believe we, as the technologists designing and building the systems that the world runs on, should put more careful thought into making them fundamentally secure and easy to use.
Nothing wrong with letting notaries use PGP. I think that's great.
A public benefit or nonprofit setup for a bank with strict rules in a country with strict rules is way more trustworthy and efficient than the average cryptocurrency. The tech is also better since an ACID key-value store plus the kinds of credit and smartcards we already have is all you need for majority of activity. Stuff like FoundationDB hits ridiculously-high transactions-per-second with strong consistency. Banks already have lots of methods for catching fraud. A simple, online bank will have less go wrong technologically, legally, and so on since every part is field- and court-proven.
I was comparing the network, protocols, and interfaces that make the transaction happen, not the currency itself. Please don't take this as a endorsement of cryptocurrencies, because they do have problems.
Even with improvements you mentioned, there is just no comparison between the technical and mathematical simplicity of the cryptocurrency transaction as opposed to a bank transaction.
The blockchain was a truly genius innovation. It's that kind of out-of-the-box thinking that I believe we need more of and applied to more varied problems (and obviously not blockchain again, because that would be thinking in the blockchain box).
A bank transaction is this:
MoveMoney(FromThisAccount, ToThisAccount)
One with decentralized checking is this:
MoveMoney(FromThisAccount, ToThisAccount) PostToLedger(CurrentStateorChanges);
On other system, CheckChanges(CurrentStateorChanges).
That's it. All the extra stuff is for extra requirements or overhead from traditional, bank designs. It's not requirements for centralized banking. You can do the basics of banking, with crypto, on 16-bit microcontrollers on smartcards. You can do the ledger in memory with snapshots for persistence. You're talking load and store instructions plus some I/O. Super simple. The stuff proof engineers are mathematically modeling, implementing, and verifying down to the assembly is much more complicated than this.
Now, with cryptocurrency, it starts with some pretty math. That turns into a way more complex implementation than what I just described. Inevitably because their protocols are intrinsically more difficult than centralized protocols that just publish ledger for decentralized checking. Even the tools for verifying them are more in infancy than those for traditional systems. Then, there's the mass of code they use like Linux to operate. Then there's developers that can make changes. There can be lawsuits forcing things to happen. A lot more than math goes on with the cryptocurrencies even though proponents talk like it's just math that you can trust.
Now, someone might say their complexities aren't nearly as bad as traditional banking or weaknesses are worth it. The former might be true, but nobody has proven the latter given a centralized non-profit can do almost everything better. I haven't even seen opponents of traditional banks attempt to do better with centralized design. I have seen for-profit companies like PayPal, Western Union, Venmo, and an online bank in Go language vastly improve on the situation with clean-slate designs getting lots of market share away from bankers. Had idealists done that, they'd have millions to billions to spend on experiments like cryptocurrencies plus made a huge, positive difference in people's lives. That's because they are actually using the centralized alternatives based on traditional currencies. Can you imagine how much better they'd be if they were public benefit or non-profit companies with stuff in their charter and agreements protecting the customers? And that leverages existing laws that lawyers understand well.
Idealists opposed to traditional banking have done that, with significant success. Hence, public benefit banks, public banks, and credit unions.
People take good security for granted. Look at HTTPS,all you see is the green lock as it's interface telling you the connection is secure.
Thankfully things have been improving on all fronts in recent years, but I'd still say HTTPS is a great example of when something that should be simple to use was totally cocked up.
I'm talking about all aspects of it. But you shouldn't dismiss the server / admin end either because if security is too difficult to set up then you can bet a lot of people will set it up incorrectly thus leaving end users vulnerable.
> For users,a properly configured https site shouldn't cause any trouble.
Most users cannot tell if a HTTPS site is properly configured though. And as I mentioned in my previous post, many users have been trained into complatency with ignoring certificate errors due to the widespread use of self signed certs and how browsers will display the same styled error message for that as it would for arguably more serious SSL errors.
> Even on servers,I'd say it's always been fairly successful if you consider the successful setups.
"Successful" in the sense that we have a secure method of transmitting HTTP traffic. However I question whether it's successful with regards to the "user friendly" point you're trying to make when you consider that great many servers were not and still are not correctly set up (eg running insecure TLS cithers, supporting SSL 3, etc). Given my PCI DSS training as well as working with the gambling commission, I've spent a lot of time analysing network traffic and you'd be surprised just how much out there isn't following best practices. Even more worrying is a great number of devices (eg computers, smart phones, network devices, etc) don't even support what should be the minimum security requirements like TLS 1.2.
The "cross platform" bit is completely irrelevant. The user friendly and strong security (there's no such thing as bullet proof security) points are certainly achievable with a little effort.
User friendly design is about understanding user behaviours, UI/UX, etc. It's about designing sane workflows and user interfaces. Whereas writing cross platform code is a technical complication regarding the internals of a particular application. The crossover is between cross platform development and user friendly design is just which UI toolkit you choose to use (ie Electron, Qt, native platform-specific widgets, etc?) and even that is really just an implementation detail rather than a fundamental roadblock in designing user friendly applications.
Thus the requirement for something being user friendly shouldn't affected by the requirement for something being cross platform.
This is why I say the cross platform point is irrelevant. Not because cross platform solutions aren't important but rather because they're not the reason many solutions aren't user friendly (the reason is much more simple than that: they were designed by technical people to be used by technical people).
Anyway, the puropose of a security solution is to reduce risk to an acceptable degree. There are already plenty of apps and protocols that allow for secure message transmission and storage(signal,wire,tls,ssh,etc...) Why do you think GPGs task is special?
FYI -- gpg is just a pgp client.
We already have many programs that are cross-platform and user-friendly while also addressing way more complicated use cases than cryptographic singing.