There is a small correlation between the effects of security and simplicity. This use of complexity for its own sake (See ETH, Core etc) will not add and may remove security. Likewise, simplicity for its own sake will not add security.
For the most part, the functions of simplicity and security are perpendicularly polar. This is, although there is a feedback effect one aligns with a proverbial X and the other, a proverbial Y axis. The real issue also comes to a definitional framework. I speak of simplicity in a Chaos/Complexity Theory framework.
Simplicity adds to security in human system interactions. Complex systems (in general) are more prone to catastrophic failure. That is they are more brittle. To understand this, you need to think how a brittle material fails. High-carbon steel structures can be remarkably strong, but if they exceed their threshold only once, they shatter. Low-carbon steel will bend at a lower threshold, but can be reformed. If the strength of a brittle material is sufficiently high, it does not matter that it can fail catastrophically, as the conditions will never be met.
As in materials science and metallurgy, some of the most robust systems are hybrid composites. This is a combination of elements and methods. This in itself is a form of complexity, but in the sense that simple and complex systems are enmeshed.
The same applies to information systems. Brittle but strong systems can survive extremely well as long as they are sufficiently resilient to have a capacity to withstand any attack.
The flaw here is in software. Although we pose an NP infeasibility issue, software validation can be of great use. It also poses a cost. A verified system (such as in the old rainbow A tables) can be extremely resilient. The cost of such a system is however extraordinarily high.
All software is complex by nature. So the issue is not of pure simplicity. Even in the face of open-source code, software is not evaluated. It requires a level of complexity to account for the failings in software. Malcode, bugs, vulnerabilities, etc all account for the major flaw in any system design. To account for this correctly it requires the introduction of multiple systems. This reduces simplicity through introduced complexity, yet adds to systematic security. An example is given through an introduction of dual layers of firewall technologies with separate vendors such that neither ever suffers the same software flaw (and all firewalls have had compromises). Another example is the use of multiple anti-virus engines (such as an email gateway with one product and a separate engine on the email server and data store).
To contrast this, the increase in security from multiple systems is impacted through the addition of further human factors. More systems and complexity make it more difficult for a single individual to run a security system (e.g. firewalls or AV) as they require knowledge in multiple platforms and thus spend less time on either platform. This can also lead to an introduction of more people. Two specialists can be used (1 for each vendor). This allows the individual to specialise in a particular area again, but also takes interaction with the other person (which was previously achieved by one individual).
The requirement to act in concert adds stress points to the security solution making it more brittle. This can be tempered. Training and drilling staff leads to a team approach where the effect lies in an individual team rather than a group mindset. This tempering adds to security. This may (and generally does, if you exclude the cost of failure) increase costs (esp. as contingency costs are not attributed to project costs).
Training in itself is a source of complexity in its development. The paradox is that this addition of complexity can create a simpler and more robust system.
We can see this (simplicity) in regards to Bitcoin (BCH) when compared to so-called valueless blockchain offerings (ETH, EOS):
Bitcoin: global, fast, P2P electronic cash
Blockchain: decentralised digital ledgers and settlements systems that act as a public ledger system. Incorporates the ability to have dApps when sharding is solved, and the P vs NP problem is shown to not be an issue allowing the world to universally and immutably create censorship-resistant speculative and slow-kitty apps that move from fad to fad in a generalised glut of waste and value destruction. Allows ICOs and other illegal security offerings designed to ponzi your way to a lambo to get away in, before the government comes for you and your highly permissioned “permission-less system”
“There is a delicate balance in making security work.” There is a point solution that makes a balance. Security is a dynamical (spelt correctly) system. Although point equilibria exist, they do not exist in time.
Nodal minima do exist — sometimes for long periods of time, but these require tuning and updates.
“Black boxes are prone to be vulnerable.“ Not necessarily. There are many B2 and higher (on the old rainbow-table US-classification scheme) systems that can operate as a black box. These can be fit-for-purpose designed systems. For instance, you can even create a secure software-based system using vulnerability-prone software.
Many systems are black boxes — this is not the sole cause of security issues. In addition, open source also has just as many flaws.
Working on useless optimisations seems like a valid goal to some, but, we should understand that “finding optimal network-aware sharding strategies is unfortunately an NP-complete problem.”
NP-complete problems can be solved, but, if they can be solved efficiently, it means that P=NP, and this also means that other NP-complete problems (discrete logarithm problem) would also be at risk. This would make ECDSA easily reversed.
Luckily, it is incredibly unlikely that P=NP. Sorry ETH.
