emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Add GPG compatible symmetric encryption command


From: Daiki Ueno
Subject: Re: [PATCH] Add GPG compatible symmetric encryption command
Date: Sat, 08 Feb 2014 15:24:54 +0900
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)

Ted Zlatanov <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]