From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: libnettle/libhogweed WIP Date: Fri, 21 Apr 2017 09:21:14 +0300 Message-ID: <8360hyb7s5.fsf@gnu.org> 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> <878tmurbhj.fsf@lifelogs.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1492755643 25563 195.159.176.226 (21 Apr 2017 06:20:43 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 21 Apr 2017 06:20:43 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 21 08:20:39 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 1d1Rvn-0006SE-WB for ged-emacs-devel@m.gmane.org; Fri, 21 Apr 2017 08:20:36 +0200 Original-Received: from localhost ([::1]:57378 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d1Rvt-0006IK-K1 for ged-emacs-devel@m.gmane.org; Fri, 21 Apr 2017 02:20:41 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54707) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d1Rvo-0006IB-5e for emacs-devel@gnu.org; Fri, 21 Apr 2017 02:20:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d1Rvl-000136-0u for emacs-devel@gnu.org; Fri, 21 Apr 2017 02:20:36 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:47103) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d1Rvk-000132-Tm for emacs-devel@gnu.org; Fri, 21 Apr 2017 02:20:32 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4338 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1d1Rvk-0008A9-8b for emacs-devel@gnu.org; Fri, 21 Apr 2017 02:20:32 -0400 In-reply-to: <878tmurbhj.fsf@lifelogs.com> (message from Ted Zlatanov on Thu, 20 Apr 2017 17:54:32 -0400) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:214175 Archived-At: > From: Ted Zlatanov > 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.