Hacker News Reader

Comment by e12e | Hacker News Reader

"Let's just consider symmetric ciphers for a moment. Because everyone wants them to be as fast as possible, BoringSSL currently contains 27 thousand lines of Perl scripts (taken from OpenSSL, who wrote them all) that generate assembly code just in order to implement AES-GCM."

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

View on HN

Yep, that's it. Different platforms need slightly different assembly and, although I wouldn't choose Perl for it, it's not fundamentally that different from any other text-to-text transform.

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

While some of NaCl's kernels are written using qhasm, qhasm itself is not part of the build process of NaCl. This means that those functions cannot be ran on, say, Windows, because the calling convention (and the assembly syntax) is different. qhasm also does not have programming capabilities, so one would need a lot of code duplication to write an SSE2, SSSE3, AVX2, etc variant of the same function. While OpenSSL's perlasm is an abomination, it does produce "portable" assembly output, and there is no obvious superior option to accomplish that. This is something sorely missing from our collective toolchains.

It sounds like this perlasm is the state of the art in maximally efficient high level languages. (Half joking.)

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.

The nasm/yasm macro packages in x264 source can do all this for you and more, across i386/x86-64 sysv/win64.

The Win64 versions are a little less optimal IIRC, but to be fair Win64 is dumb.

I'm probably missing something, but looking at:

https://boringssl.googlesource.com/boringssl/+/master/crypto...

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

Can the Perl output in different syntaxes for different assemblers?

This is one of the reasons I'm a very strong proponent of LibreSSL.

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?

One of the worst being the SSLv2 code.

Is assembly then not hard to do right?

I'm not going to pretend to have an authoritative answer on whether Perl generated assembly is easier to get right than assembly, but I'll say this: The number of people who are skilled in assembly is small, and it's made even smaller when what you are looking for is where it intersects with those skilled in Perl.

> This is one of the reasons I'm a very strong proponent of LibreSSL.

http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/...

Looks like LibreSSL has the exact same perl-generating-assembler code.

Pure crypto functions are highly deterministic. If the output is correct then all you need to worry about is side-channel attacks, and to analyze that you don't need code audits at all.

I thought one of the key difficulties in analysing (and writing) good crypto implementations was making sure that they are both efficient and that there are no allocations of memory or branching that is key dependent. While it may be easy to prove an implementation insecure (find an example where there are obvious timing issues), isn't it still a matter of code analysis to show an implementation is actually secure?

I am just saying that you don't need code analysis to find out that there's a side channel attack (e.g. through memory allocation analysis, power analysis.) In fact, I believe actual physical testing is the way to prove security of an implementation, given the subtle bugs that can appear in optimizing compilers, runtimes, downstream packagers, etc.

Reply on news.ycombinator.com