From wk at gnupg.org Mon Jul 1 10:54:55 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 01 Jul 2013 10:54:55 +0200 Subject: No secmem support on kfreebsd-amd64 In-Reply-To: <20130630172728.GA3233@downhill.g.la> (Andreas Metzler's message of "Sun, 30 Jun 2013 19:27:28 +0200") References: <20130630172728.GA3233@downhill.g.la> Message-ID: <877ghaacdc.fsf@vigenere.g10code.de> On Sun, 30 Jun 2013 19:27, ametzler at downhill.at.eu.org said: > it looks like secmem support is broken on kfreebsd-amd64 (gcrypt 1.5.2): Only on -amd64? Currently I have only a 32 bit kfreebox in use thus I am not able to test it right now. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From testtest_2005 at ukr.net Mon Jul 1 12:08:14 2013 From: testtest_2005 at ukr.net (Vasiliy) Date: Mon, 1 Jul 2013 12:08:14 +0200 Subject: could not create a keypair / sign a single file Message-ID: Thank you for your reply, your first suggestion was helpful. Despite all the lines in ~/.gnupg/trustlist.txt were no longer than 61 characters each (plus I added the last line manually), I've just re-created trustlist.txt as it was described on: http://www.claws-mail.org/faq/index.php/S/MIME_howto , and gpgsm was able to produce a signature. I've re-checked my libraries again (take a look at my previous post also), and all the libraries are the latest ones: ... configure: checking for libraries checking for gpg-error-config... /usr/bin/gpg-error-config checking for GPG Error - version >= 1.11... yes (1.13-beta1) checking for libgcrypt-config... /usr/bin/libgcrypt-config checking for LIBGCRYPT - version >= 1.5.0... yes (1.6.0-beta154) checking LIBGCRYPT API version... okay checking for libassuan-config... /usr/bin/libassuan-config checking for LIBASSUAN - version >= 2.1.0... yes (2.1.2-beta1) checking LIBASSUAN API version... okay checking for ksba-config... /usr/bin/ksba-config checking for KSBA - version >= 1.2.0... yes (1.3.1-beta3) checking KSBA API version... okay checking for usb_bulk_write in -lusb... no checking for usb_create_match... no checking for library containing dlopen... none required checking for encfs... /usr/bin/encfs checking for fusermount... /usr/bin/fusermount checking for openpty in -lutil... yes checking for shred... /usr/bin/shred checking for npth-config... /usr/bin/npth-config checking for NPTH - version >= 0.91... yes (0.91) checking NPTH API version... okay ... ...however, I still could not create a keypair with gpgsm, though doing so with gpg/gpg2 works just fine (why also we have to add quotes around Name-DN?). In addition, I have to kill gpg-agent.exe process every time I need it to start responding to follow-up queries. For some obstructive reason, it does not after its successful first reply. $ gpgsm --gen-key gpgsm (GnuPG) 2.1.0-beta220; Copyright (C) 2012 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. gpgsm: NOTE: THIS IS A DEVELOPMENT VERSION! gpgsm: It is only intended for test purposes and should NOT be gpgsm: used in a production environment or with production keys! gpgsm: enabled debug flags: assuan Please select what kind of key you want: (1) RSA (2) Existing key (3) Existing key from card Your selection? 1 What keysize do you want? (2048) 16834 RSA keysizes must be in the range 1024-4096 What keysize do you want? (2048) 4096 Requested keysize is 4096 bits Possible actions for a RSA key: (1) sign, encrypt (2) sign (3) encrypt Your selection? 1 Enter the X.509 subject name: NAME Invalid subject name 'NAME' ^ Enter the X.509 subject name: 'NAME' Enter email addresses (end with an empty line): > Enter DNS names (optional; end with an empty line): > Enter URIs (optional; end with an empty line): > Create self-signed certificate? (y/N) Y These parameters are used: Key-Type: RSA Key-Length: 4096 Key-Usage: sign, encrypt Serial: random Name-DN: 'NAME' Proceed with creation? (y/N) Y Now creating self-signed certificate. This may take a while ... gpgsm: no running gpg-agent - starting '/usr/bin/gpg-agent' gpgsm: waiting for the agent to come up ... (5s) gpgsm: waiting for the agent to come up ... (4s) gpgsm: DBG: chan_4 <- OK Pleased to meet you, process 6944 gpgsm: connection to agent established gpgsm: DBG: chan_4 -> RESET gpgsm: DBG: chan_4 <- OK gpgsm: DBG: chan_4 -> OPTION ttyname=/dev/pty0 gpgsm: DBG: chan_4 <- OK gpgsm: DBG: chan_4 -> OPTION ttytype=xterm gpgsm: DBG: chan_4 <- OK gpgsm: DBG: chan_4 -> OPTION display=:0.0 gpgsm: DBG: chan_4 <- OK gpgsm: DBG: chan_4 -> OPTION xauthority=~/.Xauthority gpgsm: DBG: chan_4 <- OK gpgsm: DBG: chan_4 -> OPTION lc-ctype=en_US.UTF-8 gpgsm: DBG: chan_4 <- OK gpgsm: DBG: chan_4 -> OPTION lc-messages=en_US.UTF-8 gpgsm: DBG: chan_4 <- OK gpgsm: DBG: chan_4 -> OPTION allow-pinentry-notify gpgsm: DBG: chan_4 <- OK gpgsm: DBG: chan_4 -> RESET gpgsm: DBG: chan_4 <- OK gpgsm: DBG: chan_4 -> GENKEY gpgsm: DBG: chan_4 <- S INQUIRE_MAXLEN 1024 gpgsm: DBG: chan_4 <- INQUIRE KEYPARAM gpgsm: DBG: chan_4 -> D (6:genkey(3:rsa(5:nbits4:4096))) gpgsm: DBG: chan_4 -> END gpgsm: DBG: chan_4 <- INQUIRE PINENTRY_LAUNCHED 27592 gpgsm: DBG: chan_4 -> END gpgsm: DBG: chan_4 <- INQUIRE PINENTRY_LAUNCHED 31548 gpgsm: DBG: chan_4 -> END gpgsm: DBG: chan_4 <- INQUIRE PINENTRY_LAUNCHED 27460 gpgsm: DBG: chan_4 -> END gpgsm: DBG: chan_4 <- INQUIRE PINENTRY_LAUNCHED 26340 gpgsm: DBG: chan_4 -> END gpgsm: DBG: chan_4 <- S CACHE_NONCE F8536E97B6E8BEC79E037C13 gpgsm: DBG: chan_4 <- [ 44 20 28 31 30 3a 70 75 62 6c 69 63 2d 6b 65 79 ...(556 byte(s) skipped) ] gpgsm: DBG: chan_4 <- OK gpgsm: error setting the subject's name: Not implemented gpgsm: error creating certificate request: Not implemented secmem usage: 0/65536 bytes in 0 blocks On Sun, Jun 30, 2013 at 11:46 PM, Werner Koch wrote: > On Sat, 29 Jun 2013 09:37, Vasiliy said: > >> gpgsm: DBG: chan_4 -> ISTRUSTED FB7EAD4851BE76AF04486BA4738A744BFB50DE86 >> gpgsm: DBG: chan_4 <- ERR 67108961 Line too long >> gpgsm: checking the trust list failed: Line too long > > Please check ~/.gnupg.trustlist.txt. A line is longer that 255 bytes. > You will find the above fingerprint there - what is special with that > line? Did you edit it manually, has it been added by GnuPG, or was it > created by Kleopatra or another tool? > >> gpgsm: error setting the subject's name: Not implemented >> gpgsm: error creating certificate request: Not implemented > > You libksba is too old. > > > Shalom-Salam, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > From jussi.kivilinna at iki.fi Mon Jul 1 12:18:51 2013 From: jussi.kivilinna at iki.fi (Jussi Kivilinna) Date: Mon, 01 Jul 2013 13:18:51 +0300 Subject: New amd64 implementations? In-Reply-To: <87vc4zct2y.fsf@vigenere.g10code.de> References: <51C2F224.7000609@iki.fi> <51C92EE3.1060401@iki.fi> <87r4fqmx93.fsf@vigenere.g10code.de> <51CAC4A0.4090304@iki.fi> <87bo6sg5e1.fsf@vigenere.g10code.de> <51CC4D28.7060204@iki.fi> <87vc4zct2y.fsf@vigenere.g10code.de> Message-ID: <51D1578B.2030802@iki.fi> On 27.06.2013 21:21, Werner Koch wrote: > On Thu, 27 Jun 2013 16:33, jussi.kivilinna at iki.fi said: > >> Would it make sense to re-evaluate rndw32.c for current Windows versions (32/64bit) and drop support for Windows versions that have reached end of life? > > Better don't touch it ;-) IIRC, I already remove some old code. > >> As I understand it, the CryptGenRandom function is supported by all current Windows and is the '/dev/urandom' of WIN32. > > I wouldn't trust CryptGenRandom. It is used only as one entropy source. > > What should really be done is to compare the changes Peter did in > Cryptlib and port them back to Libgcrypt. > Here's my observations for latest cryptlib vs libgcrypt. I've also set up git repository that shows differences of cryptlib versions at: "https://github.com/jkivilin/cryptlib-history". From there you can see that __WIN64__ ifdefs appeared in random/ with release 3.3.3. Those ifdefs disable Win95 random poller and change timer/TSC reading from 64-bit. === cryptlib uses same random/win32.c for 64-bit Windows. cryptlib vs libgcrypt slow poll differences: === In cryptlib slow poll is partially done from separate thread; slowPoll() launches thread running slowPollWinNT(). Hardware information (from third party programs) and system RNG is fetched in current thread. In addition to MBM (Motherboard Monitor), cryptlib has sensor reads from: - Everest - SysTool - RivaTuner - HMonitor - ATI Tray Tools - CoreTemp - GPU-Z Libgcrypt does not implement reading of PnP data... "/* readPnPData (); - we have not implemented that. */" cryptlib does not have special handling for win2k systems with pNtQuerySystemInformation ID 17 (SystemObjectInformation). Maybe win2k check can be removed since win2k is EOL. Apart from above, slow poll appear to be quite the same in libgcrypt and cryptlib. cryptlib vs libgcrypt fast poll differences: === cryptlib has 'addRandomHandle' for adding pointer type return values to random pool. This macro discards the upper 32 bits of pointer, casts to 'long'. cryptlib does not use "GetQueueStatus(QS_ALLEVENTS)" as random source because: /* Calling the following function can cause problems in some cases in that a calling application eventually stops getting events from its event loop, so we can't (safely) use it as an entropy source */ /* addRandomValue( randomState, GetQueueStatus( QS_ALLEVENTS ) ); */ cryptlib adds values minimumWorkingSetSize and maximumWorkingSetSize from GetProcessWorkingSetSize to random pool using addRandomValue(), which casts values to 'long'. On 64-bit, this means that upper 32 bits are ignored and not used. cryptlib has 'ifdef __WIN64__' for getting TSC directly with __rdtsc() intrinsic instead of calling QueryPerformanceCounter() or GetTickCount(). cryptlib does VIA RNG and Intel RDRAND in win32 fast poll. -Jussi > > Shalom-Salam, > > Werner > From rick at openfortress.nl Mon Jul 1 12:30:59 2013 From: rick at openfortress.nl (Rick van Rein (OpenFortress)) Date: Mon, 1 Jul 2013 12:30:59 +0200 Subject: could not create a keypair / sign a single file In-Reply-To: References: Message-ID: <2CC95CFD-CD53-4516-9497-B4855C5602A4@openfortress.nl> Vasily, > Enter the X.509 subject name: NAME > Invalid subject name 'NAME' > ^ > Enter the X.509 subject name: 'NAME' The subjectName is a structured text field, and not an arbitrary line of characters. The string "NAME" would not be of the right form, which is what you are being told. The form to use is a distinguishedName, like cn=NAME or uid=testtest_2005,dc=ukr,dc=net -- I think this may also clear up questions about quotes. Cheers, -Rick From wk at gnupg.org Mon Jul 1 13:29:37 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 01 Jul 2013 13:29:37 +0200 Subject: could not create a keypair / sign a single file In-Reply-To: <2CC95CFD-CD53-4516-9497-B4855C5602A4@openfortress.nl> (Rick van Rein's message of "Mon, 1 Jul 2013 12:30:59 +0200") References: <2CC95CFD-CD53-4516-9497-B4855C5602A4@openfortress.nl> Message-ID: <87vc4u8qn2.fsf@vigenere.g10code.de> On Mon, 1 Jul 2013 12:30, rick at openfortress.nl said: > The subjectName is a structured text field, and not an arbitrary line of characters. The string "NAME" would not be of the right form, which is what you are being told. Right. The later returned error "not implemented" however seems to be wrong. That error code is only used for multi-valued RDNs which we don't support - I can't see them in the log, though. I would have expected "syntax error" for calling the DN parser with just 'NAME'. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From ametzler at downhill.at.eu.org Mon Jul 1 19:41:41 2013 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Mon, 1 Jul 2013 19:41:41 +0200 Subject: No secmem support on kfreebsd-amd64 In-Reply-To: <877ghaacdc.fsf@vigenere.g10code.de> References: <20130630172728.GA3233@downhill.g.la> <877ghaacdc.fsf@vigenere.g10code.de> Message-ID: <20130701174141.GA3288@downhill.g.la> On 2013-07-01 Werner Koch wrote: > On Sun, 30 Jun 2013 19:27, ametzler at downhill.at.eu.org said: >> it looks like secmem support is broken on kfreebsd-amd64 (gcrypt 1.5.2): > Only on -amd64? Currently I have only a 32 bit kfreebox in use thus I > am not able to test it right now. Hello, let's test it ... It is broken on 32bit, too. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' From wk at gnupg.org Mon Jul 1 21:24:27 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 01 Jul 2013 21:24:27 +0200 Subject: No secmem support on kfreebsd-amd64 In-Reply-To: <20130701174141.GA3288@downhill.g.la> (Andreas Metzler's message of "Mon, 1 Jul 2013 19:41:41 +0200") References: <20130630172728.GA3233@downhill.g.la> <877ghaacdc.fsf@vigenere.g10code.de> <20130701174141.GA3288@downhill.g.la> Message-ID: <87bo6m6q38.fsf@vigenere.g10code.de> On Mon, 1 Jul 2013 19:41, ametzler at downhill.at.eu.org said: > It is broken on 32bit, too. That makes it easy for me to test. May take a few days - I am pretty busy this week. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From o.jasper at gmail.com Wed Jul 3 15:44:31 2013 From: o.jasper at gmail.com (Jasper) Date: Wed, 3 Jul 2013 15:44:31 +0200 Subject: a platform with which each gnupg identity can put out notifications Message-ID: <20130703154431.57fcdb60.o.jasper@gmail.com> Is there a system with which you can have each gpg identity put notifications out? Basically the idea is that you feed it signed files, and it verifies, figures out the identity, and puts the files in a directory(if the key not yet revoked/outdated etcetera), each corresponding to one identity.(Though they will have to be connectable when a user changes private key) The directory would be used to receive data which other programs can then use. The main use i have in mind is a 'distributed reddit' where you give points to persons who are good at indicating or rating interesting articles. The program uses the data to make a list ordered by interestingness, allows you to give points yourself, and it could also publish some calculated estimates about stuff you havent read about.(So you propagate interesting articles without neccessarily having read them) For more on this: http://www.reddit.com/r/darknet/comments/1fwfjt/cant_we_make_a_darkreddit/ The unit of distributing notifications should imo be the file. So the source doesnt matter; you could put it on a memory stick, steghide it into a picture, flicker a led light and use a telescope to catch it, or just put it on a server for all to see. Email clients etcetera could then be configurable to identify and outomatically add this file. But it would be useful for other things too; * distributed wikis * 'voting systems'/todo systems * vetting code? Trust/competence estimates on code based on people indicating they reviewed it/wrote it. Something like this might already exist. I am an idiot about choosing/figuring out tools/libraries sometimes.. Could you advise about how this can be a good/bad idea? Wrote some code(attachment), but it seems i havent figured out how to parse the signature right.(and probably still issues after that) Also i think probably the stuff should be tarballed, so it'd immediately indicate directories inside. Advice on how to implement it is also welcome. -------------- next part -------------- A non-text attachment was scrubbed... Name: by_fingerprint.tar.gz Type: application/gzip Size: 31853 bytes Desc: not available URL: From wk at gnupg.org Wed Jul 3 20:54:48 2013 From: wk at gnupg.org (Werner Koch) Date: Wed, 03 Jul 2013 20:54:48 +0200 Subject: a platform with which each gnupg identity can put out notifications In-Reply-To: <20130703154431.57fcdb60.o.jasper@gmail.com> (Jasper's message of "Wed, 3 Jul 2013 15:44:31 +0200") References: <20130703154431.57fcdb60.o.jasper@gmail.com> Message-ID: <878v1n5v9j.fsf@vigenere.g10code.de> Hello Jasper, this is the Libgcrypt development list. You probably want to send your question to the gnupg-users at gnupg.org mailing list. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From o.jasper at gmail.com Fri Jul 12 15:25:04 2013 From: o.jasper at gmail.com (Jasper den Ouden) Date: Fri, 12 Jul 2013 15:25:04 +0200 Subject: a platform with which each gnupg identity can put out notifications Message-ID: <51E003B0.6070602@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sorry for taking so long to reply, was kindah still hoping for some feedback.(But understand if its not worth the time/or just people not seeing it) I'll try again at the gnupg list. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIbBAEBAgAGBQJR4AOuAAoJEJyFfbXiRwmSMAkP+PToPs4gNFBTKbRAlckbQndW 50+Mc5XbNfU51OR+PW4wnxJX1t6tSI3+2WUJ9wQjLASHJzLaK7UhGwle+gdfoIma 7AXDBzjxH+L+Hd0xRA5WKdaMs6vCrxU2DtOObVx/g5X7vXSF7jQL2gkTmujilcGx kUNZ03lbD4cD0JvTsU6ITkJbbgRYKn7yqXQQ7JHwLDnB4r/NKBGRYI2jj3By2lkf 8fj5k67w14IXNfqi0JmeDzmGtzmYu419yPmPgmhrSMFSWoXMOaB6nWI1tbkxXeI9 xuyKn9g/9RPv3oVTte1L4pRdUF+oHUcswPN0XJyP0CqBfHW6ULhFCB6qkZVzdk88 b/+4zsJ/t7N+GENOc4p+y6Sp0VDAF60/yFgM/sBG1X3hDU5tjJTIRnXcnT6Ddm6R uVg1F037Adet+rxYnevh9pZXbLChqAMUugb8jWga64ptZPy2Yr+PUsLkjo4wwDkk TNND+IpVTdvMpJrGESZHn44wumxWMtptx/Ru/uLOdYmfTltCUBSMBG7f+sjssndF JzhTDMy6vr6zJ7IHtdmT0gmQFPn5KbtViwvs1eFBqJn3erwm1GXRV06fZX1XzIP9 9OglYYidU6O29HutfnNU4AJkxE12y3im5sJYGZg/UpZFygiqhDP7Ev3/Zbu02nXa 7hZVjbOa0MfqSTcFNCM= =3Bdh -----END PGP SIGNATURE----- From dbaryshkov at gmail.com Sat Jul 13 16:50:05 2013 From: dbaryshkov at gmail.com (Dmitry Eremin-Solenikov) Date: Sat, 13 Jul 2013 18:50:05 +0400 Subject: [PATCH 1/3] Fix memory leak in t-mpi-point test Message-ID: <1373727007-1617-1-git-send-email-dbaryshkov@gmail.com> * tests/t-mpi-point.c (basic_ec_math, basic_ec_math_simplified): add calls to gcry_ctx_release() to free contexts after they become unused. Signed-off-by: Dmitry Eremin-Solenikov --- tests/t-mpi-point.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tests/t-mpi-point.c b/tests/t-mpi-point.c index 98236e7..3ee57dc 100644 --- a/tests/t-mpi-point.c +++ b/tests/t-mpi-point.c @@ -643,6 +643,7 @@ basic_ec_math (void) gcry_mpi_point_release (G); gcry_mpi_release (A); gcry_mpi_release (P); + gcry_ctx_release (ctx); } @@ -761,6 +762,7 @@ basic_ec_math_simplified (void) gcry_mpi_point_release (Q); gcry_mpi_release (d); gcry_mpi_point_release (G); + gcry_ctx_release (ctx); } -- 1.7.10.4 From dbaryshkov at gmail.com Sat Jul 13 16:44:07 2013 From: dbaryshkov at gmail.com (Dmitry Eremin-Solenikov) Date: Sat, 13 Jul 2013 18:44:07 +0400 Subject: DCO Message-ID: <20130713144407.GA27334@fangorn.rup.mentorg.com> Libgcrypt Developer's Certificate of Origin. Version 1.0 ========================================================= By making a contribution to the Libgcrypt project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the free software license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate free software license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same free software license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the free software license(s) involved. Signed-off-by: Dmitry Eremin-Solenikov -- With best wishes Dmitry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From dbaryshkov at gmail.com Sat Jul 13 16:50:06 2013 From: dbaryshkov at gmail.com (Dmitry Eremin-Solenikov) Date: Sat, 13 Jul 2013 18:50:06 +0400 Subject: [PATCH 2/3] Specify stack_burn for SHA256 cipher In-Reply-To: <1373727007-1617-1-git-send-email-dbaryshkov@gmail.com> References: <1373727007-1617-1-git-send-email-dbaryshkov@gmail.com> Message-ID: <1373727007-1617-2-git-send-email-dbaryshkov@gmail.com> * cipher/sha256.c (sha256_init): fill stack_burn information for SHA256 cipher, which otherwise will contain random value. Signed-off-by: Dmitry Eremin-Solenikov --- cipher/sha256.c | 1 + 1 file changed, 1 insertion(+) diff --git a/cipher/sha256.c b/cipher/sha256.c index 975612b..1785699 100644 --- a/cipher/sha256.c +++ b/cipher/sha256.c @@ -70,6 +70,7 @@ sha256_init (void *context) hd->bctx.nblocks = 0; hd->bctx.count = 0; hd->bctx.blocksize = 64; + hd->bctx.stack_burn = 74*4+32; hd->bctx.bwrite = transform; } -- 1.7.10.4 From dbaryshkov at gmail.com Sat Jul 13 16:50:07 2013 From: dbaryshkov at gmail.com (Dmitry Eremin-Solenikov) Date: Sat, 13 Jul 2013 18:50:07 +0400 Subject: [PATCH 3/3] Add a simple PKCS#1 padding mode In-Reply-To: <1373727007-1617-1-git-send-email-dbaryshkov@gmail.com> References: <1373727007-1617-1-git-send-email-dbaryshkov@gmail.com> Message-ID: <1373727007-1617-3-git-send-email-dbaryshkov@gmail.com> * cipher/pubkey.c (sexp_data_to_mpi, pkcs1_encode_for_signature_simple): handle s-exp like (data (flags pkcs1) (value xxxxx)) Allow user to specify (flags pkcs1) to enable pkcs1 padding of raw value (no hash algorithm is specified). It is up to the user to verify that passed value is properly formatted and includes DER-encoded ASN OID of the hash function. Signed-off-by: Dmitry Eremin-Solenikov --- cipher/pubkey.c | 81 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ tests/basic.c | 2 +- 2 files changed, 82 insertions(+), 1 deletion(-) diff --git a/cipher/pubkey.c b/cipher/pubkey.c index 378e072..028cbb4 100644 --- a/cipher/pubkey.c +++ b/cipher/pubkey.c @@ -1126,6 +1126,73 @@ pkcs1_encode_for_signature (gcry_mpi_t *r_result, unsigned int nbits, } +/* Encode {VALUE,VALUELEN} for an NBITS keys and hash algorith ALGO + using the pkcs#1 block type 1 padding. On success the result is + stored as a new MPI at R_RESULT. On error the value at R_RESULT is + undefined. + + We encode the value in this way: + + 0 1 PAD(n bytes) 0 VALUE(valuelen bytes) + + 0 is a marker we unfortunately can't encode because we return an + MPI which strips all leading zeroes. + 1 is the block type. + PAD consists of 0xff bytes. + 0 marks the end of the padding. + + (Note that PGP prior to version 2.3 encoded the message digest as: + 0 1 MD(16 bytes) 0 PAD(n bytes) 1 + The MD is always 16 bytes here because it's always MD5. GnuPG + does not not support pre-v2.3 signatures, but I'm including this + comment so the information is easily found if needed.) +*/ +static gcry_err_code_t +pkcs1_encode_for_signature_simple (gcry_mpi_t *r_result, unsigned int nbits, + const unsigned char *value, size_t valuelen) +{ + gcry_err_code_t rc = 0; + gcry_error_t err; + byte *frame = NULL; + size_t nframe = (nbits+7) / 8; + int i; + size_t n; + + if ( !valuelen || valuelen + 4 > nframe) + { + /* Can't encode an DLEN byte digest MD into an NFRAME byte + frame. */ + return GPG_ERR_TOO_SHORT; + } + + if ( !(frame = gcry_malloc (nframe)) ) + return gpg_err_code_from_syserror (); + + /* Assemble the pkcs#1 block type 1. */ + n = 0; + frame[n++] = 0; + frame[n++] = 1; /* block type */ + i = nframe - valuelen - 3 ; + gcry_assert (i > 1); + memset (frame+n, 0xff, i ); + n += i; + frame[n++] = 0; + memcpy (frame+n, value, valuelen ); + n += valuelen; + gcry_assert (n == nframe); + + /* Convert it into an MPI. */ + err = gcry_mpi_scan (r_result, GCRYMPI_FMT_USG, frame, n, &nframe); + if (err) + rc = gcry_err_code (err); + else if (DBG_CIPHER) + log_mpidump ("PKCS#1 block type 1 encoded data", *r_result); + gcry_free (frame); + + return rc; +} + + /* Mask generation function for OAEP. See RFC-3447 B.2.1. */ static gcry_err_code_t mgf1 (unsigned char *output, size_t outlen, unsigned char *seed, size_t seedlen, @@ -2602,6 +2669,20 @@ sexp_data_to_mpi (gcry_sexp_t input, gcry_mpi_t *ret_mpi, gcry_free (random_override); } } + else if (ctx->encoding == PUBKEY_ENC_PKCS1 && lvalue + && (ctx->op == PUBKEY_OP_SIGN || ctx->op == PUBKEY_OP_VERIFY)) + { + const void * value; + size_t valuelen; + + if ( !(value=gcry_sexp_nth_data (lvalue, 1, &valuelen)) || !valuelen ) + rc = GPG_ERR_INV_OBJ; + else + { + rc = pkcs1_encode_for_signature_simple (ret_mpi, ctx->nbits, + value, valuelen); + } + } else if (ctx->encoding == PUBKEY_ENC_PKCS1 && lhash && (ctx->op == PUBKEY_OP_SIGN || ctx->op == PUBKEY_OP_VERIFY)) { diff --git a/tests/basic.c b/tests/basic.c index 01bdd46..a9cdbe6 100644 --- a/tests/basic.c +++ b/tests/basic.c @@ -2456,7 +2456,7 @@ check_pubkey_sign (int n, gcry_sexp_t skey, gcry_sexp_t pkey, int algo) { "(data\n (flags pkcs1)\n" " (value #11223344556677889900AA#))\n", GCRY_PK_RSA, - GPG_ERR_CONFLICT }, + 0 }, { "(data\n (flags raw foo)\n" " (value #11223344556677889900AA#))\n", 0, -- 1.7.10.4 From wk at gnupg.org Mon Jul 15 09:53:32 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 15 Jul 2013 09:53:32 +0200 Subject: [PATCH 2/3] Specify stack_burn for SHA256 cipher In-Reply-To: <1373727007-1617-2-git-send-email-dbaryshkov@gmail.com> (Dmitry Eremin-Solenikov's message of "Sat, 13 Jul 2013 18:50:06 +0400") References: <1373727007-1617-1-git-send-email-dbaryshkov@gmail.com> <1373727007-1617-2-git-send-email-dbaryshkov@gmail.com> Message-ID: <87ehb0nts3.fsf@vigenere.g10code.de> On Sat, 13 Jul 2013 16:50, dbaryshkov at gmail.com said: > hd->bctx.count = 0; > hd->bctx.blocksize = 64; > + hd->bctx.stack_burn = 74*4+32; I can't find the original code. Is that based on a private branch? [I applied the the first patch. Thanks] Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dbaryshkov at gmail.com Mon Jul 15 11:26:59 2013 From: dbaryshkov at gmail.com (Dmitry Eremin-Solenikov) Date: Mon, 15 Jul 2013 13:26:59 +0400 Subject: [PATCH 2/3] Specify stack_burn for SHA256 cipher In-Reply-To: <87ehb0nts3.fsf@vigenere.g10code.de> References: <1373727007-1617-1-git-send-email-dbaryshkov@gmail.com> <1373727007-1617-2-git-send-email-dbaryshkov@gmail.com> <87ehb0nts3.fsf@vigenere.g10code.de> Message-ID: On Mon, Jul 15, 2013 at 11:53 AM, Werner Koch wrote: > On Sat, 13 Jul 2013 16:50, dbaryshkov at gmail.com said: > >> hd->bctx.count = 0; >> hd->bctx.blocksize = 64; >> + hd->bctx.stack_burn = 74*4+32; > > I can't find the original code. Is that based on a private branch? Ah... It looks so. I refactored most of hash functions working with blocks of data, but did it so long ago, that I forgot about that. Would you be interested in a patch that separates common block-handling code from hash functions (except whirpool and sha512)? -- With best wishes Dmitry From dbaryshkov at gmail.com Mon Jul 15 12:54:54 2013 From: dbaryshkov at gmail.com (Dmitry Eremin-Solenikov) Date: Mon, 15 Jul 2013 14:54:54 +0400 Subject: DCO In-Reply-To: References: <20130713144407.GA27334@fangorn.rup.mentorg.com> Message-ID: On Mon, Jul 15, 2013 at 2:34 PM, Dmitry Kasatkin wrote: > On Sat, Jul 13, 2013 at 5:44 PM, Dmitry Eremin-Solenikov > wrote: >> >> Signed-off-by: Dmitry Eremin-Solenikov >> > > Considering that email address is a sort of logically ordered letters, > your family name does not correspond to one in the email address. Changed my surname after getting married :) -- With best wishes Dmitry From wk at gnupg.org Mon Jul 15 15:15:34 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 15 Jul 2013 15:15:34 +0200 Subject: [PATCH 2/3] Specify stack_burn for SHA256 cipher In-Reply-To: (Dmitry Eremin-Solenikov's message of "Mon, 15 Jul 2013 13:26:59 +0400") References: <1373727007-1617-1-git-send-email-dbaryshkov@gmail.com> <1373727007-1617-2-git-send-email-dbaryshkov@gmail.com> <87ehb0nts3.fsf@vigenere.g10code.de> Message-ID: <87k3ksm0ax.fsf@vigenere.g10code.de> On Mon, 15 Jul 2013 11:26, dbaryshkov at gmail.com said: > Would you be interested in a patch that separates common > block-handling code from hash functions (except whirpool and > sha512)? In general yes. But at the moment I would prefer to work on other things first and don't add another construction area. Please keep them somewhere. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Jul 15 15:18:12 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 15 Jul 2013 15:18:12 +0200 Subject: DCO In-Reply-To: (Dmitry Eremin-Solenikov's message of "Mon, 15 Jul 2013 14:54:54 +0400") References: <20130713144407.GA27334@fangorn.rup.mentorg.com> Message-ID: <87fvvgm06j.fsf@vigenere.g10code.de> On Mon, 15 Jul 2013 12:54, dbaryshkov at gmail.com said: > Changed my surname after getting married :) My congratulations to both of you. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dmitry.kasatkin at gmail.com Mon Jul 15 12:34:13 2013 From: dmitry.kasatkin at gmail.com (Dmitry Kasatkin) Date: Mon, 15 Jul 2013 13:34:13 +0300 Subject: DCO In-Reply-To: <20130713144407.GA27334@fangorn.rup.mentorg.com> References: <20130713144407.GA27334@fangorn.rup.mentorg.com> Message-ID: On Sat, Jul 13, 2013 at 5:44 PM, Dmitry Eremin-Solenikov wrote: > Libgcrypt Developer's Certificate of Origin. Version 1.0 > ========================================================= > > By making a contribution to the Libgcrypt project, I certify that: > > (a) The contribution was created in whole or in part by me and I > have the right to submit it under the free software license > indicated in the file; or > > (b) The contribution is based upon previous work that, to the > best of my knowledge, is covered under an appropriate free > software license and I have the right under that license to > submit that work with modifications, whether created in whole > or in part by me, under the same free software license > (unless I am permitted to submit under a different license), > as indicated in the file; or > > (c) The contribution was provided directly to me by some other > person who certified (a), (b) or (c) and I have not modified > it. > > (d) I understand and agree that this project and the contribution > are public and that a record of the contribution (including > all personal information I submit with it, including my > sign-off) is maintained indefinitely and may be redistributed > consistent with this project or the free software license(s) > involved. > > Signed-off-by: Dmitry Eremin-Solenikov > Considering that email address is a sort of logically ordered letters, your family name does not correspond to one in the email address. :) > -- > With best wishes > Dmitry > > _______________________________________________ > Gcrypt-devel mailing list > Gcrypt-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gcrypt-devel > From linux at paip.net Tue Jul 16 23:27:00 2013 From: linux at paip.net (Ian Goldberg) Date: Tue, 16 Jul 2013 17:27:00 -0400 Subject: Crash in gcry_mpi_powm Message-ID: <20130716212700.GR2200@yoink.cs.uwaterloo.ca> Am I doing something crazy wrong here? I'm compiling the attached testcase.c program with: gcc -g -O0 testcase.c -o testcase -lgcrypt It takes a number x as a command-line argument, and computes 3^x mod 100 (output in hex). If I pass something non-zero, all is well: $ ./testcase 5 exponent = 5 result = 2B But if I pass zero, it segfaults in gcry_mpi_powm: $ valgrind ./testcase 0 ==19837== Memcheck, a memory error detector ==19837== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==19837== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info ==19837== Command: ./testcase 0 ==19837== exponent = 0 ==19837== Invalid write of size 4 ==19837== at 0x4090FEB: ??? (in /lib/libgcrypt.so.11.5.2) ==19837== by 0x4046001: gcry_mpi_powm (in /lib/libgcrypt.so.11.5.2) ==19837== by 0x80488FE: main (testcase.c:34) ==19837== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==19837== ==19837== ==19837== Process terminating with default action of signal 11 (SIGSEGV) ==19837== Access not within mapped region at address 0x0 ==19837== at 0x4090FEB: ??? (in /lib/libgcrypt.so.11.5.2) ==19837== by 0x4046001: gcry_mpi_powm (in /lib/libgcrypt.so.11.5.2) ==19837== by 0x80488FE: main (testcase.c:34) ==19837== If you believe this happened as a result of a stack ==19837== overflow in your program's main thread (unlikely but ==19837== possible), you can try to increase the size of the ==19837== main thread stack using the --main-stacksize= flag. ==19837== The main thread stack size used in this run was 8388608. ==19837== ==19837== HEAP SUMMARY: ==19837== in use at exit: 1,100 bytes in 43 blocks ==19837== total heap usage: 45 allocs, 2 frees, 1,477 bytes allocated ==19837== ==19837== LEAK SUMMARY: ==19837== definitely lost: 0 bytes in 0 blocks ==19837== indirectly lost: 0 bytes in 0 blocks ==19837== possibly lost: 0 bytes in 0 blocks ==19837== still reachable: 1,100 bytes in 43 blocks ==19837== suppressed: 0 bytes in 0 blocks ==19837== Rerun with --leak-check=full to see details of leaked memory ==19837== ==19837== For counts of detected and suppressed errors, rerun with: -v ==19837== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 16 from 7) Segmentation fault I get the same results on Ubuntu 10.04 32-bit and Ubuntu 12.04 64-bit except the latter reports a write of size 8 and a different minor version number for libgcrypt.so: ==17872== Invalid write of size 8 ==17872== at 0x4E82EBC: ??? (in /lib/x86_64-linux-gnu/libgcrypt.so.11.7.0) ==17872== by 0x400AB0: main (testcase.c:34) ==17872== Address 0x0 is not stack'd, malloc'd or (recently) free'd I'm sure I'm doing something wrong, but the program is extremely simple. Any ideas? Thanks, - Ian -------------- next part -------------- A non-text attachment was scrubbed... Name: testcase.c Type: text/x-csrc Size: 1189 bytes Desc: not available URL: From wk at gnupg.org Wed Jul 17 10:21:48 2013 From: wk at gnupg.org (Werner Koch) Date: Wed, 17 Jul 2013 10:21:48 +0200 Subject: Crash in gcry_mpi_powm In-Reply-To: <20130716212700.GR2200@yoink.cs.uwaterloo.ca> (Ian Goldberg's message of "Tue, 16 Jul 2013 17:27:00 -0400") References: <20130716212700.GR2200@yoink.cs.uwaterloo.ca> Message-ID: <877ggpha03.fsf@vigenere.g10code.de> On Tue, 16 Jul 2013 23:27, linux at paip.net said: > But if I pass zero, it segfaults in gcry_mpi_powm: Find a patch below. I am going to apply this also to stable. You may want to use the workaround for now. Shalom-Salam, Werner >From 6e1adb05d290aeeb1c230c763970695f4a538526 Mon Sep 17 00:00:00 2001 From: Werner Koch Date: Wed, 17 Jul 2013 10:18:39 +0200 Subject: [PATCH] Fix a special case bug in mpi_powm for e==0. * mpi/mpi-pow.c (gcry_mpi_powm): For a zero exponent, make sure that the result has been allocated. -- This code triggered the problem: modulus = gcry_mpi_set_ui(NULL, 100); generator = gcry_mpi_set_ui(NULL, 3); exponent = gcry_mpi_set_ui(NULL, 0); result = gcry_mpi_new(0); gcry_mpi_powm(result, generator, exponent, modulus); gcry_mpi_new(0) does not allocate the limb space thus it is not possible to write even into the first limb. Workaround was to use gcry_mpi_new (1) but a real fix is better. Reported-by: Ian Goldberg Signed-off-by: Werner Koch --- mpi/mpi-pow.c | 9 +++++++-- 1 files changed, 7 insertions(+), 2 deletions(-) diff --git a/mpi/mpi-pow.c b/mpi/mpi-pow.c index 891a7e6..7ec49d7 100644 --- a/mpi/mpi-pow.c +++ b/mpi/mpi-pow.c @@ -81,9 +81,14 @@ gcry_mpi_powm (gcry_mpi_t res, if (!esize) { /* Exponent is zero, result is 1 mod MOD, i.e., 1 or 0 depending - on if MOD equals 1. */ - rp[0] = 1; + on if MOD equals 1. */ res->nlimbs = (msize == 1 && mod->d[0] == 1) ? 0 : 1; + if (res->nlimbs) + { + RESIZE_IF_NEEDED (res, 1); + rp = res->d; + rp[0] = 1; + } res->sign = 0; goto leave; } -- 1.7.7.1 -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From linux at paip.net Thu Jul 18 13:55:30 2013 From: linux at paip.net (Ian Goldberg) Date: Thu, 18 Jul 2013 07:55:30 -0400 Subject: Crash in gcry_mpi_powm In-Reply-To: <877ggpha03.fsf@vigenere.g10code.de> References: <20130716212700.GR2200@yoink.cs.uwaterloo.ca> <877ggpha03.fsf@vigenere.g10code.de> Message-ID: <20130718115530.GA31706@thunk.cs.uwaterloo.ca> On Wed, Jul 17, 2013 at 10:21:48AM +0200, Werner Koch wrote: > On Tue, 16 Jul 2013 23:27, linux at paip.net said: > > > But if I pass zero, it segfaults in gcry_mpi_powm: > > Find a patch below. I am going to apply this also to stable. You may > want to use the workaround for now. > > > Shalom-Salam, > > Werner Thanks! - Ian From dbaryshkov at gmail.com Sun Jul 21 16:53:22 2013 From: dbaryshkov at gmail.com (Dmitry Eremin-Solenikov) Date: Sun, 21 Jul 2013 18:53:22 +0400 Subject: [PATCH] Add support for Salsa20/12 - 12 round version of Salsa20 Message-ID: <1374418402-25336-1-git-send-email-dbaryshkov@gmail.com> * src/gcrypt.h.in (GCRY_CIPHER_SALSA20R12): New. * src/salsa20.c (salsa20_core, salsa20_do_encrypt_stream): Add support for reduced round versions. (salsa20r12_encrypt_stream, _gcry_cipher_spec_salsa20r12): Implement Salsa20/12 - a 12 round version of Salsa20 selected by eStream. * src/cipher.h: Declsare Salsa20/12 definition. * cipher/cipher.c: Register Salsa20/12 * tests/basic.c: (check_stream_cipher, check_stream_cipher_large_block): Populate Salsa20/12 tests with test vectors from ecrypt (check_ciphers): Add simple test for Salsa20/12 -- Salsa20/12 is a reduced round version of Salsa20 that is amongst ciphers selected by eSTREAM for Phase 3 of Profile 1 algorithm. Moreover it is one of proposed ciphers for TLS (draft-josefsson-salsa20-tls-02). Signed-off-by: Dmitry Eremin-Solenikov --- NEWS | 3 +- cipher/cipher.c | 2 + cipher/salsa20.c | 49 ++++++++++-- doc/gcrypt.texi | 4 + src/cipher.h | 1 + src/gcrypt.h.in | 3 +- tests/basic.c | 218 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 7 files changed, 273 insertions(+), 7 deletions(-) diff --git a/NEWS b/NEWS index 508b943..3e47400 100644 --- a/NEWS +++ b/NEWS @@ -12,7 +12,7 @@ Noteworthy changes in version 1.6.0 (unreleased) * Added support for the IDEA cipher algorithm. - * Added support for the Salsa20 stream cipher. + * Added support for the Salsa20 and reduced Salsa20/12 stream ciphers. * Added a random number generator to directly use the system's RNG. Also added an interface to prefer the use of a specified RNG. @@ -74,6 +74,7 @@ Noteworthy changes in version 1.6.0 (unreleased) GCRYCTL_DISABLE_PRIV_DROP NEW. GCRY_CIPHER_SALSA20 NEW. gcry_sexp_nth_buffer NEW. + GCRY_CIPHER_SALSA20R12 NEW. Noteworthy changes in version 1.5.0 (2011-06-29) diff --git a/cipher/cipher.c b/cipher/cipher.c index 08d6165..7b320c4 100644 --- a/cipher/cipher.c +++ b/cipher/cipher.c @@ -107,6 +107,8 @@ static struct cipher_table_entry #if USE_SALSA20 { &_gcry_cipher_spec_salsa20, &_gcry_cipher_extraspec_salsa20, GCRY_CIPHER_SALSA20 }, + { &_gcry_cipher_spec_salsa20r12, + &_gcry_cipher_extraspec_salsa20, GCRY_CIPHER_SALSA20R12 }, #endif { NULL } }; diff --git a/cipher/salsa20.c b/cipher/salsa20.c index e26c328..2fd77e0 100644 --- a/cipher/salsa20.c +++ b/cipher/salsa20.c @@ -49,6 +49,7 @@ /* Number of rounds. The standard uses 20 rounds. In any case the number of rounds must be even. */ #define SALSA20_ROUNDS 20 +#define SALSA20r12_ROUNDS 12 typedef struct @@ -120,13 +121,13 @@ static const char *selftest (void); } while(0) static void -salsa20_core (u32 *dst, const u32 *src) +salsa20_core (u32 *dst, const u32 *src, unsigned rounds) { u32 pad[SALSA20_INPUT_LENGTH]; unsigned int i; memcpy (pad, src, sizeof(pad)); - for (i = 0; i < SALSA20_ROUNDS; i += 2) + for (i = 0; i < rounds; i += 2) { SALSA20_CORE_DEBUG (i); QROUND (pad[0], pad[4], pad[8], pad[12]); @@ -253,7 +254,7 @@ salsa20_setiv (void *context, const byte *iv, unsigned int ivlen) static void salsa20_do_encrypt_stream (SALSA20_context_t *ctx, byte *outbuf, const byte *inbuf, - unsigned int length) + unsigned int length, unsigned rounds) { if (ctx->unused) { @@ -280,7 +281,7 @@ salsa20_do_encrypt_stream (SALSA20_context_t *ctx, /* Create the next pad and bump the block counter. Note that it is the user's duty to change to another nonce not later than after 2^70 processed bytes. */ - salsa20_core (ctx->pad, ctx->input); + salsa20_core (ctx->pad, ctx->input, rounds); if (!++ctx->input[8]) ctx->input[9]++; @@ -306,7 +307,30 @@ salsa20_encrypt_stream (void *context, if (length) { - salsa20_do_encrypt_stream (ctx, outbuf, inbuf, length); + salsa20_do_encrypt_stream (ctx, outbuf, inbuf, length, SALSA20_ROUNDS); + _gcry_burn_stack (/* salsa20_do_encrypt_stream: */ + 2*sizeof (void*) + + 3*sizeof (void*) + sizeof (unsigned int) + /* salsa20_core: */ + + 2*sizeof (void*) + + 2*sizeof (void*) + + 64 + + sizeof (unsigned int) + + sizeof (u32) + ); + } +} + + +static void +salsa20r12_encrypt_stream (void *context, + byte *outbuf, const byte *inbuf, unsigned int length) +{ + SALSA20_context_t *ctx = (SALSA20_context_t *)context; + + if (length) + { + salsa20_do_encrypt_stream (ctx, outbuf, inbuf, length, SALSA20r12_ROUNDS); _gcry_burn_stack (/* salsa20_do_encrypt_stream: */ 2*sizeof (void*) + 3*sizeof (void*) + sizeof (unsigned int) @@ -372,6 +396,21 @@ gcry_cipher_spec_t _gcry_cipher_spec_salsa20 = salsa20_encrypt_stream }; +gcry_cipher_spec_t _gcry_cipher_spec_salsa20r12 = + { + "SALSA20/12", /* name */ + NULL, /* aliases */ + NULL, /* oids */ + 1, /* blocksize in bytes. */ + SALSA20_MAX_KEY_SIZE*8, /* standard key length in bits. */ + sizeof (SALSA20_context_t), + salsa20_setkey, + NULL, + NULL, + salsa20r12_encrypt_stream, + salsa20r12_encrypt_stream + }; + cipher_extra_spec_t _gcry_cipher_extraspec_salsa20 = { NULL, diff --git a/doc/gcrypt.texi b/doc/gcrypt.texi index 770a245..b49dee3 100644 --- a/doc/gcrypt.texi +++ b/doc/gcrypt.texi @@ -1579,6 +1579,10 @@ The Camellia cipher by NTT. See @cindex Salsa20 This is the Salsa20 stream cipher. + at item GCRY_CIPHER_SALSA20R12 + at cindex Salsa20/12 +This is the Salsa20/12 - reduced round version of Salsa20 stream cipher. + @end table @node Available cipher modes diff --git a/src/cipher.h b/src/cipher.h index bb92758..710061a 100644 --- a/src/cipher.h +++ b/src/cipher.h @@ -196,6 +196,7 @@ extern gcry_cipher_spec_t _gcry_cipher_spec_camellia192; extern gcry_cipher_spec_t _gcry_cipher_spec_camellia256; extern gcry_cipher_spec_t _gcry_cipher_spec_idea; extern gcry_cipher_spec_t _gcry_cipher_spec_salsa20; +extern gcry_cipher_spec_t _gcry_cipher_spec_salsa20r12; extern cipher_extra_spec_t _gcry_cipher_extraspec_tripledes; extern cipher_extra_spec_t _gcry_cipher_extraspec_aes; diff --git a/src/gcrypt.h.in b/src/gcrypt.h.in index 06d6663..ce7c154 100644 --- a/src/gcrypt.h.in +++ b/src/gcrypt.h.in @@ -820,7 +820,8 @@ enum gcry_cipher_algos GCRY_CIPHER_CAMELLIA128 = 310, GCRY_CIPHER_CAMELLIA192 = 311, GCRY_CIPHER_CAMELLIA256 = 312, - GCRY_CIPHER_SALSA20 = 313 + GCRY_CIPHER_SALSA20 = 313, + GCRY_CIPHER_SALSA20R12 = 314 }; /* The Rijndael algorithm is basically AES, so provide some macros. */ diff --git a/tests/basic.c b/tests/basic.c index 46e213c..4fbca43 100644 --- a/tests/basic.c +++ b/tests/basic.c @@ -1241,6 +1241,91 @@ check_stream_cipher (void) "\x2B\xB2\x55\x71\xE1\xAA\x85\x93\x75\x8F\xC3\x82\xB1\x28\x0B\x71" } } + }, + { + "Salsa20/12 128 bit, test 1", + GCRY_CIPHER_SALSA20R12, 16, 8, + "\x80\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00", + "\x00\x00\x00\x00\x00\x00\x00\x00", + { + { 8, + "\x00\x00\x00\x00\x00\x00\x00\x00", + "\xFC\x20\x7D\xBF\xC7\x6C\x5E\x17" + } + } + }, + { + "Salsa20/12 128 bit, test 2", + GCRY_CIPHER_SALSA20R12, 16, 8, + "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00", + "\x80\x00\x00\x00\x00\x00\x00\x00", + { + { 8, + "\x00\x00\x00\x00\x00\x00\x00\x00", + "\x08\x28\x39\x9A\x6F\xEF\x20\xDA" + } + } + }, + { + "Salsa20/12 128 bit, test 3", + GCRY_CIPHER_SALSA20R12, 16, 8, + "\x00\x53\xA6\xF9\x4C\x9F\xF2\x45\x98\xEB\x3E\x91\xE4\x37\x8A\xDD", + "\x0D\x74\xDB\x42\xA9\x10\x77\xDE", + { + { 8, + "\x00\x00\x00\x00\x00\x00\x00\x00", + "\xAD\x9E\x60\xE6\xD2\xA2\x64\xB8" + } + } + }, + { + "Salsa20/12 256 bit, test 1", + GCRY_CIPHER_SALSA20R12, 32, 8, + "\x80\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00" + "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00", + "\x00\x00\x00\x00\x00\x00\x00\x00", + { + { 8, + "\x00\x00\x00\x00\x00\x00\x00\x00", + "\xAF\xE4\x11\xED\x1C\x4E\x07\xE4" + } + } + }, + { + "Salsa20/12 256 bit, test 2", + GCRY_CIPHER_SALSA20R12, 32, 8, + "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00" + "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00", + "\x80\x00\x00\x00\x00\x00\x00\x00", + { + { 8, + "\x00\x00\x00\x00\x00\x00\x00\x00", + "\x17\x2C\x51\x92\xCB\x6E\x64\x5B" + } + } + }, + { + "Salsa20/12 256 bit, ecrypt verified, set 6, vector 0", + GCRY_CIPHER_SALSA20R12, 32, 8, + "\x00\x53\xA6\xF9\x4C\x9F\xF2\x45\x98\xEB\x3E\x91\xE4\x37\x8A\xDD" + "\x30\x83\xD6\x29\x7C\xCF\x22\x75\xC8\x1B\x6E\xC1\x14\x67\xBA\x0D", + "\x0D\x74\xDB\x42\xA9\x10\x77\xDE", + { + { 8, + "\x00\x00\x00\x00\x00\x00\x00\x00", + "\x52\xE2\x0C\xF8\x77\x5A\xE8\x82" + }, + { 64, + "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00" + "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00" + "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00" + "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00", + "\x52\xE2\x0C\xF8\x77\x5A\xE8\x82\xF2\x00\xC2\x99\x9F\xE4\xBA\x31" + "\xA7\xA1\x8F\x1D\x5C\x97\x16\x19\x1D\x12\x31\x75\xE1\x47\xBD\x4E" + "\x8C\xA6\xED\x16\x6C\xE0\xFC\x8E\x65\xA5\xCA\x60\x84\x20\xFC\x65" + "\x44\xC9\x70\x0A\x0F\x21\x38\xE8\xC1\xA2\x86\xFB\x8C\x1F\xBF\xA0" + } + } } #endif /*USE_SALSA20*/ }; @@ -1543,6 +1628,138 @@ check_stream_cipher_large_block (void) "\xEB\x31\x4E\xD4\x70\xB1\xAF\x6B\x9F\x8D\x69\xDD\x79\xA9\xD7\x50" } } + }, + { + "Salsa20/12 256 bit, ecrypt verified, set 6, vector 0", + GCRY_CIPHER_SALSA20R12, 32, 8, + "\x00\x53\xA6\xF9\x4C\x9F\xF2\x45\x98\xEB\x3E\x91\xE4\x37\x8A\xDD" + "\x30\x83\xD6\x29\x7C\xCF\x22\x75\xC8\x1B\x6E\xC1\x14\x67\xBA\x0D", + "\x0D\x74\xDB\x42\xA9\x10\x77\xDE", + { + { 0, 64, + "\x52\xE2\x0C\xF8\x77\x5A\xE8\x82\xF2\x00\xC2\x99\x9F\xE4\xBA\x31" + "\xA7\xA1\x8F\x1D\x5C\x97\x16\x19\x1D\x12\x31\x75\xE1\x47\xBD\x4E" + "\x8C\xA6\xED\x16\x6C\xE0\xFC\x8E\x65\xA5\xCA\x60\x84\x20\xFC\x65" + "\x44\xC9\x70\x0A\x0F\x21\x38\xE8\xC1\xA2\x86\xFB\x8C\x1F\xBF\xA0" + }, + { 65472, 64, + "\x8F\xBC\x9F\xE8\x69\x1B\xD4\xF0\x82\xB4\x7F\x54\x05\xED\xFB\xC1" + "\x6F\x4D\x5A\x12\xDD\xCB\x2D\x75\x4E\x8A\x99\x98\xD0\xB2\x19\x55" + "\x7D\xFE\x29\x84\xF4\xA1\xD2\xDD\xA7\x6B\x95\x96\x92\x8C\xCE\x05" + "\x56\xF5\x00\x66\xCD\x59\x9E\x44\xEF\x5C\x14\xB2\x26\x68\x3A\xEF" + }, + { 65536, 64, + "\xBC\xBD\x01\xDD\x28\x96\x1C\xC7\xAD\x30\x47\x38\x6C\xBC\xC6\x7C" + "\x10\x8D\x6A\xF1\x11\x67\xE4\x0D\x7A\xE1\xB2\xFC\x45\x18\xA8\x67" + "\xEF\xE4\x02\x65\x1D\x1D\x88\x51\xC4\xFD\x23\x30\xC5\x97\xB3\x6A" + "\x46\xD5\x68\x9E\x00\xFC\x96\xFE\xCF\x9C\xE3\xE2\x21\x1D\x44\xBE" + }, + { 131008, 64, + "\x91\x66\xF3\x1C\xD8\x5B\x5B\xB1\x8F\xC6\x14\xE5\x4E\x4A\xD6\x7F" + "\xB8\x65\x8E\x3B\xF9\xFB\x19\xB7\xA8\x2F\x0F\xE7\xDC\x90\x2D\xF5" + "\x63\xC6\xAC\x4F\x44\x67\x48\xC4\xBC\x3E\x14\x05\xE1\x24\x82\x0D" + "\xC4\x09\x41\x99\x8F\x44\xA8\x10\xE7\x22\x78\x7F\xCD\x47\x78\x4C" + } + } + }, + { + "Salsa20/12 256 bit, ecrypt verified, set 6, vector 1", + GCRY_CIPHER_SALSA20R12, 32, 8, + "\x05\x58\xAB\xFE\x51\xA4\xF7\x4A\x9D\xF0\x43\x96\xE9\x3C\x8F\xE2" + "\x35\x88\xDB\x2E\x81\xD4\x27\x7A\xCD\x20\x73\xC6\x19\x6C\xBF\x12", + "\x16\x7D\xE4\x4B\xB2\x19\x80\xE7", + { + { 0, 64, + "\xC0\x75\x60\xB3\xE7\x76\xB4\x71\xC5\xE2\x93\x14\x26\xCA\xF1\xED" + "\x3A\xE4\xB8\x67\x08\x76\x82\xCA\x9D\xFD\xC2\xBA\xE8\x93\x50\xBD" + "\x84\x82\x1C\xAE\xFF\x85\xAA\xC4\x9D\x74\x35\xA7\xD9\x88\x93\x52" + "\xF5\x27\x9E\x36\x12\x3F\x41\x72\x8A\x14\xEF\x26\x9F\xCB\x94\x4B" + }, + { 65472, 64, + "\xEE\xD1\xBB\x58\xF9\x0C\x89\xE0\x5C\xC6\x8B\x2D\xB6\x05\x58\x49" + "\xB3\xD2\xB1\x87\xB7\xF0\x2F\x9A\x24\xCE\x34\x2A\xF0\xFC\x47\xA3" + "\x74\xBD\x75\x90\xFB\xF4\xFD\x9E\xE5\x9B\x1A\x38\x1E\xBF\xD2\x29" + "\xAD\x2A\x29\x01\xB3\xFB\x61\x08\x12\x90\x0B\x92\x30\xE6\x22\xE9" + }, + { 65536, 64, + "\x70\xF0\x49\x3A\x1B\x62\x53\xCC\x5E\xD3\x45\x0A\x31\xCF\x37\x7D" + "\x83\x4B\xAD\x20\x72\x30\x29\x27\xCC\xD8\x30\x10\x4B\xD3\x05\xFF" + "\x59\xD2\x94\x17\xB2\x32\x88\x4E\xC9\x59\x19\x4D\x60\x47\xC3\xDD" + "\x66\x56\xC4\x7E\x32\x00\x64\xEB\x01\x44\xF7\x34\x1B\xC3\xD6\x97" + }, + { 131008, 64, + "\xD2\xCC\xF7\xC1\xAF\x2A\xB4\x66\xE6\x27\xDB\x44\x08\x40\x96\x9A" + "\xBD\xAB\x68\xD8\x86\xAE\x6A\x38\xA1\x3F\xEE\x17\x50\xCA\x97\xB5" + "\xD3\x31\x5B\x84\x08\x47\x28\x86\x2F\xBC\xC7\xD4\xA9\x7C\x75\xC8" + "\x65\x5F\xF9\xD6\xBB\xC2\x61\x88\x63\x6F\x3E\xDF\xE1\x5C\x7D\x30" + } + } + }, + { + "Salsa20/12 256 bit, ecrypt verified, set 6, vector 2", + GCRY_CIPHER_SALSA20R12, 32, 8, + "\x0A\x5D\xB0\x03\x56\xA9\xFC\x4F\xA2\xF5\x48\x9B\xEE\x41\x94\xE7" + "\x3A\x8D\xE0\x33\x86\xD9\x2C\x7F\xD2\x25\x78\xCB\x1E\x71\xC4\x17", + "\x1F\x86\xED\x54\xBB\x22\x89\xF0", + { + { 0, 64, + "\x51\x22\x52\x91\x01\x90\xD1\x54\xD1\x4D\x0B\x92\x32\xB8\x84\x31" + "\x8C\xCB\x43\x81\x9B\xD5\x42\x19\x32\xC0\x3A\x13\xF0\x7B\x40\x10" + "\x83\xD7\x89\x72\x5A\xA9\xDA\x0B\x41\xCB\x62\x24\x94\x5E\xDC\xB0" + "\xFB\x6F\xD7\xC2\x34\x22\x35\xC9\x70\xF6\x4E\x10\x1C\x25\x68\x64" + }, + { 65472, 64, + "\x97\x96\x74\x55\x84\x0A\x4A\xE5\xC1\xCA\xCE\x49\x15\x19\x13\x8A" + "\xA3\x5E\x5F\x02\x40\x7D\x4A\x1F\xE5\x08\x6D\x35\xF3\x55\x1E\xF4" + "\x77\xD9\x28\x9D\x17\x23\x79\x7C\x1A\x49\xEC\x26\x62\x9A\xFA\xDC" + "\x56\xA0\x38\xA3\x8C\x75\x88\x1B\x62\x17\xFD\x74\x67\x25\x59\x09" + }, + { 65536, 64, + "\x1B\xF8\x2E\x3D\x5C\x54\xDA\xAB\xCF\x84\x15\xF8\xA2\xA1\xA2\x2E" + "\x86\x88\x06\x33\x4F\xF3\x11\x36\x04\x74\x1C\x1D\xF2\xB9\x84\x0F" + "\x87\xDE\xEF\xB0\x07\x23\xA8\xA1\xB2\x4A\x4D\xA1\x7E\xCD\xAD\x00" + "\x01\xF9\x79\xDD\xAE\x2D\xF0\xC5\xE1\xE5\x32\xC4\x8F\x8E\x0D\x34" + }, + { 131008, 64, + "\x06\xD8\x4F\x6A\x71\x34\x84\x20\x32\x9F\xCD\x0C\x41\x75\x9A\xD1" + "\x8F\x99\x57\xA3\x8F\x22\x89\x3B\xA5\x58\xC5\x05\x11\x97\x28\x5C" + "\x6B\xE2\xFD\x6C\x96\xA5\xC6\x62\xAF\xD3\x11\x78\xE7\x0F\x96\x0A" + "\xAB\x3F\x47\x96\x23\xA4\x44\xB6\x81\x91\xE4\xC5\x28\x46\x93\x88" + } + } + }, + { + "Salsa20/12 256 bit, ecrypt verified, set 6, vector 3", + GCRY_CIPHER_SALSA20R12, 32, 8, + "\x0F\x62\xB5\x08\x5B\xAE\x01\x54\xA7\xFA\x4D\xA0\xF3\x46\x99\xEC" + "\x3F\x92\xE5\x38\x8B\xDE\x31\x84\xD7\x2A\x7D\xD0\x23\x76\xC9\x1C", + "\x28\x8F\xF6\x5D\xC4\x2B\x92\xF9", + { + { 0, 64, + "\x99\xDB\x33\xAD\x11\xCE\x0C\xCB\x3B\xFD\xBF\x8D\x0C\x18\x16\x04" + "\x52\xD0\x14\xCD\xE9\x89\xB4\xC4\x11\xA5\x59\xFF\x7C\x20\xA1\x69" + "\xE6\xDC\x99\x09\xD8\x16\xBE\xCE\xDC\x40\x63\xCE\x07\xCE\xA8\x28" + "\xF4\x4B\xF9\xB6\xC9\xA0\xA0\xB2\x00\xE1\xB5\x2A\xF4\x18\x59\xC5" + }, + { 65472, 64, + "\x2F\xF2\x02\x64\xEE\xAF\x47\xAB\x7D\x57\xC3\x62\x24\x53\x54\x51" + "\x73\x5A\xC8\x36\xD3\x2D\xD2\x8A\xE6\x36\x45\xCE\x95\x2F\x7F\xDB" + "\xE6\x68\x9C\x69\x59\x77\xB1\xC7\x6E\x60\xDD\x5B\x27\xAC\xA4\x76" + "\xD2\x62\x0F\xDC\x93\x13\xE8\x48\x9B\xA5\x6A\x70\xC9\xF4\xC3\xA8" + }, + { 65536, 64, + "\xEB\x30\xCD\xA7\x27\xC0\xF8\xB7\xE4\x5D\x5E\xF3\x0D\xB7\xCB\xE0" + "\x21\xF2\x29\x1E\x5F\x56\x93\x8D\x56\xF6\x87\xB7\x37\xC3\xB4\x27" + "\x54\x5C\x56\xA6\xD3\xA0\xBF\x2B\x2F\x47\xB4\x84\x93\xFA\xE4\x5E" + "\xD5\x0C\x2E\x9B\xBE\x49\xFD\x92\xD6\x7C\x76\x49\x05\x5F\x06\xFD" + }, + { 131008, 64, + "\x0E\xBF\x6C\xC3\xCB\xCB\xE7\x4E\x6E\xE8\x07\x47\x1B\x49\x2A\x67" + "\x39\xA5\x2F\x57\x11\x31\xA2\x50\xBC\xDF\xA0\x76\xA2\x65\x90\xD7" + "\xED\xE6\x75\x1C\x03\x26\xA0\x2C\xB1\x1C\x58\x77\x35\x52\x80\x4F" + "\xD8\x68\x67\x15\x35\x5C\x5A\x5C\xC5\x91\x96\x3A\x75\xE9\x94\xB4" + } + } } #endif /*USE_SALSA20*/ }; @@ -2170,6 +2387,7 @@ check_ciphers (void) #endif #if USE_SALSA20 GCRY_CIPHER_SALSA20, + GCRY_CIPHER_SALSA20R12, #endif 0 }; -- 1.7.10.4 From wk at gnupg.org Thu Jul 25 11:53:33 2013 From: wk at gnupg.org (Werner Koch) Date: Thu, 25 Jul 2013 11:53:33 +0200 Subject: [security fix] Libgcrypt 1.5.3 released Message-ID: <87a9lb7yoy.fsf@vigenere.g10code.de> Hello! I am pleased to announce the availability of Libgcrypt version 1.5.3. This is a *security fix* release for the stable branch. Libgcrypt is a general purpose library of cryptographic building blocks. It is originally based on code used by GnuPG. It does not provide any implementation of OpenPGP or other protocols. Thorough understanding of applied cryptography is required to use Libgcrypt. Noteworthy changes in version 1.5.3: * Mitigate the Yarom/Falkner flush+reload side-channel attack on RSA secret keys. See . [ Note that Libgcrypt is used by GnuPG 2.x and thus this release fixes the above problem. The fix for GnuPG < 2.0 can be found in the just released GnuPG 1.4.14. ] Source code is hosted at the GnuPG FTP server and its mirrors as listed at http://www.gnupg.org/download/mirrors.html . On the primary server the source file and its digital signatures is: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.5.3.tar.bz2 (1.5M) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.5.3.tar.bz2.sig This file is bzip2 compressed. A gzip compressed version is also available: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.5.3.tar.gz (1.8M) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.5.3.tar.gz.sig Alternativley you may upgrade version 1.5.2 using this patch file: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.5.2-1.5.3.diff.bz2 (4k) The SHA-1 checksums are: 2c6553cc17f2a1616d512d6870fe95edf6b0e26e libgcrypt-1.5.3.tar.bz2 184405c91d1ab4877caefb1a6458767e5f0b639e libgcrypt-1.5.3.tar.gz b711fe3ddf534bb6f11823542036eb4a32e0c914 libgcrypt-1.5.2-1.5.3.diff.bz2 For help on developing with Libgcrypt you should read the included manual and optional ask on the gcrypt-devel mailing list [1]. A listing with commercial support offers for Libgcrypt and related software is available at the GnuPG web site [2]. The driving force behind the development of Libgcrypt is my company g10 Code. Maintenance and improvement of Libgcrypt and related software takes up most of our resources. To allow us to continue our work on free software, we ask to either purchase a support contract, engage us for custom enhancements, or to donate money: http://g10code.com/gnupg-donation.html Many thanks to all who contributed to Libgcrypt development, be it bug fixes, code, documentation, testing or helping users. Happy hacking, Werner [1] See http://www.gnupg.org/documentation/mailing-lists.html . [2] See http://www.gnupg.org/service.html -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 204 bytes Desc: not available URL: From wk at gnupg.org Thu Jul 25 19:26:36 2013 From: wk at gnupg.org (Werner Koch) Date: Thu, 25 Jul 2013 19:26:36 +0200 Subject: [PATCH] Add support for Salsa20/12 - 12 round version of Salsa20 In-Reply-To: <1374418402-25336-1-git-send-email-dbaryshkov@gmail.com> (Dmitry Eremin-Solenikov's message of "Sun, 21 Jul 2013 18:53:22 +0400") References: <1374418402-25336-1-git-send-email-dbaryshkov@gmail.com> Message-ID: <8738r25z5f.fsf@vigenere.g10code.de> On Sun, 21 Jul 2013 16:53, dbaryshkov at gmail.com said: > Salsa20/12 is a reduced round version of Salsa20 that is amongst ciphers > selected by eSTREAM for Phase 3 of Profile 1 algorithm. Moreover it is > one of proposed ciphers for TLS (draft-josefsson-salsa20-tls-02). Why should anyone give up a good security margin for an algorithm which is already very fast. If there is a real world application for such a reduced version of Salsa20 it makes sense to have it. But until then, I doubt that it makes any sense. Simon: Why are you proposing that? Minor nitpicking: > +#define SALSA20r12_ROUNDS 12 All uppercase please. > + "SALSA20/12", /* name */ A slash in the name is not a good idea (think file name). Lower or uppercase 'r' would be better. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From simon at josefsson.org Fri Jul 26 21:12:58 2013 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 26 Jul 2013 21:12:58 +0200 Subject: [PATCH] Add support for Salsa20/12 - 12 round version of Salsa20 In-Reply-To: <8738r25z5f.fsf@vigenere.g10code.de> (Werner Koch's message of "Thu, 25 Jul 2013 19:26:36 +0200") References: <1374418402-25336-1-git-send-email-dbaryshkov@gmail.com> <8738r25z5f.fsf@vigenere.g10code.de> Message-ID: <87fvv1w2x1.fsf@latte.josefsson.org> Werner Koch writes: > On Sun, 21 Jul 2013 16:53, dbaryshkov at gmail.com said: > >> Salsa20/12 is a reduced round version of Salsa20 that is amongst ciphers >> selected by eSTREAM for Phase 3 of Profile 1 algorithm. Moreover it is >> one of proposed ciphers for TLS (draft-josefsson-salsa20-tls-02). > > Why should anyone give up a good security margin for an algorithm which > is already very fast. If there is a real world application for such a > reduced version of Salsa20 it makes sense to have it. But until then, I > doubt that it makes any sense. > > Simon: Why are you proposing that? eSTREAM picked 12-rounds Salsa, and not the 20-round version, so it could be argued that it will receive more scrutiny -- even though it seems quite unlikely that there would be any security problem with 20-round Salsa20 that wouldn't also affect 12-rounds. I would recommend against implementing 12-rounds without also implementing 20-rounds -- DJB specified 20-rounds and I would personally use 20-rounds. Whenever 12-rounds is available, 20-rounds should be available as well. I think it is unfortunate that eSTREAM managed to weaken it by lowering the round count to 12-rounds, but that's where it is. There doesn't seem to be a lot of documentation how the change from 20-rounds to 12-rounds Salsa20 occured. /Simon From rdohm321 at gmail.com Sat Jul 27 04:45:53 2013 From: rdohm321 at gmail.com (Randolph D.) Date: Sat, 27 Jul 2013 04:45:53 +0200 Subject: Fwd: Goldbug.sf.net - Secure Multi-Crypto-Messenger v0.1 released Message-ID: Does anyone know, if this tool is really secure? Fwd: >>> DOWNLOAD & PRESS RELEASE 2013-07-27 - English / Deutsch weiter unten _____ _ _ ____ / ____| | | | | _ \ | | __ ___ | | __| | |_) |_ _ __ _ | | |_ |/ _ \| |/ _` | _ <| | | |/ _` | | |__| | (_) | | (_| | |_) | |_| | (_| | GoldBug.sf.net \_____|\___/|_|\__,_|____/ \__,_|\__, | __/ | |___/ TITLE: GoldBug.sf.net: Secure Instant Messenger V0.1 has been released - with p2p Email and decentral IRC public chat DOWNLOAD: https://sourceforge.net/projects/goldbug/files/?source=navbar SHORTY: While today thousands of members of the Stop-Watching-Us initiative against surveillance programs like PRISM demonstrated in several cities all around the globe, the EFF in conjunction with the Chaos Computer Club announced a new secure Instant Messenger called: GoldBug.sf.net (http://goldbug.sf.net) Next to chat as well a serverless Email-System and public IRC-Chat has been introduced with Multi-Encryption: a kind of PGP secured with AES over SSL. The new protocol driving this is called "Echo" and has many potentials to be deployed as well for further secure and anonymous communication applications. Some net communities already call it the Neuland Messenger due to the Font Name of the Logo. DESCRIPTION: StopWatching.Us [3] is the initiative half a million web users have signed due to the mass-surveillance programs like PRISM in USA; TEMPORA in Great Britain, MICS in France and XKEYSCORE Software as well deployed e.g. in Germany. While the governments are powerless in regard to prevent foreign agencies to grab internet-line data and to protect their citizens' privacy, the end-users themself are forced to encrypt their communication and stand up for their Human Rights.Thousands of facebook [4] and twitter [5] members declared to demonstrate on the streets on (last) Saturday, July 27, in many decentral cities. As well at this date, the first release of the Secure Instant Messenger GoldBug (http://goldbug.sf.net) has been announced. It uses multi-encryption (a kind of PGP secured with AES over SSL) based on the new echo protocol. While Mega?s "Spy-proof Email" [6] and Pirate Bay Founder?s "Hemlis Mobile Chat" [7] still play around at crypto-parties to find the right development, the open-source project "GoldBug" has chosen the crypto-library "Lib-Spot-On v. 0.1" (based on libGcrypt). The project brought out not only a secure, beautiful and easy to use messenger, but also a new peer protocol behind it: The Echo Protocol. The so called "Echo" creates a peer-2-peer (p2p), respective friend-2-friend (f2f) network, which sends every (strong encrypted) data packet to everyone connected in that network to your node. When you can decrypt the packet, it is yours and readable, if not, you share it with all your connected neighbors. So far so simple. Thinking other Protocols like Jabber, IRC, Torrent etc. based on the Echo opens up a new perspective, as this new kind of Distant-Chat currently shown in the GoldBug Chat Reference Model introduces a detachment with IP addresses and Private/Public Encryption Keys. The Echo Modus can be half or full: half means, to create a dedicated line to your neighbor, and the Echo stops there: Messages are not shared in the half modus. This creates a Web-of-Trust (friend-to-friend)-network within a p2p network (and not vice versa), which is not detectable - as the user defines at each node how to utilize the Echo. This creates a new view on trust and enables a plausible deniability of having ever utilized a Web of Trust (WoT). An important point in times of 100%-surveillance and data retention tracking over several, but stable line-hops. While for example RetroShare [8] as anonymous, decentral network is a good practice model for a Web of Trust, in a Web of Trust with added echo the user can disconnect from the neighbour while keeping the trust and communication - based on the encryption-key (so called "REPLEO") e.g. shown in the GoldBug Messenger Application. Next to chat as well a serverless Email-System and public IRC-Chat has been inlcuded with the GoldBug-release based on the echo protocol and deployed by the Library Libspoton. How the communities of other apps and protocols will evaluate, discuss and test and maybe adopt the security features of the echo protocol, will be shown by some next hybrid applications - and who knows, maybe the Hemlis-Mobile application or the new secure email systems like BitMail [9] or StartMail [10] announced by IXQUICK will integrate the echo as well. WHY THE NAME: GoldBug was the title of a short story of Edgar Allan Poe about cryptograms in 1843. In the short story Mr. LeGrand, who was recently bitten by a gold-colored bug, starts an adventure with two other friends after deciphering a secret message. Poe took advantage of the popularity of cryptography and the success of the story centers on one such cryptogram. "The Gold-Bug" was an instant success and was the most popular and most widely read of Poe's works during his lifetime. It also helped to popularize cryptograms and secured writing. Even 150 Years later a still vaid approach due to the current events in this time. FEATURES: # Instant Messenger Function: Direct Chat, Group Chat, Public Chat. # the integrated Email Client enables encrypted communication without the usage of a central server. You can even email to offline-friends: other friends from you chace the message for you until your friends come online again. # IPV6 Support: As IPV6 integrates the IP-Adress of the senders into each Datapacket, you can drop this with the Gemini-Feature of a detached communication. # The so called Repleo-Feature based on the Echo-Protocols enables the detachment of logged data retention, that means Data Retention has a solution: a TTL+1 function in an elastic network environment. # Optional you can use furthermore the "GoldBug"-Feature, a kind of password, a hybride-multi-encryption, which integrates a kind of pgp with AES end to end encryption, which offers new standards in regard to Instant Messaging and the Agenda Setting of crypto parties. # Hybrid, optional P2P and F2F Modi. # Proxy Modus: Can run over Tor, 127.0.0.1. : 9150 The GoldBug logo uses the Neuland font: "Neuland is a German typeface that was designed in 1923 by Rudolf Koch. It is often used today when an ?exotic? or ?primitive? look is desired, such as the logos for the Jurassic Park films", says Wikipedia. That has to be regarded just as a coincidence, no one in the net community would ever have the view to call it the Neuland Messenger or subscribe it to a person, e.g. like Rudolf Koch. WEBSITE: http://goldbug.sourceforge.net https://sourceforge.net/projects/goldbug/?source=navbar DOWNLOAD: https://sourceforge.net/projects/goldbug/files/?source=navbar SOURCE: http://spot-on.svn.sourceforge.net/viewvc/spot-on/?view=tar (as well included in the GB windows installer for your convenience) DEVELOPER-SVN: svn checkout svn://svn.code.sf.net/p/spot-on/code/ spot-on-code PROTOCOL-SIMULATION: http://goldbug.sourceforge.net/img/bitmail.gif Add this gadget to your bog or website - it describes, how the echo protocol works. References: [01] http://goldbug.sourceforge.net [02] https://sourceforge.net/projects/goldbug/?source=navbar [03] https://optin.stopwatching.us/ [04] https://www.facebook.com/events/566858663364951/ [05] https://twitter.com/stopwatchingus [06] http://torrentfreak.com/dotcoms-mega-debuts-spy-proof-messaging-this-summer-email-follows-130711/ [07] http://torrentfreak.com/pirate-bay-founder-announces-encrypted-nsa-proof-communication-apps-130710/ [08] http://retroshare.sourceforge.net/ [09] http://bitmail.sourceforge.net/ [10] https://beta.startmail.com/ >>>>>>>>>>>>>>> GERMAN LANGUAGE / DEUTSCHE SPRACHE: TITEL: GoldBug.sf.net: Sicherer Messenger mit Multi-Crypto V0.1 ver?ffentlicht - Auch p2p Email und dezentraler IRC Chat DOWNLOAD: https://sourceforge.net/projects/goldbug/files/?source=navbar KURZ: W?hrend heute tausende von Mitgliedrn der Stop-Watching-Us Initiative gegen Massen-?berwachungsprogramme wie PRISM in vielen St?dten rund um den Globus demonstrieren, hat die EFF in Verbindung mit dem CCC mitgeteilt, dass es ein neues Sofortnachrichtenprogramm gibt mit dem Namen GoldBug.sf.net ( http://goldbug.sf.net) - zu Deutsch: Goldk?fer. Neben dem Chat wird damit auch ein Email-System ohne zentralen Server und ein ?ffentlicher IRC Chat vorgestellt mit Multi-Verschl?sselung durch eine Art von PGP abgesichert mit den Verschl?sselungsstandards AES ?ber SSL. Das neue Protokoll, das dieses umsetzt, wird "Echo" genannt und hat zahlreiche Potentiale auch f?r weitere sichere und anonym eKommunikationsanwendungen genutzt zu werden. Einige Netz-Gemeinschaften nennen das Programm inzwischen auch den Neuland-Messenger. BESCHREIBUNG: StopWatching.Us [3] ist die Initiative, bei der mehr als eine halbe Million Internetnutzer unterzeichnet haben und sich gehen Massen?berwachungsprogramme wie PRISM in den USA, TEMPORA in Gro?britannien, MICS in Frankeich sowie der XKEYSCORE SOftware, die ebenso auch in Deutschland angewandt wird. W?hrend die Regierungen kraftlos sind in bezug die jeweils au?l?ndischen Agenturen davon abzuhalten, die Daten der Internet-Leitungen abzugreifen und ihre B?rger entsprechend zu sch?tzen, sind die End-Nutzer auf sich selbst gestellt, ihre Kommunikation zu verschl?sseln und f?r ihre Menschen- und Grundrechte auf Privatheit aufzustehen.Tausende von Facebook [4] und Twitter [5] Mitglieder erkl?rten, am (letzten) Samstag, 27. Juli, in den Stra?en von vielen dezentralen St?dten demonstrieren zu wollen.Ebenso an diesem Datum wurde die erste Ver?ffentlichung des Sicheren Sofortnachrichten Programms / INstant Messengers Golbug (http://goldbug.sf.net) bekannt gegeben. Es nutzt eine Multi-Verschl?sselung (eine Art PGP mit zus?tzlichem AES und SSL Standard) basierend auf dem neuen Echo-Protokol. W?hrend f?r das "abh?rsichere Email" von Mega [6] oder dem mobilen "Hemlis Chat" [7] des TPB Gr?nders immer noch auf Verschl?sselungsparties nach dem richtigen Entwicklungsansatz gesucht wird, hat das quelloffene Project "GoldBug" die Verschl?psselungs-Bibliothek "Lib-Spot-On v. 0.1" (basierend auf libGcrypt) ausgew?hlt. Das Projet brachte nicht nur einen sicheren, sch?nen und einfach zu nutzenden Chat Messenger heraus, sondern auch ein neues Peer-Protokol dahinter: Das Echo-Protokol. Das sogenannte "Echo" erstellt ein peer-zu-peer (p2p), respektive ein freund-zu-freund (f2f) netzwerk, welches jedes (stark verschl?sselte) Datenpaket an jeden der vorhandenen Kontaktknoten senden. Wenn das Datenpacket entschl?sselt werden kann, ist es Deins, und es ist lesbar, wenn nicht, wird es weiterhin mit allen verbundenen Netzwerkknoten geteilt. Soweit so einfach. Andere Protokolle insbesondere der Kommuikation wie Jabber, IRC, Torrent etc neu zu denken basierend auf dem Echo er?ffnet ganz neue Perspektiven, als dass diese neue Art einer Distanz-Kommunikation derzeit gezeigt in dem Forschungs- und Entwicklungsmodell Gold Bug Chat eine neues Beziehungsgef?ge von IP Adressen und privaten-?ffentlichen Schl?sseln vorstellt. Der Echo-Modus kann halb oder voll sein: Halb bedeutet, eine direkte Verbindung mit dem Nachbarn herzustelen und das Echo stoppt dann auch dort: Nachrichten werden nicht weiter geteilt in dem Halb-Modus. Somit wird ein Vertrauensgeflecht, ein Web of Trust (WoT) inmitten eines Peer-zu-Peer-Netzwerkes erstellt (und gerade nicht umgekehrt), das nicht erkennbar ist, weil der Nutzer selbst definiert an jedem Knotenpunkt, we er das Echo einsetzen m?chte. Das erm?glicht eine neue Sichtweise auf Vertrauen im Interner und er?ffnet auch eine Plausible Abstreitbarkeit ein Vertrauensnetzwerk (WoT) jemals eingesetzt zu haben. Das kann ein bedeutender Punkt in Zeiten von 100-Prozent-?berwachung der Netzwerkkommunikation und der Vorratsdatenspeicherung selbst ?ber mehrer, aber stablile Netzwerk?berleitungen. W?hrend beispielsweise RetroShare [8] als anonymes und dezentrales Netzwerk ein gutes Anwenderbeispiel f?r ein Vertrauensnetzwerk (Web of Trust) ist, kann der Nutzer jedoch in einem Web of Trust mit hinzugef?gtem Echo sich vom Nachbarn abmelden, w?hrend die Vertrauens-Signatur und die Kommunikatiosnf?higkeit erhalten bleibt - basieren auf dem Verschl?sselungs-Code (so genanntes "Repleo") wie es beispielsweise in der Anwendung GoldBug Messenger genutz wird. Neben dem Chat is tauch ein dezentrales, severloses Email System und ein ?ffentlicher IRC CHat in dem GoldBug Release integriert - ebenso basierend auf dem Echo Protokol, das von der Bibliothel Lib-Spot-On umgesetzt wird. Wie nun die Netzgemeinden von anderen Applikationen und Protokollen die Sicherheitsmerkmale und das Echo protokoll evaluieren, diskutieren, testen und m?glicherweise auch ?bernehmen, wir durch ggf. entstehende Hybrid Applikationen gezeigt werden k?nnen. Und wer weiss, m?glicherweise werden die Hemlis-Mobilanwendung oder die neuen sicheren Emailsysteme wie BitMail [9] oder StartMail [10], angek?ndigt durch IXQUICK, das Echo ebenso integrieren. WARUM DER NAME: GoldBug wer der Title einer Kurzgeschichte von Edgar Allan Poe ?ber Cryptogramme im Jahr 1843. In der Geshichte startet Herr LeGrand, der neulich von einem gold-farbenen K?fer gebissen wurde, ein Abenteuer mit zwei weiteren Freunden - nachdem sie eine geheime Botschaft entschl?sseln konnten. Der Dichter Poe hat die Popularit?t von Verschl?sselung damals schon verhergesehen und der Erfolg der Kurzgeschichte basiert auf der Entschl?sselung eines solchen Kryptogramms. "Der GoldK?fer" war ein sofortiger Erfolg and das am meisten popul?re und von vielen Bev?lkerngsschichten gelesene Werk von Edgar Allan Poe w?hrend seiner gesamten Lebenszeit. Es halt ebenso geholfen, die Verwendung von Kryptogrammen und das Schreiben mit Verschl?sselungstechniken popul?r zu machen. Auch 150 Jahre sp?ter ein g?ltoger Anspruch in Anbetracht der derzeitigen Ereignisse in dieser Zeit. FEATURES: # Instant Messenger Function: Direct Chat, Group Chat, Public Chat. # the integrated Email Client enables encrypted communication without the usage of a central server. You can even email to offline-friends: other friends from you chace the message for you until your friends come online again. # IPV6 Support: As IPV6 integrates the IP-Adress of the senders into each Datapacket, you can drop this with the Gemini-Feature of a detached communication. # The so called Repleo-Feature based on the Echo-Protocols enables the detachment of logged data retention, that means Data Retention has a solution: a TTL+1 function in an elastic network environment. # Optional you can use furthermore the "GoldBug"-Feature, a kind of password, a hybride-multi-encryption, which integrates a kind of pgp with AES end to end encryption, which offers new standards in regard to Instant Messaging and the Agenda Setting of crypto parties. # Hybrid, optional P2P and F2F Modi. # Proxy Modus: Can run over Tor, 127.0.0.1. : 9150 The GoldBug logo uses the Neuland font: "Neuland is a German typeface that was designed in 1923 by Rudolf Koch. It is often used today when an ?exotic? or ?primitive? look is desired, such as the logos for the Jurassic Park films", says Wikipedia. That has to be regarded just as a coincidence, no one in the net community would ever have the view to call it the Neuland Messenger or subscribe it to a person, e.g. like Rudolf Koch. WEBSITE: http://goldbug.sourceforge.net https://sourceforge.net/projects/goldbug/?source=navbar DOWNLOAD: https://sourceforge.net/projects/goldbug/files/?source=navbar SOURCE: http://spot-on.svn.sourceforge.net/viewvc/spot-on/?view=tar (as well included in the GB windows installer for your convenience) DEVELOPER-SVN: svn checkout svn://svn.code.sf.net/p/spot-on/code/ spot-on-code PROTOCOL-SIMULATION: http://goldbug.sourceforge.net/img/bitmail.gif Add this gadget to your bog or website - it describes, how the echo protocol works. References: [01] http://goldbug.sourceforge.net [02] https://sourceforge.net/projects/goldbug/?source=navbar [03] https://optin.stopwatching.us/ [04] https://www.facebook.com/events/566858663364951/ [05] https://twitter.com/stopwatchingus [06] http://torrentfreak.com/dotcoms-mega-debuts-spy-proof-messaging-this-summer-email-follows-130711/ [07] http://torrentfreak.com/pirate-bay-founder-announces-encrypted-nsa-proof-communication-apps-130710/ [08] http://retroshare.sourceforge.net/ [09] http://bitmail.sourceforge.net/ [10] https://beta.startmail.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Mon Jul 29 15:25:36 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 29 Jul 2013 15:25:36 +0200 Subject: Deterministic DSA Message-ID: <878v0p1orz.fsf@vigenere.g10code.de> Hi, I just pushed the last patch to support RFC-6979 style Deterministic DSA to master. All prime field tests from the RFC (or well, the I-D) work as expected. Using it is pretty straighforward: const char *hashname = "sha256". int hashalgo; int digestlen; char digest[32]; hashalgo = gcry_md_map_name (hashname); if (!hashalgo) die ("hash with name '%s' is not supported\n", tests[tno].hashname); digestlen = gcry_md_get_algo_dlen (hashalgo); if (digestlen > sizeof digest) die ("internal error: digest does not fit into our buffer\n"); gcry_md_hash_buffer (hashalgo, digest, message, strlen (message)); err = gcry_sexp_build (&data, NULL, "(data " " (flags rfc6979)" " (hash %s %b))", hashname, digestlen, digest); if (err) die ("building data sexp failed: %s\n", gpg_strerror (err)); err = gcry_pk_sign (&sig, data, seckey); You may now also use (hash ALGO BUFFER) instead of (value MPI) for standard DSA. In that case Libgcrypt takes care of standard conforminf truncation Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Jul 29 21:34:49 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 29 Jul 2013 21:34:49 +0200 Subject: [PATCH] Add support for Salsa20/12 - 12 round version of Salsa20 In-Reply-To: <87fvv1w2x1.fsf@latte.josefsson.org> (Simon Josefsson's message of "Fri, 26 Jul 2013 21:12:58 +0200") References: <1374418402-25336-1-git-send-email-dbaryshkov@gmail.com> <8738r25z5f.fsf@vigenere.g10code.de> <87fvv1w2x1.fsf@latte.josefsson.org> Message-ID: <87bo5lxiqu.fsf@vigenere.g10code.de> On Fri, 26 Jul 2013 21:12, simon at josefsson.org said: > eSTREAM picked 12-rounds Salsa, and not the 20-round version, so it I see. > I would recommend against implementing 12-rounds without also > implementing 20-rounds -- DJB specified 20-rounds and I would personally Well, we implemented 20 rounds and not yet 12 rounds. In how far is eSTREAM relevant; why do we need to care about it? Is there any project already using Salsa20r12 or is there still time to ignore this variant? In other words, would you mind to change your I-D to ?Standard? 20 rounds Salsa? It is not that I am against adding this variant, but I try to keep the number of implemented algorithms low. We already had to add a couple of algorithms simply for political reasons. I would appreciate if we could avoid that (and thus make IanG happy). Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dbaryshkov at gmail.com Wed Jul 31 15:20:58 2013 From: dbaryshkov at gmail.com (Dmitry Eremin-Solenikov) Date: Wed, 31 Jul 2013 17:20:58 +0400 Subject: [PATCH] Correct checks for ecc secret key Message-ID: <1375276858-27865-1-git-send-email-dbaryshkov@gmail.com> * cipher/ecc.c (check_secret_key): replace wrong comparison of Q and sk->Q points with correct one. -- Currently check_secret_keys compares pointers to coordinates of Q (calculated) and sk->Q (provided) points. Instead it should convert them to affine representations and use mpi_cmp to compare coordinates. This has an implication that keys that were (erroneously) verified as valid could now become invalid. Signed-off-by: Dmitry Eremin-Solenikov --- cipher/ecc.c | 40 +++++++++++++++++++++++++++++++++++++--- 1 file changed, 37 insertions(+), 3 deletions(-) diff --git a/cipher/ecc.c b/cipher/ecc.c index 725dfbe..3bb7c9e 100644 --- a/cipher/ecc.c +++ b/cipher/ecc.c @@ -674,6 +674,7 @@ check_secret_key (ECC_secret_key * sk) int rc = 1; mpi_point_struct Q; gcry_mpi_t y_2, y2; + gcry_mpi_t x1, x2; mpi_ec_t ctx = NULL; point_init (&Q); @@ -683,6 +684,8 @@ check_secret_key (ECC_secret_key * sk) /* G in E(F_p) */ y_2 = gen_y_2 (sk->E.G.x, &sk->E); /* y^2=x^3+a*x+b */ y2 = mpi_alloc (0); + x1 = mpi_alloc (0); + x2 = mpi_alloc (0); mpi_mulm (y2, sk->E.G.y, sk->E.G.y, sk->E.p); /* y^2=y*y */ if (mpi_cmp (y_2, y2)) { @@ -716,17 +719,48 @@ check_secret_key (ECC_secret_key * sk) } /* pubkey = [d]G over E */ _gcry_mpi_ec_mul_point (&Q, sk->d, &sk->E.G, ctx); - if ((Q.x == sk->Q.x) && (Q.y == sk->Q.y) && (Q.z == sk->Q.z)) + + if (_gcry_mpi_ec_get_affine (x1, y_2, &Q, ctx)) { if (DBG_CIPHER) - log_debug - ("Bad check: There is NO correspondence between 'd' and 'Q'!\n"); + log_debug ("Bad check: Q can not be a Point at Infinity!\n"); goto leave; } + + /* Fast path for loaded secret keys - sk->Q is already in affine coordinates */ + if (!mpi_cmp_ui (sk->Q.z, 1)) + { + if (mpi_cmp (x1, sk->Q.x) || mpi_cmp (y_2, sk->Q.y)) + { + if (DBG_CIPHER) + log_debug + ("Bad check: There is NO correspondence between 'd' and 'Q'!\n"); + goto leave; + } + } + else + { + if (_gcry_mpi_ec_get_affine (x2, y2, &sk->Q, ctx)) + { + if (DBG_CIPHER) + log_debug ("Bad check: Q can not be a Point at Infinity!\n"); + goto leave; + } + + if (mpi_cmp (x1, x2) || mpi_cmp (y_2, y2)) + { + if (DBG_CIPHER) + log_debug + ("Bad check: There is NO correspondence between 'd' and 'Q'!\n"); + goto leave; + } + } rc = 0; /* Okay. */ leave: _gcry_mpi_ec_free (ctx); + mpi_free (x2); + mpi_free (x1); mpi_free (y2); mpi_free (y_2); point_free (&Q); -- 1.7.10.4 From wk at gnupg.org Wed Jul 31 17:58:06 2013 From: wk at gnupg.org (Werner Koch) Date: Wed, 31 Jul 2013 17:58:06 +0200 Subject: [PATCH] Correct checks for ecc secret key In-Reply-To: <1375276858-27865-1-git-send-email-dbaryshkov@gmail.com> (Dmitry Eremin-Solenikov's message of "Wed, 31 Jul 2013 17:20:58 +0400") References: <1375276858-27865-1-git-send-email-dbaryshkov@gmail.com> Message-ID: <877gg6sovl.fsf@vigenere.g10code.de> On Wed, 31 Jul 2013 15:20, dbaryshkov at gmail.com said: > * cipher/ecc.c (check_secret_key): replace wrong comparison of Q and > sk->Q points with correct one. Pushed. Thanks. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.