nettle-bugs

nettle-bugs@lists.lysator.liu.se

1 participants
2193 discussions

Minor nits/comments on sha256.c
by Joachim Strömbergson 03 Jan '14

03 Jan '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aloha! I took a look at the code in sha256.c and have a couple of small comments. (1) The K table is not zero extended. This just makes the table look weird: K[64] = { 0x428a2f98UL, 0x71374491UL, 0xb5c0fbcfUL, 0xe9b5dba5UL, 0x3956c25bUL, 0x59f111f1UL, 0x923f82a4UL, 0xab1c5ed5UL, 0xd807aa98UL, 0x12835b01UL, 0x243185beUL, 0x550c7dc3UL, 0x72be5d74UL, 0x80deb1feUL, 0x9bdc06a7UL, 0xc19bf174UL, 0xe49b69c1UL, 0xefbe4786UL, 0xfc19dc6UL, 0x240ca1ccUL, 0x2de92c6fUL, 0x4a7484aaUL, 0x5cb0a9dcUL, 0x76f988daUL, 0x983e5152UL, 0xa831c66dUL, 0xb00327c8UL, 0xbf597fc7UL, 0xc6e00bf3UL, 0xd5a79147UL, 0x6ca6351UL, 0x14292967UL, 0x27b70a85UL, 0x2e1b2138UL, 0x4d2c6dfcUL, 0x53380d13UL, 0x650a7354UL, 0x766a0abbUL, 0x81c2c92eUL, 0x92722c85UL, 0xa2bfe8a1UL, 0xa81a664bUL, 0xc24b8b70UL, 0xc76c51a3UL, 0xd192e819UL, 0xd6990624UL, 0xf40e3585UL, 0x106aa070UL, 0x19a4c116UL, 0x1e376c08UL, 0x2748774cUL, 0x34b0bcb5UL, 0x391c0cb3UL, 0x4ed8aa4aUL, 0x5b9cca4fUL, 0x682e6ff3UL, 0x748f82eeUL, 0x78a5636fUL, 0x84c87814UL, 0x8cc70208UL, 0x90befffaUL, 0xa4506cebUL, 0xbef9a3f7UL, 0xc67178f2UL, }; I would suggest zero extending the table to get the same textual width of all elements. (2) Pretty cool that you actually generate the constants from the FIPS 180 specification! Good verification. (3) The SHA-224 H0-table refers to the _SHA256_DIGEST_LENGTH. This imho should be a separate define _SHA224_DIGEST_LENGTH. Yes, it is the same length in practice but it looks weird esp since the generated digest for SHA-224 is in fact not the same even though the internal diget state vector H is the same length as SHA-256. (4) I'll think I'm going to ask on the SHA-3 maillist (hosted by NIST) if John Kelsey & Co can provide an explanation for the H0-constants used in SHA-224 and SHA-1 in the same way as for SHA-256, SHA-512 etc. It really is a bit peculiar that they don't. - -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. ======================================================================== Joachim Strömbergson Secworks AB joachim(a)secworks.se ======================================================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlLG28UACgkQZoPr8HT30QFslACgobq4tXi1dzRao/QIu4/tEUPG ev0An2Mul1IqawWz1mRAQq26i8UNeizX =NxwW -----END PGP SIGNATURE-----

2 4

Regarding the nettle release plan page
by Joachim Strömbergson 03 Jan '14

03 Jan '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aloha! Really good with the release plan page for Nettle: http://www.lysator.liu.se/~nisse/nettle/plan.html A few (bikeshed) comments etc. (1) I would suggest not using colors as distinguisher for what is done (green), what is critical for the release (red) and what is nice to have (grayish). I would instead suggest having subsections with explicit headers stating this instead (done, important, nice to have). Colors are harder to parse and esp red-green is bad when dealing with a lot of male individuals. (2) How about putting up an estimated release schedule at the top of the page. For example such as: - - 2014-01-xx: Feature freeze for 2.8 (branch date) - - 2014-02-xx: Testing and bug fix completed. - - 2014-03-xx: 2.8 RC1 - - 2014-04-xx: 2.8 Released (label date) (I have no idea what release schedule you in fact have in mind - if it is 4 days, 4 weeks of 4 months to do the release.) (3) I'll try and work on the chacha support files the next weeks. (4) I'm prepared to do the darwin testing on OSX 10.9.x - -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. ======================================================================== Joachim Strömbergson Secworks AB joachim(a)secworks.se ======================================================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlLG110ACgkQZoPr8HT30QGbXACgpU2K0VxrKfQkZUoUVXfdLEed CVgAn0UF6IpAEf8+waGIocrp50NH/El/ =rwsu -----END PGP SIGNATURE-----

2 1

