From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Lars Ingebrigtsen Newsgroups: gmane.emacs.devel Subject: Re: libnettle/libhogweed WIP Date: Thu, 20 Apr 2017 22:42:37 +0200 Message-ID: References: <87shmeb5ln.fsf_-_@lifelogs.com> <83y3w5z1ez.fsf@gnu.org> <87lgr6yakj.fsf@lifelogs.com> <87wpamww9k.fsf@lifelogs.com> <8337daggnj.fsf@gnu.org> <87d1cdwxt6.fsf@lifelogs.com> <83tw5pg1q3.fsf@gnu.org> <87zifhulc2.fsf@lifelogs.com> <83h91og80k.fsf@gnu.org> <87pogbuhoe.fsf@lifelogs.com> <834lxndmd9.fsf@gnu.org> <87efwrug6z.fsf@lifelogs.com> <87r30qu5av.fsf@lifelogs.com> <874lxmtxyy.fsf@lifelogs.com> <87r30prvwt.fsf@lifelogs.com> <8337d4csez.fsf@gnu.org> <87r30nq9el.fsf@lifelogs.com> <83inlyc1k2.fsf@gnu.org> <87inlyrfni.fsf@lifelogs.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1492720971 15312 195.159.176.226 (20 Apr 2017 20:42:51 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 20 Apr 2017 20:42:51 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Apr 20 22:42:46 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d1Iuc-0003rD-Bw for ged-emacs-devel@m.gmane.org; Thu, 20 Apr 2017 22:42:46 +0200 Original-Received: from localhost ([::1]:55901 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d1Iui-0002yd-6M for ged-emacs-devel@m.gmane.org; Thu, 20 Apr 2017 16:42:52 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48479) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d1Iuc-0002yY-0q for emacs-devel@gnu.org; Thu, 20 Apr 2017 16:42:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d1IuX-0003wD-Nl for emacs-devel@gnu.org; Thu, 20 Apr 2017 16:42:46 -0400 Original-Received: from hermes.netfonds.no ([80.91.224.195]:47573) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1d1IuX-0003t7-Ge for emacs-devel@gnu.org; Thu, 20 Apr 2017 16:42:41 -0400 Original-Received: from cm-84.213.17.174.getinternet.no ([84.213.17.174] helo=stories) by hermes.netfonds.no with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1d1IuT-0007CJ-Ca for emacs-devel@gnu.org; Thu, 20 Apr 2017 22:42:39 +0200 Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAHlBMVEXwuWeFADN1DFGZPXT4 zUV8HVulACfboLfFcp5uBUXWN8BHAAACZUlEQVQ4jV3UO2/bMBAAYAMuIK1K4gLeCrkqoC0wzUTe AyRryDCoRtd1HluWghqLEoFuDRUZuH/bO1IWnBCe7hN5uuPJkwdeuzxH9IgnxmhxfsVrEqDEsLLZ 7Umn5WqEzducwm8G32r00ugRyixDnAtBG3tTK78a4LnM5hkWWtTYF11d4/cBpD6VeSGMqjGvu772 RYRt2oCTSou1Qr/uesRiFeAxsY2glEb2xsuOz7sLcHmdglC51r3XlBtxoXWANkmdUD5f9Ki7Er2m vQzbl+RGCOPzQqFce1wLgi8RUkE5jF5THeXsVi4MFT95eCKACoTTSzq/nu2lXhqG6sWmAA1M5ZL7 tdtLqdTdAWz6F6bnzwHWRT5AkqQ2dfTOdBQ+35fGBLi0SZK8pBNLxRAwesU5Wpte0xbbgJAUmxPl IXnb3FxPW4o77rvnPCNMi4rDVCbe8pXligtMmlTNQoEk8j5AwS1ZNZCfzOjgRQUQoegZvjWgMrop /7MFeL1gKDuGXwtY4rxEba2F13veEGGnrPuXZVnLIH8Q9OU7w0ZY+yfLKoo3zuzDgEU4tU0ln2zY UEQ4Czd4aocFbtl/DTBMyRiXpd8cQTvGVewh7j+CMMNsc26G4SQn8wOcHUMjzAhXH2HJX88naLg4 qQbYDwBCVCGHGs46wPaiCn2i+Y3yfviiICZx0sTDRhiy0+XGNCO0Q+U0p+YDbAF4emi5UPx+zCFc Zel54DYew/YJoA0/p44LfKBLaigKlP8TtI6u17Z0g7HC3+MO18YXVmUo8f3wlwGVjTNS+oI7OcLj UKHiL9QopEG8+g819Lc4efuejgAAAABJRU5ErkJggg== In-Reply-To: <87inlyrfni.fsf@lifelogs.com> (Ted Zlatanov's message of "Thu, 20 Apr 2017 16:24:33 -0400") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 80.91.224.195 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:214161 Archived-At: Ted Zlatanov 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 =E2=80=98gnutls-ciphers=E2=80= =99, 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=E2= =80=99s 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=E2=80=99t be enc= oded using the specified or chosen coding system. When NOERROR is non-=E2=80=98nil=E2=80=99, this function silently uses =E2=80=98raw-te= xt=E2=80=99 coding instead. This is similar to how =E2=80=98md5=E2=80=99 and =E2=80=98secure-hash= =E2=80=99 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. :-) --=20 (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no