nettle-bugs

nettle-bugs@lists.lysator.liu.se

2196 discussions

Using alloca on windows
by nisse＠lysator.liu.se 03 Jul '12

03 Jul '12

When I try cross-compiling using ./configure '--host=i586-mingw32msvc' I get warnings on alloca usage, e.g., /home/nisse/hack/nettle/cbc.c: In function `nettle_cbc_decrypt': /home/nisse/hack/nettle/cbc.c:101: warning: implicit declaration of function `alloca' /home/nisse/hack/nettle/cbc.c:101: warning: incompatible implicit declaration of built-in function `alloca' Which header should I include to get a proper declaration? In config.h, I have some boilerplate code which includes … [View More]

2 2

Interface for new rsa features
by nisse＠lysator.liu.se 20 Jun '12

20 Jun '12

In recent months, some new RSA functions have been added, from suggestions and work of Nikos. I'd like to hear comments on the interface before release. Timing resistant decryption function, using RSA blinding: int rsa_decrypt_tr(const struct rsa_public_key *pub, const struct rsa_private_key *key, void *random_ctx, nettle_random_func *random, unsigned *length, uint8_t *message, const mpz_t gibberish); New signing functions taking a "… [View More]DigestInfo" as input: int rsa_pkcs1_sign(const struct rsa_private_key *key, unsigned length, const uint8_t *digest_info, mpz_t s); int rsa_pkcs1_verify(const struct rsa_public_key *key, unsigned length, const uint8_t *digest_info, const mpz_t signature); Timing-resistant version of the signing function: int rsa_pkcs1_sign_tr(const struct rsa_public_key *pub, const struct rsa_private_key *key, void *random_ctx, nettle_random_func random, unsigned length, const uint8_t *digest_info, mpz_t s); The _tr fucntions use these internal functions for RSA blinding: void _rsa_blind (const struct rsa_public_key *pub, void *random_ctx, nettle_random_func random, mpz_t c, mpz_t ri); void _rsa_unblind (const struct rsa_public_key *pub, mpz_t c, const mpz_t ri); Do you think this looks good? I see that there's some inconsistency of using "nettle_random_func random" vs "nettle_random_func *random", the latter variant is the preferred form. It would be nice with timing resistant versions of the other signing functions, byt I hesitate since we would end up with such a large number of functions. Some redesign (for some later version) may be appropriate. It's possible to do deterministic RSA blinding, using something like HMAC(encoding of private key, message) to generate the random number. And in similar way, one can do deterministic DSA signatures. That's also for later, but you may want to take that possibility into account when commenting on the interface. In somewhat related reorganization, the interface of the internal function pkcs1_signature_prefix has changed and is not compatible with the old version. Questions: 1. Is anyone depending on that function? 2. Does a change of this function require a new solib number? (Depends on the answer to previous question). 3. Should I rename it to _pkcs1_signature_prefix, in order to (i) make it more clear it's an internal function, and (ii) make applications depending on the old behaviour break in a more predictable fashion? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. [View Less]

2 2

Re: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc
by Dagobert Michelsen 23 May '12

23 May '12

Hi, Am 08.05.2012 um 23:17 schrieb Paul Eggert: > On 05/08/2012 01:05 PM, Niels Möller wrote: >> I think it should work fine to just get the gnutls release and apply >> Paul's patch to the file gnutls-3.0.9/gl/stdint.in.h before running the >> configure script. > > Yes, that's the idea. Thanks. Sorry for the delay, I got distracted. I just tested the latest stdint.in.h from gnulib master and gnutls 3.0.19 passes this stage now. However, I didn't change anything on … [View More]

2 1

Configure problem on OS-X
by William Morris 21 May '12

21 May '12

