Re: NaCl support for Emacs

[Carsten Mattner]

2012/1/9 Ted Zlatanov <address@hidden>:
> On Mon, 9 Jan 2012 17:43:58 +0100 Carsten Mattner <address@hidden> wrote:
>
> CM> On Mon, Jan 9, 2012 at 4:30 PM, Stefan Monnier <address@hidden> wrote:
>>>> I'm interested in bringing in support for the NaCl cryptographic library
>>>> for Emacs, after 24.1 is out.  There is info on NaCl here:
>>>
>>> While it might be an interesting feature to provide for future Elisp
>>> packages, its immediate usefulness is much less obvious, so the kind of
>>> compile-time linking model we use for things like libgnutls would not be
>>> appropriate (e.g. Debian wouldn't want to add nacl as a dependency if
>>> it's not actually used).
>>>
>>> OTOH that might be a good motivation to add support for dynamic loading
>>> of extension libraries.
>
> CM> Only if NaCl's "Automatic CPU-specific tuning" can be done at run-time
> CM> and not only at compile-time. Ted, what's the status with that?
>
> If we manage it as a GNU ELPA package with an included tarball, so it's
> downloaded and compiled locally, sure.  But otherwise yeah, it's not so
> nice.  NaCl is a nice library with no community, AFAICT, and that's

That sounds like a good plan :).

> really my biggest concern about integrating with it.  There's no place
> to propose changes or get updates.

NaCl's design goals, implementation and patent cleanness make it attractive
to anyone who's had to make use of any kind of cipher functionality.
If there's no forum, I suggest addressing the authors listed in
http://cr.yp.to/highspeed/coolnacl-20111201.pdf
If you're bound by FIPS rules, your choices are limited and different.
I wouldn't put much weight on that.

djb has time and time again proven that his work is solid and provides less
attack surface.

Part of the reason that there's much asm code involved may be that
NaCl avoids timing attacks by design.

I'd definitely favor NaCl, just because they provide a simple API with known
safe defaults. Way safer than using OpenSSL without a the required
crypto background.
Most bugs surface in combination of the different tools from a crypto lib,
because too much code is written without being aware of all the semantics of
the used ciphers and modes.