From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: Re: libnettle/libhogweed WIP Date: Thu, 20 Apr 2017 17:54:32 -0400 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <878tmurbhj.fsf@lifelogs.com> References: <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> Reply-To: emacs-devel@gnu.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1492725293 11196 195.159.176.226 (20 Apr 2017 21:54:53 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 20 Apr 2017 21:54:53 +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 23:54:49 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 1d1K2L-0002oQ-Nm for ged-emacs-devel@m.gmane.org; Thu, 20 Apr 2017 23:54:49 +0200 Original-Received: from localhost ([::1]:56160 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d1K2R-0000DQ-NW for ged-emacs-devel@m.gmane.org; Thu, 20 Apr 2017 17:54:55 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39806) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d1K2J-0000DJ-3A for emacs-devel@gnu.org; Thu, 20 Apr 2017 17:54:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d1K2E-00065M-6S for emacs-devel@gnu.org; Thu, 20 Apr 2017 17:54:47 -0400 Original-Received: from [195.159.176.226] (port=37131 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1d1K2D-00064k-V3 for emacs-devel@gnu.org; Thu, 20 Apr 2017 17:54:42 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1d1K25-0002Tm-9b for emacs-devel@gnu.org; Thu, 20 Apr 2017 23:54:33 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 45 Original-X-Complaints-To: usenet@blaine.gmane.org X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Mail-Copies-To: never Cancel-Lock: sha1:g+V1y/P42lO8XZKdpUDuDNaupg8= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 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:214164 Archived-At: On Thu, 20 Apr 2017 22:42:37 +0200 Lars Ingebrigtsen 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