5 ms·
Buffer Overflows in a few of the prospective SHA-3 algorithms (including MD6).
- neilc 18y agoAs the article makes clear, these are not buffer overflows in the algorithms themselves, they are just overflows in the reference implementations.
- jjguy 18y agoI don't understand why this keeps getting passed around. Buffer overflows in the hash reference implementations have zero relevance on the algorithm's hashing effectiveness. Fortify posted the results of their static analysis tool to the web as an academic exercise and PR stunt. That it continues to propagate the web is merely amplifying the FUD.
- jrockway 18y agoThe article does not use the buffer overflows to conclude anything about the algorithm -- it concludes that writing software that manages memory correctly is very difficult. This is why you should all stop using C, and people should stop telling other people to use C. (Anything I would use C for, I now use Haskell for. Everything runs as fast, and the language and libraries are much better.)
- tptacek 18y agoThat's nice. Almost nobody is using C anymore --- especially for the web apps we talk about here. But everyone drops to native code for encoding/decoding; in Python, Perl, or Ruby, you're calling OpenSSL to get your crypto primitives, an OpenSSL is gnarly C code.
- neilc 18y agoNo one is using C anymore, except for trivial things like kernels, database systems, and VMs.
- jrockway 18y agoKernels are trivial (straightforward is a better word) and are very close to the hardware, so C works pretty well for them. If you started a new OS kernel today, though, you wouldn't have to pick C. The other things are just going on momentum. C is not a good choice for those applications. (For example, look at SBCL and GHC. Two of the fastest language runtimes, and both are self-hosting. Yeah, you need a little bit of C to interface with the underlying OS, but the critical parts are not C.) Anyway, nice attempt at snark. It earned you an upmod.
- likpok 18y agoThe bigger issue with kernels is that they are, as you say, close to the hardware. That makes them harder to do in higher level languages (you need something to run on...). However, it is possible to do, for example Singularity. Personally, I think that the "kernel" will begin to be a smaller and smaller part of the OS. More like L4 et al, as the performance costs become smaller (L4 is already pretty good). Eventually, C might become the old assembly; you need a small amount of it to get started, but once you've boostrapped, you can live in higher-level code.
- tptacek 18y agoI don't think proximity to the hardware is a big issue (we do a lot of hardware work --- at the interrupt-handler, polling-MSRs, hard-timer level --- and we take pains to stay in Ruby, an incredibly slow language. I think the issue is first performance (you can't context switch fast enough in a high-level language, and more importantly the concept of a context switch in most OSs is kind of tuned to the C language), and the second is universality; you want the lowest common denominator in the kernel.
- tptacek 18y agoRDBMS's seem like the next likely C stronghold to fall; they're I/O bound and feature-laden.
- 18y ago
- jrockway 18y agoMost of the Perl crypto libraries use Pari or GMP, actually. Your point still holds, however. You will notice, though, that the Haskell crypto libraries are generally "pure Haskell", since there is not much of a speed hit for not using C. This is the Future.
- tptacek 18y agoThis is pretty retarded. The code in crypto competition submissions is invariably crappy; nobody is expected to use it outside of the contest. Unfortunately, Fortify's core customers are enterprise IT development teams, who will be impressed by this. That real security professionals will ding them for the misleading post matters not at all.