Re: libnettle/libhogweed WIP

[Ted Zlatanov <tzz@lifelogs.com>]

On Thu, 20 Apr 2017 22:42:37 +0200 Lars Ingebrigtsen <larsi@gnus.org> wrote: 

LI> While we're bikeshedding interfaces.  :-)

Damn it.

LI> When encrypting something, you usually have a (short) passphrase from
LI> somewhere (KEY), a (short) salt (the binary IV data) and the (long) text
LI> (INPUT).  To me, this suggests that KEY, IV and INPUT doesn't really have
LI> to allow all these various input types: We can limit KEY and IV to be
LI> strings, and INPUT can be both a string and a buffer.  That's really the
LI> use case for 99.72% of the cases, isn't it?

The KEY is secret and ideally would come from a file and never be
seen at the Lisp level. But tests and other use cases may need it from a
buffer (more secure but still accessible to Lisp) or a string (visible
to all as a function parameter).

Getting the INPUT from a file enables large files (not in the first
version probably) and other interesting use cases.

The IV will probably be internal and part of the payload. It probably
won't be part of the function signature normally.

So I think the flexibility is important.

LI> In any case, the `file' case you're discussing here doesn't really feel
LI> that useful, but also makes things more complicated.  If the user wants
LI> to encrypt a file, then it's more flexible to just have the caller
LI> insert the file into a buffer and call the function as normal

Aboslutely. It would be nice if the Emacs C core had "readers" like Java
or Go because then this discussion would be really simple: "did you use
a reader" - "yes" - "good" :)

LI> Your call signatures are extremely flexible, and as such I think they
LI> may be a bit overwhelming.  :-)

Understood. I think there will have to be an interface on top. These are
building blocks.

However it works out, I am positive it would be a mistake to limit
this C code to just strings and buffers.

Ted