Re: [PATCH] Add GPG compatible symmetric encryption command

[Ted Zlatanov]

On Sat, 08 Feb 2014 15:24:54 +0900 Daiki Ueno <address@hidden> wrote: 

DU> Ted Zlatanov <address@hidden> writes:
>> Meanwhile, would you consider continuing with your patch to the point
>> where Lars can use it from Gnus?

DU> I wouldn't take that risk, sorry.  Emacs will soon get CVE numbers
DU> assigned, unless the patch will be carefully reviewed by experts and
DU> actively maintained.  I already found a few flaws that may lead to a
DU> security hole.

OK, I understand your concerns.

DU> Let's look at your patch:
DU> http://lists.gnu.org/archive/html/emacs-devel/2013-10/msg00144.html

DU> Ouch.  Why do you expose IV to Elisp and don't use any salt?  Are you
DU> aware that you are negating security doing secret key operation in
DU> Elisp?  Why do you always allocate new memory for key on heap,
DU> plaintext, cipher, and why don't you clear them.  How do you check if
DU> password is correct or wrong.

DU> It's much worse than I expected.  I'm afraid to say you can't write any
DU> security related code that people can depend on, at this skill level.

I acknowledged your patch was a better approach.  Your criticism is
valid, regardless.

My goal was to make the acceptance tests, which are 90% of the code, and
to show a proof of concept for the API.  The code was not intended to go
into the core in that shape.  As I said:

"I would appreciate any comments at this early stage." and more recently
"I'm sure it could use similar thoroughness [to your patch]."

It was rejected for reasons other than code quality so I saw no point in
improving it further.  When I continue, it will be modeled after your
patch and probably structured as an EPG plugin.

I'll also note that the integration of the hash functions is a large
part of my patch and probably does not need as much review or fixing.
Those functions seem (from a casual reading) to be better optimized and
to offer more choice than the ones in the Emacs core.  Going through
FFI, however, *may* negate the speed benefits.  So perhaps importing
just the hashing functions directly would be practically useful.

DU> I'd suggest to read GNUTLS or GnuPG code to learn how practical
DU> encryption code works.  Perhaps my patch might also give you some
DU> inspiration.

It did, and I think it's good code and a good direction.  It's a shame
you don't want to continue with it.

Ted