OpenBSD forks, prunes, fixes OpenSSL
zdnet.com
OpenBSD forks, prunes, fixes OpenSSL
1–10 of 58 posts
Re: OpenBSD forks, prunes, fixes OpenSSL
#2Cryptographic 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?
Re: OpenBSD forks, prunes, fixes OpenSSL
#3Cryptographic 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…
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.
Re: OpenBSD forks, prunes, fixes OpenSSL
#4Cryptographic 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…
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.
Re: OpenBSD forks, prunes, fixes OpenSSL
#5Cryptographic 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…
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."
Re: OpenBSD forks, prunes, fixes OpenSSL
#6Cryptographic 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…
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.
Re: OpenBSD forks, prunes, fixes OpenSSL
#7Earlier 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.
In my experience, people tend to wildly over- or under- estimate the complexity of anything they don't understand.
Re: OpenBSD forks, prunes, fixes OpenSSL
#8Earlier 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.
Here you go.
http://www.opensource.apple.com/source/OpenSSL098/OpenSSL098...
Note: it's Perl.
Re: OpenBSD forks, prunes, fixes OpenSSL
#9OpenSSL 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
#10It'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…)