SecureD Futures (v2.0)

[Adam Wilson]

On 05/29/2018 11:29 AM, Brad Roberts wrote:
> 
> On 5/29/2018 1:57 AM, Adam Wilson via Digitalmars-d wrote:
>> One of the pillars of SecureD is that ONLY safe, well-known, 
>> algorithms are presented. If reasonable we will only present one 
>> algorithm for a specific purpose. If there is a good reason to add 
>> more than one algorithm, we will.
> 
> One of the pillars of crypto is that eventually a problem will be found 
> with every algorithm, it's just a matter of time.  So, having just one 
> available means that eventually the library will be horribly broken. The 
> corollary here is that having a fallback is pretty essential.

Sure. For example, TLS 1.3 supports AES, Camellia, ARIA, and 
ChaCha20-Poly1305 for symmetric ciphers. However, when you look at the 
best-practice recommendations, AES is the clear winner. And when you 
look at what actually gets used, it's AES. AES is the Gold Standard and 
it would take a fundamental breakthrough in cryptanalysis for that to 
change.

But what happens to TLS1.3 if there is a fundamental breakthrough?
- ARIA uses an AES derived substitution-permutation network.
- Camellia uses the same S-box that AES does. (It was an AES contender)
- Poly1305 for ChaCha20 directly uses AES in it's PRF.
Which algorithm do you switch to? Anything that breaks AES can also be 
used against these other algorithms. In this case, ChaCha20 is probably 
the best answer, but only if you apply a different MAC to it.

It's a good thing that a fundamental breakthrough in cryptanalysis is 
unlikely in the foreseeable future. Of course, that's what we told 
ourselves before 3DES and Differential Cryptanalysis.

I don't disagree with you. But the overwhelming cacophony of choice 
presents it's own issues. (See: The Paradox of Choice) SecureD v2 could 
easily support these ciphers, and I don't really have a problem adding 
them for the purposes of compatibility. But the default is going to be 
AES for the forseeable future. The design premise of SecureD is to make 
the the safe defaults easy and everything else hard.

In cases where there are known weaknesses SecureD does intend to support 
multiple algorithms, but usually only two, for example SHA2 potentially 
suffers from the same weaknesses as SHA1, and as a result SecureD v2 
will be getting SHA3 support whenever OpenSSL 1.1.1 drops. But it's not 
going to add things like Whirlpool or Skein.

Or RSA versus ECC. I am considering adding Curve25519 support to v2, but 
with NSA/NIST deprecating ECC altogether (as it is less resistant to 
quantum computing than RSA, see: 
https://en.wikipedia.org/wiki/Elliptic-curve_cryptography#Quantum_computing_attacks) 
it may be better to wait-and-see what comes of the work being done on 
quantum-resistant public-key cryptography. The new Supersingular Isogeny 
Diffie-Hellman (SIDH) looks like a strong contender, but nothing 
implements it, and it's way too new to put any trust in it yet.

-- 
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;