PGP is an alright protocol but I cannot recommend gpg for daily use by non-technical users. They make it extremely difficult to use long-term and simple issues like gpg-agent running as a background process become controversies where they could have just made it optional.
Honestly,I think it's an alright piece of software but the project became the way it is as a result of the massive gnupg adoption in the *nix world and lack of competition.
If it isn't cross-platform and user friendly,it shouldn't be used by the average citizen. As much as the cryptonerd in me likes this news,Gnupg as it is shouldn't be used for official matters. Most lawyers and judges would struggle to use it.
My employer requires that emails with certain types of content be sent with a GPG signature. I spent a few hours today figuring out the best way to do it. First, I used the CLI to < echo "..." | gpg --clear-sign > and paste that into Gmail (web), but the receiver didn't know how to verify the signature (Mac Mail with GPG Tools).
Eventually I settled on Thunderbird with an add-on. It took some googling because the add-on defaulted to "Junior" mode. Eventually, I was able to send emails both signed and encrypted.
So, the issue to me is that there needs to be a standard that can be easily integrated into commonly used communication tools, like Gmail, SMS, etc.
Private key portability is also a problem. I have a USB-C yubikey, and it works on my laptop and my phone. Once USB-C becomes common, maybe carrying your private keys around with you will be much easier.
Ask if they'll let you send text and zip files as attachments instead. You just save the file, use the encrypt file option, an encrypted file is generated, and attach that to the email. The receiver does gpg -d (file). It's how I use it. Let's me ignore most of GPG complexity and its potential risks. Also, I use zip with obscure names to hide content type.
Just make extra, extra sure you click the encrypted file in attach dialog, not original. It can help to put them in different directories.
I meant in general if the software isn't cross-platform and user friendly,it shouldn't be used for official purposes since a significant amount of citizens would be forcibly excluded. Gnupg gets the job done and is cross-platform but isn't user friendly.
>If it isn't cross-platform and user friendly,it shouldn't be used by the average citizen
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.
This is the exact attitude that has gotten us where we are today (as in, pervasive bad security). "Do what you've always done, you'll get what you always got."
I disagree. It is possible to make decent, good, and perhaps great security that is easy to teach and not too inconvenient that users will rebel. I think it is unreasonable to keep someone from using GnuPG in a legal fashion because average people cannot use it. You will never find signing software with sufficiently bulletproof security that average people can use. To suggest such also implies that average people need to regularly perform notarial acts, which I think is imaginative.
The guy in the cubical next to me made a comment along the lines of "security is always inconvenient and hard" earlier today. And he's just expressing a widespread attitude, but I think it's not (or at least doesn't need to be) always true. If we do it right, we can make simple systems built from the ground up on fundamentally secure principals.
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.
I'm responsible for managing 30+ firewalls at my bank. If any one of them is incorrectly configured an attacker could get into our network and all that would take is a tiny incorrect detail on one line. And I'm keenly aware that I'm a mortal human being and very possibly could make such a mistake.
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.
That's another good point, the reason the bank employs people to pore over every detail is because they're liable to make sure it works right. If I say "send $1000 to account X" and the $1000 vanishes, that's their fault.
But if something goes wrong in cryptocurrency, whoops, guess I should have just known better.
Banks can run on systems like NonStop we have gotten to five 9's reliability with components simple enough to formally verify. Most people's money doesn't get robbed. If they do, they can mitigate it with $50 max reporting it quickly. They can also stop payment if a provider screws them over. Their stored money is worth about same day 2 as it was day 1 since it's an actual currency aimed at stability. Compare that to cryptocurrencies with volatile value, inefficient systems, lower volume, more hacks, and more closed exchanges.
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.
> Compare that to cryptocurrencies with volatile value
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).
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.
> 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.
> If we do it right, we can make simple systems built from the ground up on fundamentally secure principals.
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.
HTTPS is a bad example because it's historically been hard to implement (and often expensive too), defaults to insecure protocols and ciphers on many servers (with clients still supporting insecure versions), and end users have since been conditioned to ignore SSL errors due to self signed certs etc.
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.
You're talking about the server/admin end. For users,a properly configured https site shouldn't cause any trouble. Even on servers,I'd say it's always been fairly successful if you consider the successful setups.
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.
Cross platform is important for official matters because allowing a platform specific tool means the government,legal community and fellow citizens are also expected to use that platform to interact with content made or consumed by that platform specific tool.
Sorry but you're still missing my point (though I didn't really make it all too clear).
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).
"Bulletproof" is a loaded term,something that is bulletproof may not be sulfiric acid proof for example.
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?
Why won't we ever have cross-platform and usre friendly signing software that also has bulletproof security?
We already have many programs that are cross-platform and user-friendly while also addressing way more complicated use cases than cryptographic singing.
Honestly,I think it's an alright piece of software but the project became the way it is as a result of the massive gnupg adoption in the *nix world and lack of competition.
If it isn't cross-platform and user friendly,it shouldn't be used by the average citizen. As much as the cryptonerd in me likes this news,Gnupg as it is shouldn't be used for official matters. Most lawyers and judges would struggle to use it.