3 ms·

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 writin

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?

yuhong 10y ago
One of the worst being the SSLv2 code.
tomsmeding 10y ago
Is assembly then not hard to do right?
- technion 10y ago
  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.
throwaway7767 10y ago
> 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/crypto/aes/asm/ http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/... Looks like LibreSSL has the exact same perl-generating-assembler code.
bdamm 10y ago
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.
- e12e 10y ago
  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?
  - bdamm 10y ago
    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.

yuhong 10y ago

One of the worst being the SSLv2 code.

tomsmeding 10y ago

Is assembly then not hard to do right?

technion 10y ago
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.

throwaway7767 10y ago

> 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/crypto/aes/asm/ http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/... Looks like LibreSSL has the exact same perl-generating-assembler code.

bdamm 10y ago

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.

e12e 10y ago
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?
- bdamm 10y ago
  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.