4 ms·
This looks like new development that's just API-compatible with NaCL though, right? Which feels a little strange. The reason I'm drawn to the work of DJB is b
by moxie 14y ago
This looks like new development that's just API-compatible with NaCL though, right? Which feels a little strange.
The reason I'm drawn to the work of DJB is because of his fanatical attention to security-related detail. He wrote and released his own high performance mail server, DNS server, web server, and logging replacement during a period of time when server-side software was plagued with exploitation, and people have only ever found, what, two somewhat minor bugs? Ever?
So what he creates is almost always amazingly solid, but for all his attention to security perfection, his software is also amazingly unusable. Want to run publicfile? First, forget everything you know about standard unix directory structures, because DBJ doesn't like them.
I feel somewhat the same way about NaCL. We can bet the lives of our first born children that the implementation won't suffer any of the bugs that OpenSSL has over the years. Side channel attacks, memory corruption bugs, and timing problems will almost certainly be nonexistent, and someone could probably do their PhD thesis on documenting why.
But like his other software, NaCL has weird usability quirks. This project points out that some of those quirks were certainly manifest in the implementation, but some of them shine through the API itself as well. Like his other software, my sense has been that interacting with NaCL is something that we would almost have to put up with in order to avail ourselves of DJB's greatness, rather than simple joy.
So a rewrite that's API compatible isn't super immediately appealing to me, in the same way that I don't think I'd be particularly drawn to an interface-compatible version of qmail or publicfile that was written by someone else, when the value was in DJB having written them to begin with rather than the interface (the horror!) they provided.
Although to be fair, it's certainly not as if anything else is that much more usable in this world right now.
- tptacek 14y agoI thought he had implemented it in terms of NaCL (I hadn't bothered to look at the code, because I worried I'd decide I was smart enough to endorse it). The actual crypto in this is DIY?
- erichocean 14y agoThe actual crypto in this is DIY? No. From the linked page: "Sodium uses the same implementations of crypto primitives as NaCl".
- tptacek 14y agoYeah that was established downthread. I think I misunderstood Moxie.
- anologwintermut 14y agoJudging from the context below and my limited knowledge of NaCL, this is incorrect. It uses the same algorithms but with the ASM removed. Since, I believe, one of the points of the ASM was removing timing attacks, removing it is not an inherently safe operation. Not saying anyone did anything wrong, just people should be careful and someone should probably check. This is not just a wrapper around NaCL.
- floody-berry 14y agoThe C versions (mostly reference implementations) in NaCl are constant time. The assembly code is there for performance.
- dietrichepp 14y agoWell, maybe they are constant time today. But it is difficult to make wagers about the future of C compilers.
- floody-berry 14y agoEverything that doesn't have assembler versions of all their constant time code (even NaCl under x86/x64) will be vulnerable then. It's possible that compilers start to "optimize" the branchless constructs, but it would almost be malicious as they extremely rare to ever encounter outside of specifically wanting not to branch.
- jedisct1 14y agoAs discussed on the mailing-list, there will be a high(er) level API, similar to the C++ API, that doesn't require dealing with input/output being placed at different offsets in a shared buffer. This is not a rewrite. It uses the reference implementations from NaCl and the same constructions. What it brings over NaCl is a standard build system.
- tptacek 14y agowhew.
- bascule 14y agoJust a note on the approach taken here: I can't say djb would approve of Sodium, but when I asked him about NaCl's portability, he had this to say: "The real work here is making everything PIC. Of course, if what matters is the API rather than speed, then achieving PIC is easy: just remove the asm." Sodium is mostly a "just remove the asm" project, so it seems like djb doesn't hate the concept at least.