14 ms·

From most of the way down the page… Given that we had do to this extra work, what advantage is gained from having two backends, instead of consolidating onto a

by jws 7y ago

From most of the way down the page… Given that we had do to this extra work, what advantage is gained from having two backends, instead of consolidating onto a single backend for both CryptoKit and Swift Crypto? The primary advantage is verification. With two independent implementations of the CryptoKit API, we are able to test the implementations against each other as well as their own test suites. This improves reliability and compatibility for both implementations, reducing the changes of regression and making it easy to identify errors by comparing the output of the two implementations.

mzs 7y ago
a great argument for better automated testing but not for rolling-out everywhere
SahAssar 7y ago
Wouldn't it be just as good to verify and test the ciphertext/hashes/signatures against other crypto libs in testing? It seems weird to include a dependency for some platforms just to "test the implementations". Other crypto frontends don't include different backends just because "testing", if they do they do because they have platform specific reasons.
Rebelgecko 7y ago
This seems weird to me. Creating a working implementation of an algorithm like Chacha20 is really not that hard if you're comfortable with bit twiddling. It's much harder to create an implementation that works and doesn't have hidden problems, like being vulnerable to timing attacks. So they've made it slightly easier to do the easier part of crypto (get a correct result), while increasing their attack surface and the amount of effort that it takes to do the hard part of crypto (getting a result securely).
- codyb 7y ago
  It seems like it’d be easy enough to test whether or not something was vulnerable to timing attacks. But maybe there’s other vulnerabilities to be considered too and hard to have a suite which reliably tests for them all.

by jws 7y ago

mzs 7y ago

a great argument for better automated testing but not for rolling-out everywhere

SahAssar 7y ago

Wouldn't it be just as good to verify and test the ciphertext/hashes/signatures against other crypto libs in testing? It seems weird to include a dependency for some platforms just to "test the implementations". Other crypto frontends don't include different backends just because "testing", if they do they do because they have platform specific reasons.

Rebelgecko 7y ago

This seems weird to me. Creating a working implementation of an algorithm like Chacha20 is really not that hard if you're comfortable with bit twiddling. It's much harder to create an implementation that works and doesn't have hidden problems, like being vulnerable to timing attacks. So they've made it slightly easier to do the easier part of crypto (get a correct result), while increasing their attack surface and the amount of effort that it takes to do the hard part of crypto (getting a result securely).

codyb 7y ago
It seems like it’d be easy enough to test whether or not something was vulnerable to timing attacks. But maybe there’s other vulnerabilities to be considered too and hard to have a suite which reliably tests for them all.