Negotiation is the most dangerous feature in cryptography. Nobody has ever gotten it right (I mean that literally).
Therefore, in the same sense as Dan Bernstein used to have a design goal of "don't parse", "don't negotiate".
Instead of having protocols that negotiate features, we should have protocols that have simple versions, and the only negotiation that should ever occur is "is this protocol in the set of allowable versions for my local policy".
If a version gets something wrong, like using implicit IVs for CBC, or using a hilariously broken cipher like RC4, the whole protocol should version. RC4 should take you from TLS 1 to TLS 2. Lucky13 should take you from TLS 2 to TLS 3. Want to switch everyone to ChaCha/Poly? TLS 4 it is.
I think it'd have a shot at being better than we've got now. And frankly, better than what TLS 1.3 is doing.
What if something was deployed with (SHA256 P-256 ECDHE-ECDSA-AES128-GCM), which Google promised to support for a long time, and now people want to switch to djb-blessed X25519-Ed25519-AES256-GCM, will the older ciphersuite be an old protocol version that everyone keeps supporting for >10 years?
Same with curves. Nobody really benefits from selectable 25519 vs 448.
Slap some crypto-currency payments on the risks you expose via APIs and charge for the risk.
Yikes. Is that... the state of the art of compiled/machine code AES-GCM implementations? I guess I'll look to NaCl for an AEAD construct...
Handwritten asm still outperforms compiler output by enough to warrant its use in hot functions like AES-GCM.
(NaCl also uses a text-to-text transform system to output asm, although it's written in C and does register allocation too. The important aspect of NaCl is djb & friend's attention to quality.)
The Win64 versions are a little less optimal IIRC, but to be fair Win64 is dumb.
I feel like if you took something like qhasm and extended it to be a full language rather than sort of a hack, you would end up with something really beautiful, like Forth minus the crazy and plus both standard assembly and high level syntax. It could be a better C than C.
and in particular:
https://boringssl.googlesource.com/boringssl/+/master/crypto... and https://boringssl.googlesource.com/boringssl/+/master/crypto...
I don't see how this is any improvement on just writing plain assembler? Apart from the perl-style comments, is this any cleaner than say, some code compiled with yasm?
[ed: I guess what I'm missing is that there's probably more similarities between the x86 flavours and ARM flavours -- but I still think one would need to look at, and understand, the generated assembly for each platform in order to audit the code. So I still wonder a bit about what the gain is.]
Much of the code they stripped is just about impossible to audit.
People talk about writing less C because it's so hard to do right. How much faith do you really have in "many eyes" finding issues in Perl generated assembly?
Looks like LibreSSL has the exact same perl-generating-assembler code.
Just this year I've bumped into two separate security-related networking devices which were stripping out all TCP options except the MSS from the SYN packet . So no window scaling and no selective acknowledgements. This is absolutely crippling to TCP.
In one case the middlebox was next to an FTP server used for transferring huge files all over the world. Just taking that box out of traffic would have given a 5x-10x speedup on those connections. The other was in an LTE core network; in that environment just losing window scaling cuts the maximum throughput to maybe 20Mbps. A bit of a problem when your marketing is promising 100Mbps.
If TCP stacks wouldn't negotiate the connection settings like that, crap like this wouldn't get deployed. It would be obvious that something is horribly wrong. Now they get deployed, and nobody realizes that this particular box is why the network is currently working like crap. (Until somebody looks at a trace of the traffic, and notices that the TCP options are straight from the '80s).
And TCP is supposed to be the canonical success story for Postel's law!
 Why would anyone do such a horrible thing? AFAIK in both devices this behavior was linked to SYN-flood protection. So it might have been some kind of a horrible SYN-cookie implementation that could not encode any interesting TCP options.
And even that used to be broken too requiring fallback. There used to be several version of the SSLv3 spec out there, and the first time this requirement was mentioned was in an errata document.