It's cool they're doing this cleanup, but overly self-righteous commit messages ( http://opensslrampage.org/ ) on patches like http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/cry... rub me the wrong way (I'm sure comparing a string pointer to '5' / decimal 53 is _exactly_ what the old, ridiculed code meant to do…)
OpenBSD forks, prunes, fixes OpenSSL
11–20 of 58 posts
Re: OpenBSD forks, prunes, fixes OpenSSL
#12OpenSSL is beyond repair. We need a new clean start, sane design and rock solid implementation with principles and following best practices.
Re: OpenBSD forks, prunes, fixes OpenSSL
#13OpenSSL is beyond repair. We need a new clean start, sane design and rock solid implementation with principles and following best practices.
Also, I think that an OpenSSL cleanup is needed even if we get a new awesome library too. We can't drop OpenSSL overnight, and as you said it's bad. So this at least make it less bad, until there's something we can switch to.
Re: OpenBSD forks, prunes, fixes OpenSSL
#14Earlier quoted context omitted.
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.
They're still just doing a bunch of math; the complexity is in I/O and protocol interactions, not the algorithms themselves.
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.
Re: OpenBSD forks, prunes, fixes OpenSSL
#15Re: OpenBSD forks, prunes, fixes OpenSSL
#16OpenSSL is beyond repair. We need a new clean start, sane design and rock solid implementation with principles and following best practices.
Like NaCl? http://nacl.cr.yp.to/
Re: OpenBSD forks, prunes, fixes OpenSSL
#17It's cool they're doing this cleanup, but overly self-righteous commit messages ( http://opensslrampage.org/ ) on patches like http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/cry... rub me the wrong way (I'm sure comparing a string pointer to '5' / decimal 53 is _exactly_ what the old, ridiculed code meant to do…)
Re: OpenBSD forks, prunes, fixes OpenSSL
#18Do they not realize that clients also need SSL support? Servers that don't have anyone to talk to them are kind of useless, so at best this is half of solution (unless it really is the year of the linux desktop, of course). There are a ton of applications out there that run on Windows and use OpenSSL for handling SSL connections.
That being said this may be a great replacement for servers, and there really isn't a requirement for there to be "one library to rule them all". This may be a great step towards diversifying the encryption-library ecosystem a bit.