nettle-bugs

nettle-bugs@lists.lysator.liu.se

3 participants
2194 discussions

Request to support more KDFs
by Gabriel Ivașcu 18 May '17

18 May '17

Dear Nettle developers, I see Nettle currently supports only some variations of PBKDF2 so I was wondering whether there could be added support for more KDFs [0]. In my particular case it would be nice to have support for HKDF [1]. HKDF is not complicated and I'm sure most of us can work with their own implementation (like I did in my projects), but I believe it will be more beneficial for users to have it properly implemented in Nettle. Same goes for the other KDFs. [0] https://en.wikipedia.org/wiki/Category:Key_derivation_functions [1] https://tools.ietf.org/html/rfc5869 Thanks, Gabriel

2 1

Please use https in mail footer
by Tim Rühsen 17 May '17

17 May '17

Could you (the admin) change the footer to use https instead of http, please ? With Best Regards, Tim

1 0

static analyzer run + few fixes
by Nikos Mavrogiannopoulos 16 May '17

16 May '17

Hi Niels, The attached patches add a static analyzer run in the nettle CI and fix few minor issues found with it. There two issues I didn't fix because I am not sure whether it is a logical error or an initialization of the variables in question could solve it. I attach the html output of scan-view. Both involve the ecc_mod() function and the variable 'hi'. regards, Nikos

2 1

Up to 7x faster sha256 for ppc64le: Please review
by Gustavo Serra Scalet 09 Apr '17

09 Apr '17

Hi, I coded a high performance sha256 algorithm for ppc64le: https://git.lysator.liu.se/gut/nettle/commit/a8facb03a69787a93c91b426f32a0b… Tests were performed with different files and comparing it against the original C implementation by using the Ubuntu's 16.10 libnettle.so.6 by using the following code: https://gist.github.com/gut/9622d4535a9e3f9ea3b0ded2762d4b28 The results I got by using an ubuntu-16.10 iso as an input (around 700mb): $ time ./sha256-test ~/ubuntu-16.10-server-ppc64el.iso d14bdb413ea6cdc8d9354fcbc37a834b7de0c23f992deb0c6764d0fd5d65408e real 0m14.607s user 0m13.988s sys 0m0.616s $ export LD_LIBRARY_PATH=~/nettle # link with user and not system lib $ time ./sha256-test ~/ubuntu-16.10-server-ppc64el.iso d14bdb413ea6cdc8d9354fcbc37a834b7de0c23f992deb0c6764d0fd5d65408e real 0m2.242s user 0m2.052s sys 0m0.188s I also plan on doing the sha512 if I'm heading to the right direction. Regards, Gustavo Serra Scalet > -----Original Message----- > From: Nikos Mavrogiannopoulos [mailto:n.mavrogiannopoulos@gmail.com] > Sent: terça-feira, 28 de fevereiro de 2017 06:07 > To: Niels Möller <nisse(a)lysator.liu.se> > Cc: Gustavo Serra Scalet <gustavo.scalet(a)eldorado.org.br>; nettle- > bugs(a)lists.lysator.liu.se > Subject: Re: Is the gitlab being used or not? > > On Tue, Feb 28, 2017 at 7:48 AM, Niels Möller <nisse(a)lysator.liu.se> > wrote: > > Gustavo Serra Scalet <gustavo.scalet(a)eldorado.org.br> writes: > > > >> I noticed there is no merging/update activities on the gitlab > website: > >> https://git.lysator.liu.se/nettle/nettle/merge_requests?scope=all&sta > >> te=all > >> > >> I wonder if it's used. > > > > It's used mainly for the plain git hosting. I rarely use the more > > advance features, and almost never access the web interface. > > Would it be possible to disable then the merge request option in the > gitlab interface? There are already 5 patches there. > > Most likely you need to go to -> Edit project and disable the issue > tracker and the merge commits for everyone (at least that's the process > in the new gitlab). > > >> The reason for asking is that I'm willing to integrate a > >> ppc64le-specific implementation using SIMD registers for the SHA-2 > >> algorithm so I would create an Issue to discuss it and then > >> submitting the code as a Merge Request. But only if that's the way > >> for upstreaming code on nettle. If not, please advise if this list > >> can be used. > > > > Discussion should take place on this list. You can mail patches here, > > or create a merge request on gitlab. But in the latter case, please > > send a note here too, otherwise it might be overlooked. > > I attach a patch to document that process. I use CONTRIBUTION.md show it > shows prominently on the gitlab interfaces. > > regards, > Nikos

