From: Lars Ingebrigtsen <larsi@gnus.org>
To: emacs-devel@gnu.org
Subject: Re: libnettle/libhogweed WIP
Date: Thu, 20 Apr 2017 22:42:37 +0200 [thread overview]
Message-ID: <m3a87a4xqa.fsf@stories> (raw)
In-Reply-To: <87inlyrfni.fsf@lifelogs.com> (Ted Zlatanov's message of "Thu, 20 Apr 2017 16:24:33 -0400")
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
next prev parent reply other threads:[~2017-04-20 20:42 UTC|newest]
Thread overview: 128+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-20 10:00 How to ship native modules? Elias Mårtenson
2017-02-20 15:27 ` Eli Zaretskii
2017-02-20 16:01 ` Elias Mårtenson
2017-02-20 16:30 ` Eli Zaretskii
2017-02-21 2:48 ` Elias Mårtenson
2017-02-21 3:41 ` Eli Zaretskii
2017-02-21 4:13 ` Elias Mårtenson
2017-02-21 16:48 ` Eli Zaretskii
2017-02-21 20:06 ` John Wiegley
2017-02-21 14:44 ` Stefan Monnier
[not found] ` <CADtN0WLjNcFRLCsJNZX+XfqOcq+veTaoGkwHQCV9bjvuQoEORA@mail.gmail.com>
2017-02-21 15:48 ` Elias Mårtenson
2017-02-21 17:14 ` Stefan Monnier
2017-02-21 16:59 ` Eli Zaretskii
2017-03-02 14:59 ` request to reconsider libnettle/libhogweed (was: How to ship native modules?) Ted Zlatanov
2017-03-02 15:19 ` request to reconsider libnettle/libhogweed Stefan Monnier
2017-03-02 15:55 ` request to reconsider libnettle/libhogweed (was: How to ship native modules?) Eli Zaretskii
2017-03-15 21:19 ` libnettle/libhogweed WIP (was: request to reconsider libnettle/libhogweed) Ted Zlatanov
2017-03-16 15:28 ` Eli Zaretskii
2017-03-17 22:46 ` libnettle/libhogweed WIP Ted Zlatanov
2017-03-18 8:12 ` Eli Zaretskii
2017-03-20 18:45 ` Ted Zlatanov
2017-04-11 20:05 ` Ted Zlatanov
2017-04-14 20:48 ` Ted Zlatanov
2017-04-15 9:32 ` Eli Zaretskii
2017-04-15 14:27 ` Ted Zlatanov
2017-04-15 14:55 ` Eli Zaretskii
2017-04-16 2:39 ` Ted Zlatanov
2017-04-16 6:25 ` Eli Zaretskii
2017-04-16 6:51 ` Eli Zaretskii
2017-04-17 16:23 ` Ted Zlatanov
2017-04-17 16:34 ` Eli Zaretskii
2017-04-17 16:55 ` Ted Zlatanov
2017-04-17 17:11 ` Eli Zaretskii
2017-04-17 17:34 ` Ted Zlatanov
2017-04-17 17:46 ` Ted Zlatanov
2017-04-17 18:11 ` Eli Zaretskii
2017-04-17 20:50 ` Ted Zlatanov
2017-04-17 21:19 ` Noam Postavsky
2017-04-17 23:29 ` Ted Zlatanov
2017-04-19 2:08 ` Ted Zlatanov
2017-04-19 2:42 ` Noam Postavsky
2017-04-19 15:24 ` Davis Herring
2017-04-19 15:45 ` Eli Zaretskii
2017-04-20 17:24 ` Ted Zlatanov
2017-04-20 19:38 ` Eli Zaretskii
2017-04-20 20:24 ` Ted Zlatanov
2017-04-20 20:42 ` Lars Ingebrigtsen [this message]
2017-04-20 21:54 ` Ted Zlatanov
2017-04-21 6:21 ` Eli Zaretskii
2017-04-21 18:45 ` Lars Ingebrigtsen
2017-04-21 19:15 ` Eli Zaretskii
2017-04-21 6:14 ` Eli Zaretskii
2017-05-15 21:55 ` Ted Zlatanov
2017-05-16 22:19 ` Ted Zlatanov
2017-05-17 16:22 ` Eli Zaretskii
2017-05-17 20:05 ` Ted Zlatanov
2017-05-31 18:17 ` Ted Zlatanov
2017-06-03 7:23 ` Eli Zaretskii
2017-06-03 9:00 ` Andreas Schwab
2017-06-03 10:01 ` Eli Zaretskii
2017-06-03 10:09 ` Andreas Schwab
2017-06-03 10:47 ` Eli Zaretskii
2017-06-27 22:58 ` Ted Zlatanov
2017-06-28 16:54 ` Eli Zaretskii
2017-06-28 19:44 ` Ted Zlatanov
2017-07-13 18:35 ` Ted Zlatanov
2017-07-14 15:10 ` Ted Zlatanov
2017-07-14 19:04 ` Eli Zaretskii
2017-07-14 19:43 ` Ted Zlatanov
2017-07-14 20:04 ` Eli Zaretskii
2017-07-15 18:30 ` Ted Zlatanov
2017-07-15 9:15 ` Eli Zaretskii
2017-07-15 18:40 ` Ted Zlatanov
2017-07-15 19:12 ` Eli Zaretskii
2017-07-22 9:10 ` Eli Zaretskii
2017-07-26 6:58 ` Ted Zlatanov
2017-07-26 14:52 ` Eli Zaretskii
2017-07-26 15:34 ` Ted Zlatanov
2017-07-26 15:49 ` Eli Zaretskii
2017-07-26 16:08 ` Ted Zlatanov
2017-07-26 18:51 ` Eli Zaretskii
2017-07-26 20:48 ` Ted Zlatanov
2017-07-27 0:19 ` Paul Eggert
2017-07-27 2:34 ` Eli Zaretskii
2017-07-27 4:36 ` Paul Eggert
2017-07-27 15:56 ` Ted Zlatanov
2017-08-03 19:52 ` Ted Zlatanov
2017-08-03 8:02 ` Paul Eggert
2017-08-03 16:49 ` Eli Zaretskii
2017-04-18 17:44 ` Ted Zlatanov
2017-04-19 12:22 ` Stefan Monnier
2017-04-19 13:38 ` Ted Zlatanov
2017-04-19 14:16 ` Lars Ingebrigtsen
2017-04-19 14:48 ` Stefan Monnier
2017-04-19 14:41 ` Eli Zaretskii
2017-04-19 14:54 ` Stefan Monnier
2017-04-19 15:31 ` Eli Zaretskii
2017-04-19 15:48 ` Ted Zlatanov
2017-04-19 16:49 ` Lars Ingebrigtsen
2017-04-19 17:24 ` Eli Zaretskii
2017-04-19 19:53 ` Stefan Monnier
2017-04-20 2:30 ` Eli Zaretskii
2017-04-20 3:36 ` Stefan Monnier
2017-04-20 15:46 ` Eli Zaretskii
2017-04-20 15:59 ` Lars Ingebrigtsen
2017-04-20 16:24 ` Eli Zaretskii
2017-04-20 17:25 ` Stefan Monnier
2017-04-20 19:40 ` Lars Ingebrigtsen
2017-04-20 20:31 ` Eli Zaretskii
2017-04-20 19:58 ` Eli Zaretskii
2017-04-20 20:36 ` Eli Zaretskii
2017-04-20 17:14 ` Stefan Monnier
2017-04-20 19:29 ` Eli Zaretskii
2017-04-19 19:49 ` Stefan Monnier
2017-04-17 16:00 ` rename STRING_SET_CHARS to STRING_SET_SIZE (was: libnettle/libhogweed WIP) Ted Zlatanov
2017-04-17 16:24 ` rename STRING_SET_CHARS to STRING_SET_SIZE Eli Zaretskii
2017-04-17 16:29 ` Stefan Monnier
2017-04-17 16:34 ` Ted Zlatanov
2017-04-16 3:37 ` libnettle/libhogweed WIP Stefan Monnier
2017-04-16 6:19 ` Eli Zaretskii
2017-04-16 13:20 ` Stefan Monnier
2017-04-16 7:47 ` Toon Claes
2017-03-02 17:58 ` request to reconsider libnettle/libhogweed Paul Eggert
2017-03-02 18:33 ` Ted Zlatanov
2017-02-20 15:33 ` How to ship native modules? Aurélien Aptel
2017-02-21 4:50 ` Andreas Politz
2017-02-21 5:12 ` Elias Mårtenson
2017-02-21 5:23 ` Andreas Politz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3a87a4xqa.fsf@stories \
--to=larsi@gnus.org \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).