Re: libnettle/libhogweed WIP

[Eli Zaretskii <eliz@gnu.org>]

> From: Ted Zlatanov <tzz@lifelogs.com>
> Date: Thu, 20 Apr 2017 17:54:32 -0400
> 
> 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).

For testing, we could always write the key to a file before using it.
What other use cases would need the key from other sources?

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

What other cases?  Large files is only theoretically useful, since
generally Emacs cannot do useful things on files larger than
most-positive-fixnum, and on 64-bit machines that is far enough to not
care.

> 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.

I think we need to weigh flexibility against the complexity, and find
the optimal balance.  So making the interfaces too complicated for use
cases that will happen only very rarely, if at all, should be avoided.

So I agree with Lars: we should rethink what types of data we want to
support for each argument, and shouldn't complicate the APIs beyond
what's necessary, at least at this point.

Once again, I think a list of use cases with some details will be
helpful to make this discussion more focused and make sure we are all
on the same page.

Thanks.