3 ms·

Cryptographic algorithm usually are pretty straight forward when you look at them. Beside good verifiable coding practice to have a quality implementation, it

by RRRA 12y ago

Cryptographic algorithm usually are pretty straight forward when you look at them. Beside good verifiable coding practice to have a quality implementation, it seems that the issue is with the many side channels attack that needs to be obfuscated and make the whole thing a lot harder to maintain and verify. So I'm guessing the issue is probably more about the very badly engineered protocols with blurry designs and too many bells and whistles rather than with the basic cryptographic building blocks?

marshray 12y ago
Cryptographic algorithm usually are pretty straight forward when you look at them. Take a look at the hand-optimized for speed immplementations in assembly sometime.
- userbinator 12y ago
  They're still just doing a bunch of math; the complexity is in I/O and protocol interactions, not the algorithms themselves.
  - Tloewald 12y ago
    In my experience, people tend to wildly over- or under- estimate the complexity of anything they don't understand.
  - marshray 12y ago
    Here you go. http://www.opensource.apple.com/source/OpenSSL098/OpenSSL098-27/src/crypto/aes/asm/ http://www.opensource.apple.com/source/OpenSSL098/OpenSSL098... Note: it's Perl.
  - pbsd 12y ago
    The AES is a good example of a cryptographic algorithm that is rather not straightforward to implement in an efficient and safe manner. AES is defined on a 4x4 byte state, and every operation (even the sbox) is defined over GF(2^8). However, fast implementations resemble very little of that definition, and end up being a large number of xor and (large) table lookups. This is a much faster way to do it, on general-purpose machines, but it often leaves you open to cache-timing attacks. So to come up with a fast and secure AES implementation you need to transpose the state in a way that resembles processing 8 blocks in parallel, and emulate hardware-level bitwise arithmetic on software. This is a so-called bitsliced implementation. By this point the code is much more complex and tricky than the original specification, and it will only actually be fast for parallel modes of operation such as CTR, leaving CBC hanging. Thankfully processors now implement AES round instructions, which simplifies secure implementations, but makes portable implementations difficult. Cryptographers have learned from this state of affairs, though. New algorithms being created (like Keccak, aka SHA-3) now try harder to make the straightforward implementation secure and reasonably fast by default. Public-key algorithms, on the other hand, are always tricky to implement, even if the arithmetic itself is not very complicated. One of the appeals of curve25519 (and other so-called "safe curves") is precisely that it is rather easy (but still not trivial) to implement them in a safe manner.
anaphor 12y ago
Protecting against sidechannels doesn't mean the code has to be obfuscated. You do need to reimplement some things that are usually pretty simple (like string comparison) but it does not mean you can't abstract that away into a library like anything else.
dsl 12y ago
This is a quote from a OpenBSD developer that sums up the work they are doing nicely: "Of necessity, some crypto code will be a bit scary to look at. anything that has to do regular jobs, like building a pathname, in a security library, should be a thing of beauty, not something that makes you want to throw up in your mouth."

by RRRA 12y ago

marshray 12y ago

Cryptographic algorithm usually are pretty straight forward when you look at them. Take a look at the hand-optimized for speed immplementations in assembly sometime.

userbinator 12y ago
They're still just doing a bunch of math; the complexity is in I/O and protocol interactions, not the algorithms themselves.
- Tloewald 12y ago
  In my experience, people tend to wildly over- or under- estimate the complexity of anything they don't understand.
- marshray 12y ago
  Here you go. http://www.opensource.apple.com/source/OpenSSL098/OpenSSL098-27/src/crypto/aes/asm/ http://www.opensource.apple.com/source/OpenSSL098/OpenSSL098... Note: it's Perl.
- pbsd 12y ago
  The AES is a good example of a cryptographic algorithm that is rather not straightforward to implement in an efficient and safe manner. AES is defined on a 4x4 byte state, and every operation (even the sbox) is defined over GF(2^8). However, fast implementations resemble very little of that definition, and end up being a large number of xor and (large) table lookups. This is a much faster way to do it, on general-purpose machines, but it often leaves you open to cache-timing attacks. So to come up with a fast and secure AES implementation you need to transpose the state in a way that resembles processing 8 blocks in parallel, and emulate hardware-level bitwise arithmetic on software. This is a so-called bitsliced implementation. By this point the code is much more complex and tricky than the original specification, and it will only actually be fast for parallel modes of operation such as CTR, leaving CBC hanging. Thankfully processors now implement AES round instructions, which simplifies secure implementations, but makes portable implementations difficult. Cryptographers have learned from this state of affairs, though. New algorithms being created (like Keccak, aka SHA-3) now try harder to make the straightforward implementation secure and reasonably fast by default. Public-key algorithms, on the other hand, are always tricky to implement, even if the arithmetic itself is not very complicated. One of the appeals of curve25519 (and other so-called "safe curves") is precisely that it is rather easy (but still not trivial) to implement them in a safe manner.

anaphor 12y ago

Protecting against sidechannels doesn't mean the code has to be obfuscated. You do need to reimplement some things that are usually pretty simple (like string comparison) but it does not mean you can't abstract that away into a library like anything else.

dsl 12y ago

This is a quote from a OpenBSD developer that sums up the work they are doing nicely: "Of necessity, some crypto code will be a bit scary to look at. anything that has to do regular jobs, like building a pathname, in a security library, should be a thing of beauty, not something that makes you want to throw up in your mouth."