2 4

Is the gitlab being used or not?
by Gustavo Serra Scalet 09 Apr '17

09 Apr '17

Hi, I noticed there is no merging/update activities on the gitlab website: https://git.lysator.liu.se/nettle/nettle/merge_requests?scope=all&state=all I wonder if it's used. The reason for asking is that I'm willing to integrate a ppc64le-specific implementation using SIMD registers for the SHA-2 algorithm so I would create an Issue to discuss it and then submitting the code as a Merge Request. But only if that's the way for upstreaming code on nettle. If not, please advise if this list can be used. Sorry for using the "nettle-bugs" mailing list, which is not a discussion mailing list. Cheers, Gustavo Serra Scalet

3 3

[PATCH 0/2] Implement RSA-PSS signature scheme
by Daiki Ueno 14 Mar '17

14 Mar '17

From: Daiki Ueno <dueno(a)redhat.com> Hello, This series of patches implements the RSA-PSS signature scheme, as specified in RFC 3447. To keep the interface minimal but to allow TLS 1.3 implementations on top of this, only SHA256/384/512 variants are provided. The prototypes of the top-level functions are as follows: int rsa_pss_shaXXX_sign_digest_tr(const struct rsa_public_key *pub, const struct rsa_private_key *key, void *random_ctx, nettle_random_func *random, size_t salt_length, const uint8_t *salt, const uint8_t *digest, mpz_t s); int rsa_pss_shaXXX_verify_digest(const struct rsa_public_key *key, size_t salt_length, const uint8_t *digest, const mpz_t signature); For MGF, "mask generation function 1" backed by the same hash algorithm is always used, as indicated in [1]. I thought it might make sense to provide more flexible variants, such as rsa_pss_{sign_tr,verify} analogous to rsa_pkcs1_*, but realized that parsing ASN.1 encoded parameters would require extra complexity. Suggestions appreciated. Daiki Ueno (2): Implement PSS encoding functions Add PSS variants for RSA sign/verify functions Makefile.in | 7 +- mgf1-sha256.c | 47 +++++++ mgf1-sha384.c | 47 +++++++ mgf1-sha512.c | 47 +++++++ mgf1.c | 72 +++++++++++ mgf1.h | 70 ++++++++++ nettle-types.h | 3 + nettle.texinfo | 30 +++++ pss-sha256.c | 64 ++++++++++ pss-sha512.c | 90 +++++++++++++ pss.c | 195 ++++++++++++++++++++++++++++ pss.h | 105 +++++++++++++++ rsa-pss-sha256-sign-tr.c | 64 ++++++++++ rsa-pss-sha256-verify.c | 60 +++++++++ rsa-pss-sha512-sign-tr.c | 87 +++++++++++++ rsa-pss-sha512-verify.c | 79 ++++++++++++ rsa-verify.c | 14 ++ rsa.h | 55 ++++++++ testsuite/.test-rules.make | 9 ++ testsuite/Makefile.in | 5 +- testsuite/mgf1-test.c | 23 ++++ testsuite/pss-test.c | 35 +++++ testsuite/rsa-pss-sign-tr-test.c | 268 +++++++++++++++++++++++++++++++++++++++ 23 files changed, 1473 insertions(+), 3 deletions(-) create mode 100644 mgf1-sha256.c create mode 100644 mgf1-sha384.c create mode 100644 mgf1-sha512.c create mode 100644 mgf1.c create mode 100644 mgf1.h create mode 100644 pss-sha256.c create mode 100644 pss-sha512.c create mode 100644 pss.c create mode 100644 pss.h create mode 100644 rsa-pss-sha256-sign-tr.c create mode 100644 rsa-pss-sha256-verify.c create mode 100644 rsa-pss-sha512-sign-tr.c create mode 100644 rsa-pss-sha512-verify.c create mode 100644 testsuite/mgf1-test.c create mode 100644 testsuite/pss-test.c create mode 100644 testsuite/rsa-pss-sign-tr-test.c Footnotes: [1] https://tlswg.github.io/tls13-spec/#signature-algorithms -- 2.9.3

