Re: libnettle/libhogweed WIP

[Lars Ingebrigtsen <larsi@gnus.org>]

Ted Zlatanov <tzz@lifelogs.com> writes:

> Then I listed another approach: to read the file directly with
> extract_data_from_object(). Based on your comments, and based on how
> we're sort of agreeing to limit the code to unibyte data, it's becoming
> clear that this is the better way. I also think it's more secure and
> less ambiguous. So I'll implement it.
>
> Thus extract_data_from_object() would allocate and read N bytes into a C
> memory buffer and pass that on, and the caller would have to free it.
> I'll see how that works out in code, but shouldn't be too bad. It will
> be a single place to review and fix, at least.

While we're bikeshedding interfaces.  :-)

 -- Function: gnutls-symmetric-encrypt cipher key iv input &optional
          aead_auth
     The CIPHER can be the whole plist from ‘gnutls-ciphers’, or just
     the symbol key, or a string with the name of that symbol.

     The KEY can be a string or a buffer or a list in the format
     (BUFFER-OR-STRING START END CODING-SYSTEM NOERROR) where only the
     first element is required.  The KEY will be wiped after use if it’s
     a string.

     The IV and INPUT and the optional AEAD_AUTH can be a string or a
     buffer or a list in the format (BUFFER-OR-STRING START END
     CODING-SYSTEM NOERROR) where only the first element is required.

     In the list form of KEY, IV, INPUT, and the optional AEAD_AUTH you
     can specify a buffer or a string, an optional range to be
     extracted, and an optional coding system.  The last optional item,
     NOERROR, overrides the normal error when the text can’t be encoded
     using the specified or chosen coding system.  When NOERROR is
     non-‘nil’, this function silently uses ‘raw-text’ coding instead.
     This is similar to how ‘md5’ and ‘secure-hash’ operate but the
     arguments are packed in a list.

To me, as a naive application programmer that apparently doesn't
understand anything, this is all rather more complicated and more
flexible than optimal.  :-)

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

Then the natural call signature here would be

gnutls-symmetric-encrypt cipher key iv input &optional aead-auth start end

If input is a buffer, then the text in the buffer could perhaps be
replaced with the encrypted data, a la many other transformation
functions.

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

(with-temp-buffer
  (set-buffer-multibyte nil)
  (insert-file-contents "/tmp/rms.jpg")
  (gnutls-symmetric-encrypt 'AES-256-CBC key iv (current-buffer))
  (write-region ...))

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

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no