From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daiki Ueno Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Add GPG compatible symmetric encryption command Date: Sat, 08 Feb 2014 15:24:54 +0900 Message-ID: <87ha8a2kax.fsf-ueno@gnu.org> References: <8761orch7y.fsf@lifelogs.com> <87ppmzw1p8.fsf-ueno@gnu.org> <87txcbawsi.fsf@lifelogs.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1391840695 23502 80.91.229.3 (8 Feb 2014 06:24:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 8 Feb 2014 06:24:55 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Feb 08 07:25:04 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WC1Lb-0008Mq-IZ for ged-emacs-devel@m.gmane.org; Sat, 08 Feb 2014 07:25:03 +0100 Original-Received: from localhost ([::1]:45362 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WC1Lb-00068A-55 for ged-emacs-devel@m.gmane.org; Sat, 08 Feb 2014 01:25:03 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47055) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WC1LY-00067w-PR for emacs-devel@gnu.org; Sat, 08 Feb 2014 01:25:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WC1LX-0005j0-Li for emacs-devel@gnu.org; Sat, 08 Feb 2014 01:25:00 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:57906) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WC1LX-0005il-I2 for emacs-devel@gnu.org; Sat, 08 Feb 2014 01:24:59 -0500 Original-Received: from du-a.org ([2001:e41:db5e:fb14::1]:48083 helo=debian) by fencepost.gnu.org with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1WC1LX-0004nG-0m for emacs-devel@gnu.org; Sat, 08 Feb 2014 01:24:59 -0500 In-Reply-To: <87txcbawsi.fsf@lifelogs.com> (Ted Zlatanov's message of "Fri, 07 Feb 2014 08:15:41 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:169479 Archived-At: Ted Zlatanov writes: > Meanwhile, would you consider continuing with your patch to the point > where Lars can use it from Gnus? I wouldn't take that risk, sorry. Emacs will soon get CVE numbers assigned, unless the patch will be carefully reviewed by experts and actively maintained. I already found a few flaws that may lead to a security hole. However, since it is free software, if your writing of this: > I wrote similar integration code in my original libnettle patch and am > sure it could use similar thoroughness. is true and you _really_ understand the background theory of this "integration" code, you could perhaps complete the task by yourself? Let's look at your patch: http://lists.gnu.org/archive/html/emacs-devel/2013-10/msg00144.html Ouch. Why do you expose IV to Elisp and don't use any salt? Are you aware that you are negating security doing secret key operation in Elisp? Why do you always allocate new memory for key on heap, plaintext, cipher, and why don't you clear them. How do you check if password is correct or wrong. It's much worse than I expected. I'm afraid to say you can't write any security related code that people can depend on, at this skill level. I'd suggest to read GNUTLS or GnuPG code to learn how practical encryption code works. Perhaps my patch might also give you some inspiration. > As I said, I don't think it affects my request for > GnuTLS/libnettle/libhogweed primitives[1] Well, didn't we already decide to use FFI for that? That implies those primitives won't be part of Emacs by default. Emacs is not your playground to try out your pseudo security feature. I remember Stefan already suggested you to do that in your ELPA package even after FFI becomes available. > [1] you omitted an answer to that question from your reply, so I assume > you agree. Of course not. -- Daiki Ueno