Hi. I obtained the latest nettle using git. Running 'configure' on OS-X (10.7.4) fails. config.status: error: cannot find input file: config.h.in Any ideas? Output from 'configure' given below. -- William Morris iMac:nettle $ ./configure checking build system type... x86_64-apple-darwin11.4.0 checking host system type... x86_64-apple-darwin11.4.0 checking for -R flag... none Searching for libraries checking /usr/local/lib/lib... not found checking /usr/local/lib... added checking /sw/… [View More]local/lib... not found checking /sw/lib... not found checking /usr/gnu/lib... not found checking /opt/gnu/lib... not found checking /sw/gnu/lib... not found checking /usr/freeware/lib... not found checking /usr/pkg/lib... not found checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking whether make sets $(MAKE)... yes checking for ranlib... ranlib checking for nm... nm checking for objdump... no checking for a BSD-compatible install... /usr/bin/install -c checking for a thread-safe mkdir -p... ./install-sh -c -d checking whether ln -s works... yes configure: Compiler uses 64-bit ABI. To change, set CC. configure: WARNING: Don't know where to install 64-bit libraries on this system. configure: Libraries to be installed in ${exec_prefix}/lib. configure: Looking for assembler files in x86_64/. checking CCPIC... -fPIC checking if globals are prefixed by underscore... yes checking if we should use a .note.GNU-stack section... no checking for ELF-style .type,%function pseudo-ops... no checking for ELF-style .type,#function pseudo-ops... no checking if .align assembly directive is logarithmic... yes checking for m4... /usr/bin/m4 checking for an ANSI C-conforming const... yes checking for inline... inline checking how to run the C preprocessor... gcc -E checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for uid_t in sys/types.h... yes checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for size_t... yes checking whether time.h and sys/time.h may both be included... yes checking for long... yes checking size of long... 8 checking for uint64_t... yes checking alignment of uint64_t... 8 checking openssl/blowfish.h usability... yes checking openssl/blowfish.h presence... yes checking for openssl/blowfish.h... yes checking openssl/des.h usability... yes checking openssl/des.h presence... yes checking for openssl/des.h... yes checking openssl/cast.h usability... yes checking openssl/cast.h presence... yes checking for openssl/cast.h... yes checking openssl/aes.h usability... yes checking openssl/aes.h presence... yes checking for openssl/aes.h... yes checking for working alloca.h... yes checking for alloca... yes checking malloc.h usability... no checking malloc.h presence... no checking for malloc.h... no checking for strerror... yes checking whether byte ordering is bigendian... no checking for memxor... no checking for __attribute__... yes checking for stdint types... stdint.h (shortcircuit) make use of stdint.h in nettle-stdint.h (assuming C99 compatible system) checking for fcntl file locking... yes checking for __gmpz_getlimbn in -lgmp... no configure: WARNING: GNU MP not found, or not 3.1 or up, see http://gmplib.org/. Support for public key algorithms will be unavailable. checking for __gmpz_powm_sec... no checking for BF_ecb_encrypt in -lcrypto... yes checking for library containing clock_gettime... no configure: creating ./config.status config.status: creating config.make config.status: creating config.m4 config.status: creating Makefile config.status: creating tools/Makefile config.status: creating testsuite/Makefile config.status: creating examples/Makefile config.status: creating nettle.pc config.status: creating hogweed.pc config.status: error: cannot find input file: config.h.in iMac:nettle $ [View Less]

2 1

Re: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc
by nisse＠lysator.liu.se 08 May '12

08 May '12

Paul Eggert <eggert(a)cs.ucla.edu> writes: > Thanks. This seems to be a win regardless of whether it > fixes the nettle problems, Dago, can you test if it solves the SunOS-5.9 problem for you? I.e., apply Paul's patch to gnutls/gnulib, then *unapply* the nettle workaround I comitted yesterday, and see if you still get compilation errors related to nettle-stdint.h. I'm not sure how picky the compiler is about multiple but equivalent typedefs of the same name. Regards, /Niels --… [View More]

2 2

Re: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc
by nisse＠lysator.liu.se 08 May '12

08 May '12

Paul Eggert <eggert(a)cs.ucla.edu> writes: > Such usage violates the C standard: even if one compiler > is not picky about it, your're likely to run into another that > does. So a better solution is needed. I've committed a workaround to nettle-types.h. It now does /* Pretend these types always exists. Nettle doesn't use them. */ #define _STDINT_HAVE_INT_FAST32_T 1 #include "nettle-stdint.h" which overrides the result of the configure checks used in the generated … [View More]

1 0

Re: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc
by nisse＠lysator.liu.se 07 May '12

07 May '12