Using side-channel silent GMP functions
by nisse＠lysator.liu.se 03 Jan '14

03 Jan '14

For the next release of GMP, there will be some new public functions for side-channel silent computations, as part of the low-level "mpn" interface. I think it would make sense to rewrite the RSA and DSA private key operations to use side-channel silent functions. This might require further interface changes; I haven't really looked into it yet, so I don't know to which degree backwards compatibility can be kept. I also don't yet know if it's practical to make use of the new functions optional, or if it will make the latest GMP a strict requirement (unless Nettle's public key support is completely disabled). What do you think? Relatedly, I've updated the release plan on http://www.lysator.liu.se/~nisse/nettle/plan.html. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

2 1

acoustic cryptanalysis
by Nikos Mavrogiannopoulos 19 Dec '13

19 Dec '13

Hello, It seems that some guys managed to "listen" gnupg private keys. While some parts of the attack are gnupg specific, similar attacks could apply in nettle as well (and I guess every implementation that does RSA decryption). This could affect TLS sessions where the server is decrypting client provided ciphertext. I see on their mitigation section that "ciphertext normalization", i.e., c=c%n, avoids their key recovery attack, so given that there is no harm to have this step anyway, it would be nice to have it in nettle as well (patch attached). http://www.cs.tau.ac.il/~tromer/acoustic/ regards, Nikos

2 2

arm-neon/v6 auto-detection
by Nikos Mavrogiannopoulos 18 Dec '13

18 Dec '13

Hello, As it is now the ARM-neon and v6 optimizations are enabled when nettle is compiled on the exact system it is supposed to run. This is very unlikely to happen in some scenarios, as applications intended to run on an arm mobile (eg [0]) cannot know in advance the target. That is a petty because nettle is pretty unique in having support for assembly in ARMv6 or neon. A solution to that issue would be to have a nettle library constructor that runs the equivalent of cpuid in ARM, and stores it to a global variable. Then each assembly module (e.g., aes-arm) will jump to the correct implementation detected at runtime. This requires no global initialization functions or anything like that. In the systems where library constructors are not available (i.e., static linking), the cost would be running the oldest arm assembly version (unless the constructor is called explicitly). This is similar to what openssl is doing already (with the exception that they use a global initialization function instead of a constructor). To me that seems quite a simple way to improve the current situation. regards, Nikos [0]. https://github.com/cernekee/ics-openconnect

4 10

Building nettle in OSX
by Joachim Strömbergson 18 Dec '13

18 Dec '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aloha! (Sorry for this stupid question.) I'm trying to get nettle to build in OSX but are having some problems. If i simply do the bootstrap-configure-make I get problems in the assembly phase: <quote> /Applications/Xcode.app/Contents/Developer/usr/bin/make all-here gcc -I. -DHAVE_CONFIG_H -g -O2 -ggdb3 -Wall -W -Wmissing-prototypes - -Wmissing-declarations -Wstrict-prototypes -Wpointer-arith - -Wbad-function-cast -Wnested-externs -fPIC -MT gcm-hash8.o -MD -MP -MF gcm-hash8.o.d -fPIC -c gcm-hash8.s gcm-hash8.s:220:18: error: unexpected token in '.section' directive .section .rodata ^ gcm-hash8.s:224:1: error: unknown directive .hword 0x0000,0xc201,0x8403,0x4602,0x0807,0xca06,0x8c04,0x4e05 ^ gcm-hash8.s:225:1: error: unknown directive .hword 0x100e,0xd20f,0x940d,0x560c,0x1809,0xda08,0x9c0a,0x5e0b ^ .... </quote> Googling I found some other people having problems: https://gist.github.com/morgant/1753095 Turning of assembly (--disable-assembler to configure) I get through the compilation, assembly, but linking fails (similarly the link above): <quote> Undefined symbols for architecture x86_64: "__nettle_aes_decrypt", referenced from: _nettle_aes_decrypt in aes-decrypt.po _nettle_aes128_decrypt in aes-decrypt.po _nettle_aes192_decrypt in aes-decrypt.po _nettle_aes256_decrypt in aes-decrypt.po "__nettle_aes_encrypt", referenced from: _nettle_aes_encrypt in aes-encrypt.po _nettle_aes128_encrypt in aes-encrypt.po _nettle_aes192_encrypt in aes-encrypt.po _nettle_aes256_encrypt in aes-encrypt.po (maybe you meant: __nettle_aes_encrypt_table) ... </quote> This is on OSX 10.9 with gcc being a wrapper around clang: Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) Target: x86_64-apple-darwin13.0.0 Thread model: posix and as being: Apple Inc version cctools-846.2.4, GNU assembler version 1.38 and ld being: @(#)PROGRAM:ld PROJECT:ld64-224.1 configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 armv6m armv7m armv7em LTO support using: LLVM version 3.3svn, from Apple Clang 5.0 (build 500.2.79) Anybody succeeding and building nettle on OSX and if so how. Being able to use the optimized assembler versions would also be good. - -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. ======================================================================== Joachim Strömbergson Secworks AB joachim(a)secworks.se ======================================================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlKq4ZcACgkQZoPr8HT30QEy2QCffi/BpWVuYyNKV5oqFLvDlLg0 CeAAoK0VLGcek5vHcUXkMG9QPHgypl2z =a0RI -----END PGP SIGNATURE-----

3 16

Mentioning of .bootstrap in INSTALL?
by Joachim Strömbergson 17 Dec '13

17 Dec '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aloha! Cloned nettle and noticed that INSTALL states: "Briefly, the shell commands `./configure; make; make install' should configure, build, and install this package." But at least in the repo there is only a config.ac and you need to run the .bootstrap shell script in order to invoke autoconf and autoheaders in order to get the configure script. Shouldn't INSTALL mention this? - -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. ======================================================================== Joachim Strömbergson Secworks AB joachim(a)secworks.se ======================================================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlKq2LgACgkQZoPr8HT30QEIbACfWjUuo8IAbigziPGwnw4Pbmx5 P8cAni2UtPVOqH52XlBlZmmsGnRfNz7L =ioBH -----END PGP SIGNATURE-----

2 4

TMP_ALLOC and size_t change
by Nikos Mavrogiannopoulos 17 Dec '13

17 Dec '13

Hello, In master (unsigned int) was replaced with (size_t), that allows for even larger sizes to be input to encryption and decryption functions. However, the usage of TMP_ALLOC to make a copy of the input data (e.g., in ctr.c) contradicts that goal. In general I think the usage of alloca() is dangerous as it not always known whether the stack is limited, e.g, when nettle is called in a co-routine or in application with non-growing stack. I think there can be an easy modification of TMP_ALLOC to use malloc for larger than 128 (or any other fixed number), and alloca otherwise. Would you be interested in such a patch? (it would require the introduction of a TMP_FREE as well) regards, Nikos

3 15

[PATCH] source files for chacha
by Joachim Strömbergson 13 Dec '13

13 Dec '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aloha! Here is the patch for the chacha implementation. I will create and send patches for the benchmark, meta, testsuite code when I get nettle to properly build. The code in this patch and my own test program builds and runs as available at: https://github.com/secworks/nettle/tree/master/chacha - -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. ======================================================================== Joachim Strömbergson Secworks AB joachim(a)secworks.se ======================================================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlKq85wACgkQZoPr8HT30QG8JgCfc/scXdxeXKJQSMWsWe7LNDHV 8qwAoN43hGYj1VkXadW65INvvm9OnSyY =AAyY -----END PGP SIGNATURE-----

1 0

ChaCha stream cipher for Nettle available
by Joachim Strömbergson 13 Dec '13

13 Dec '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aloha! I've taken a shot at implementing the ChaCha stream cipher for Nettle. Nettle is a modified version of Salsa20 done by DJB in order to improve both performance (esp on CPUs with support for data parallelism) and somewhat improved performance. ChaCha has been suggested as replacement for RC4 both by Adam Langley from Google and separately by Nikos and Me. http://cr.yp.to/chacha.html The code in this implementation is heavily based on the Salsa20 implementation in Nettle. The major changes beside name changes are the quarterround schedules, the different state init and the quarterround. This implementation also supports different number of rounds. There is a pretty simple test program that verifies the functionality for 128 and 256 keys as well as 8, 12 and 20 rounds using the testt vectors in the chacha test vectors draft: http://tools.ietf.org/html/draft-strombergson-chacha-test-vectors-00 The code for the chacha implementation is available at: https://github.com/secworks/nettle The following files comprises the implementation: chacha-core-internal.c chacha-crypt.c chacha-init.c chacha.h And the test program testsuite/chacha-test.c (The other files are clones from Nettle to be able to build.) ChaCha _should_ be a bit faster than Salsa20 and should esp be easier to optimize in asm for modern CPUs. I have however not done any benchmarks nor asm implementation (yet). Since I'm new as a contributor I don't know how you Niels want to have patches. Please let me know if this looks good and something you want to integrate and if so how. - -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. ======================================================================== Joachim Strömbergson Secworks AB joachim(a)secworks.se ======================================================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlKoxesACgkQZoPr8HT30QE6vACfTIV44gkDKJcsoxR9BjnElBfE zGQAnjbRimEsTp8arbDPtsT/RLrkgw5K =cz3W -----END PGP SIGNATURE-----

4 14

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