[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Add GPG compatible symmetric encryption command
From: |
Ted Zlatanov |
Subject: |
Re: [PATCH] Add GPG compatible symmetric encryption command |
Date: |
Sat, 08 Feb 2014 11:27:34 -0500 |
User-agent: |
Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.50 (gnu/linux) |
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