Open GoogleCodeExporter opened 9 years ago
The modification to libgcrypt in gnupg-ecc transitions to named curves. The ECC
parameters are implicitly known from the curve ID. Currently only NIST curves
P-256, P-384, P-521 are supported and tested, but others already present in
libgcrypt/cipher/ecc.c (such as brainpool curves) can easily be added. Please
check http://code.google.com/p/gnupg-ecc/wiki/libgcryptInterface for more
details.
The goal in libgcrypt integration is to provide reasonable backward
compatibility support that makes sense. This will depend on understanding how
other projects are using libgcrypt directly.
What does "(genkey (ecc (nbits 3:160)))" suppose to mean, in particular, the
field with the value "3".
Original comment by brain...@gmail.com
on 16 Dec 2010 at 12:05
Ah, it was my understanding that the project was to implement
encryption/decryption using ECC instead of just the signature
creation/verification that libgcrypt currently supports. If that is not a goal
of the project then never mind.
With respect to the "3" in "(genkey (ecc (nbits 3:160)))", that is just a
length indicator that tells libgcrypt how many bytes to read for the "nbits"
field. (i.e. strlen( "160" ) == 3).
Original comment by staktr...@gmail.com
on 16 Dec 2010 at 9:40
The project implements full ECC functionality: ECDSA signatures and ECDH
encryption. ECDSA was working before; most of my work went into making
encryption work.
Can you please provide a sample that worked before that doesn't work now?
Original comment by brain...@gmail.com
on 29 Dec 2010 at 2:25
There's nothing new that's broken. It's just that ECDH encryption doesn't work
and never has in libgcrypt. I've attached a basic sample that shows RSA
encryption/decryption using libgcrypt. What I would like is for this to work
using ECDH encryption. I thought that using the libgcrypt from gnupg-ecc would
make it possible but I couldn't get it working. To compile my sample on Mac OS
X 10.6.5 with libgcrypt from fink I do "gcc -arch i386 -I/sw/include -L/sw/lib
-lgcrypt test.c", presumably you can get it to compile on your platform without
too much trouble.
Original comment by staktr...@gmail.com
on 29 Dec 2010 at 5:21
Attachments:
The integration of ECC code is currently making its progress in GnuPG
repository (see front page for updates and details). ECDH interface is changed
a bit from r15 to accommodate new architecture of gpg-agent in which it doesn't
make private keys available.
The latest ECDH interface is described in the libgrcypt/cipher/ecc.c, see
comment before ecc_encrypt_raw(). As the function indicates, it is basically
year 1976 DH with ECC.
The true encryption similar in data structures to ElGamal, is accomplished with
the help of gnupg, i.e. the client code relies on ECDH primitives provided by
ligcrypt and performs additional operations to protect symmetric key using
AESWrap.
There are suggestions to move this functionality into libgcrypt layer, but
before this happened (if ever), would raw ECDH functionality suffice for your
usage?
libgcrypt : ECC-INTEGRATION-1-5
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=shortlog;h=refs/heads/ECC-INTEGRATION-1-5
gnupg: ECC-INTEGRATION-2-1
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=shortlog;h=refs/heads/ECC-INTEGRATION-2-1
Original comment by brain...@gmail.com
on 11 Jan 2011 at 5:10
If the raw ECDH functionality is exposed and available through the libgcrypt
API then yeah, that's sufficient for me.
Original comment by staktr...@gmail.com
on 11 Jan 2011 at 6:23
FYI, the ECDH functionality is released as part of libgcrypt beta.
Here are the files
ftp://ftp.gnupg.org/gcrypt/alpha/libgcrypt/libgcrypt-1.5.0-beta1.tar.bz2
ftp://ftp.gnupg.org/gcrypt/alpha/libgcrypt/libgcrypt-1.5.0-beta1.tar.bz2.sig
from the following announcement on Feb 21 2011 on gcrypt-devel@gnupg.org:
http://www.gossamer-threads.com/lists/gnupg/devel/53256
Please give it a try.
Original comment by brain...@gmail.com
on 24 Feb 2011 at 12:21
Original issue reported on code.google.com by
staktr...@gmail.com
on 24 Nov 2010 at 5:29