3 5

[PATCH] Make nettle compile with pre-UAL arm assembler.
by Marcus Hoffmann 09 Mar '17

09 Mar '17

See: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0204j/Cjagjj… The pre-UAL instruction is also accepted by modern assemblers. Signed-off-by: Marcus Hoffmann <m.hoffmann(a)cartelsol.com> --- arm/ecc-521-modp.asm | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arm/ecc-521-modp.asm b/arm/ecc-521-modp.asm index c311a89..3fba239 100644 --- a/arm/ecc-521-modp.asm +++ b/arm/ecc-521-modp.asm @@ -91,7 +91,7 @@ PROLOGUE(nettle_ecc_521_modp) adcs F0, F0, F3, lsr #9 C Copy low 9 bits to H, then shift right including carry and H, F0, T0 - rrx F0, F0 + mov F0, F0, rrx lsr F0, F0, #8 C Add in F1 = rp[33], with weight 2^1056 = 2^14 adds F0, F0, F1, lsl #14 -- 2.9.3

2 1

Re: How to pass an IV to the AES 256 encryption/decryption
by Gabriel Ivașcu 04 Mar '17

04 Mar '17

On Sat, Mar 4, 2017 at 2:31 PM, Aapo Talvensaari <aapo.talvensaari(a)gmail.com> wrote: > On Sat, Mar 4, 2017 at 12:18 PM, Gabriel Ivașcu <ivascu.gabriel59(a)gmail.com> > wrote: >> >> Hi, >> >> Can I get some instructions on how to use an IV (initialization >> vector) when doing an AES 256 encryption/decryption? >> >> The AES documentation [0] provides no information on how to pass the >> IV to the AES functions, > > > Please check here: > https://github.com/bungle/lua-resty-nettle/blob/master/lib/resty/nettle/aes… > Thanks for your response, Aapo! I learned eventually that you have to explicitly use the CBC mode [0] if you want to pass an IV, since the AES functions [1] use the ECB mode as default. Also, I found this useful example [2] of how use the CBC mode with Twofish, which I adapted to use AES instead. [0] https://www.lysator.liu.se/~nisse/nettle/nettle.html#CBC [1] https://www.lysator.liu.se/~nisse/nettle/nettle.html#AES [2] https://stackoverflow.com/questions/33003118/nettle-twofish-cbc Regards, Gabriel

1 0

How to pass an IV to the AES 256 encryption/decryption
by Gabriel Ivașcu 04 Mar '17

04 Mar '17

Hi, Can I get some instructions on how to use an IV (initialization vector) when doing an AES 256 encryption/decryption? The AES documentation [0] provides no information on how to pass the IV to the AES functions. [0] https://www.lysator.liu.se/~nisse/nettle/nettle.html#AES Thank you, Gabriel

1 0

lock-free random generator
by Nikos Mavrogiannopoulos 28 Feb '17

28 Feb '17

Hi, One of the items that have been on my todo-list after discussing with application writers of multi-threaded applications (mainly servers), is addressing the issue of synchronization for the random generator. Currently gnutls provides a "central" random generator based on yarrow (for keys) and salsa20 (for nonces) primitives, and it is thread safe by utilizing mutexes over it. An application that has more than 100-200 threads is most likely to spend more time in synchronization rather than the random generator itself. A solution to that would be to provide a thread-local random generator which will work lock-free, at the cost of additional memory per-thread -around 600-700 bytes for the current generator-. I have an experimental patch set, implementing this idea at: https://gitlab.com/gnutls/gnutls/merge_requests/259 On the patch above, the additional cost per thread will only be for threads actually utilizing gnutls, and in particular the random generator, as the required memory will be allocated after the first call to gnutls_rnd() by the thread. Are there any objections on such an enhancement to gnutls, or suggestions on how such a lock-free random generator could be improved (in terms of memory utilization for example)? regards, Nikos

2 5

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

nettle-bugs