Paul Eggert <eggert(a)cs.ucla.edu> writes: > Hmm, well, the latter point is dubious. SunOS 5.10 standard headers do not > mention int_fast*_t, except in stdint.h where C requires their definition. I'd consider that definition to be authoritative... > Presumably this is for the same reason that Gnulib avoids these types. > Arguably these types are not part of the SunOS 5.10 ABI, since nothing > in the SunOS library binary interface use them. C is still the system … [View More]programming language, and int_fast*_t are part of the language. But maybe we're splitting hairs now. > The main reason is to keep gnulib simple and maintainable. > I'd rather not have to hand-maintain details about an > operating system that hasn't shipped since 2009. I thought the point of gnulib was to do those annoying things to keep the maintanance in one place. But I guess I'll have to leave to the judgment of the gnulib maintainers which systems are too old and obsolete to care about. > How does the nettle stuff work? Does it #define int_fast8_t etc > in config.h? It is defined in a generated file nettle-stdint.h. And the names of the types are all typedefs, no #defines. With AX_CREATE_STDINT_H, it's a file generated independently of config.h. The file starts with a section with a bunch of #defines set up by configure, and then the rest of the file uses various tests on these to decide what file to include and which types to define. Where the common case is to just include the system's <stdint.h>. The file is then installed with the other nettle header files. > If so, there's a simple workaround in gnulib: > don't futz with int_fast8_t if it's already #defined. If one could get that to work, it might solve the problem for the case that the types are defined but not used. But if it implies that size of those types will depend on #include order, it seems very brittle to me. I think it would be better to let the gnulib application say explicitly whether or not it needs those types, and not define them at all in the common case that they aren't needed. I.e., #ifdef GL_WANT_INTX_FAST_T # define int_fast8_t gl_int_fast8_t #endif Not sure where one would define GL_WANT_INTX_FAST_T, if desired, though. Should be specified in some way in configure.ac, but it can't be put in config.h if the stdint.h types are needed for installed header files. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. [View Less]

1 0

Re: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc
by nisse＠lysator.liu.se 06 May '12

06 May '12

Paul Eggert <eggert(a)cs.ucla.edu> writes: > Intuitively, it's because the int_fast* types are so fragile: they > depend so much on choice of compiler and compiler option. Short version: I think gnulib should either make an effort to define int_fast*_t in the common way on each system (always doing the same as gcc would be very close to the Right Thing), or by default generate a stdint.h without these types and define the int_fast*_t types only when explicitly asked to. Longer … [View More]version (sorry I fail to be more concise): I think I misread "public headers" in your previous mail, I thought you meant system header files, rather than public header files provided by portable non-system libraries. Sorry for the confusion. I agree one can expect these types to be a fragile and compiler dependent whenever they're left undefined by system headers and ABI spec, which will be the usual assumption for portable code. But in the particular case of SunOS, the types are defined by system headers in release 5.10 (and presumably nailed down by the ABI spec), but missing in release 5.9. Do you see any good reason for gnulib to not define the types in the same way as on 5.10, if building on 5.9? To me, that really looks like the Right Thing to do, and it also looks like the kind of job gnulib is supposed to do. Defining them in a way which differs from SunOS-5.10 definitely seems broken. In the case of gnutls and nettle, one gets compilation errors when another packed defines the same types, and does it using a configure hack which *is* compatible with SunOS-5.10. Of course, that fix doesn't magically make int_fast*_t universally non-fragile, but it definitely improves compatibility for the system in question. As for nettle, I think it's best to not define these types, which aren't used. On Solaris, it happens that AX_CREATE_STDINT_H defines them more correctly (in my view) than gnulib, but it may well cause problems on other system, so it seems more robust to not try to define them at all. But please also consider the hypothetical situation that nettle *did* use those types, even if only internally. Then I couldn't simply omit the definitions. To not cause problems for gnulib users I'd be forced to either change my definitions to prefer compatibility with gnulib over compatibility with SunOS-5.10, which seems really backwards, or introduce additional complexity in nettle-stdint.h to omit the definitions when my public headers need uint32_t. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. [View Less]

1 0

Re: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc
by nisse＠lysator.liu.se 06 May '12

06 May '12

Bruno Haible <bruno(a)clisp.org> writes: > It doesn't exist so far. But it is feasible. - On the other hand, it > looks like nettle-stdint.h can already be easily trimmed in this way, > by undefining _STDINT_NEED_INT_LEAST_T and _STDINT_NEED_INT_FAST_T ? I think that makes sense. I just need someone (Dagobert Michelsen?) who can try it out. Nettle uses the AX_CREATE_STDINT_H macro to generate that file. If it's easy, I'd prefer not to touch that and just add some extra #define … [View More]

1 0

Re: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc
by Nikos Mavrogiannopoulos 06 May '12

06 May '12

On 05/06/2012 12:34 PM, Bruno Haible wrote: > Niels Möller wrote: >> One possibility might be to not define the types at all, unless the >> gnulib application explicitly asks for them. Lots of applications want >> uint32_t, and I imagine a lot fewer have any need for int_fast*_t. > Yes. For this reason, libunistring installs a trimmed-down version of > gnulib's stdint.h, that defines only the int{8,16,32}_t types and not > all the rest (int64_t, int_least*_t, … [View More]

1 0

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