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.
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.