Re: PATCH: Build proper Mac OS X dynamic libraries (dylibs)
Ryan Schmidt writes: > I expected $(LIBS) to be empty, but I added it for consistency with > the mingw32 and cygwin cases. But it's not in the solaris or default > cases so I don't know if that was correct. I see. The default (mainly linux and bsd) and solaris cases have more solid testing. I think it's the mingw32 and cygwin cases which get it wrong (if -l flags when building a dll have any effect at all there; I don't know). I've now applied the patch, deleted those occurences of $(LIBS), and committed the result. Thanks, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: _nettle_write_be32
Nikos Mavrogiannopoulos writes: > Would it be possible to export _nettle_write_be32? This function is simple enough that it can be documented and made public, if people find it useful. > It is a useful function and can be used on the accelerated versions of > SHA in architectures that support it (i.e. VIA cpus). BTW, how does that acceleration work? Would it be possible/practical to write a function matching the current _nettle_sha1_compress. > btw. the MD_* macros were also proved to be very useful in that case. These macros are really intended for internal use only. I'd prefer to not export any interfaces like that. If functionality like this should be exported at all, I'd be more comfortable with a function interface for doing these things. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: _nettle_write_be32
Nikos Mavrogiannopoulos writes: > Aren't they already exported in macros.h? It seems you're right, in that macros.h is actually installed in $includedir/nettle (unlike, e.g., nettle-internal.h). I must have forgotten that when I put the MD_* definitions in that file... In any case, they're undocumented, and I won't promise any backwards compatibility in future versions. Maybe the internal-use things in macros.h ought to be moved to some uninstalled *-internal.h file. The *READ_* and *WRITE_* macros should stay in macros.h, but everything else there is a bit questionable. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: make issues
Anna Smith writes: > the link provided is broken :( can you repost? Works for me. Maybe you accidentally copied the "," at the end? That was not intended as a part of the url. It should be just http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Building libnettle on MS-Windows
Eli Zaretskii writes: > About a week ago, I built libnettle 2.4 on MS-Windows using the MinGW > tools. While doing that, I found a few problems; this message reports > them. Thanks for testing. As Martin wrote, there has been some progress on windows support since the release. It would be great if you could test the cvs version (sorry it's a little cumbersome; you need to check out the lsh tree and follow the instructions on http://www.lysator.liu.se/~nisse/nettle/). > Problem #1: Compiler warnings while compiling cbc.c: > > cbc.c: In function `nettle_cbc_decrypt': > cbc.c:101: warning: implicit declaration of function `alloca' > cbc.c:101: warning: nested extern declaration of `alloca' Not fixed, as far as I know. I don't see this warning when cross compiling, so I guess this reflects a real difference in native builds. > Problem #2: "make install" incorrectly copies the DLL files into > lib/*.dll.a. *.dll.a are the Windows import libraries for using > during the link stage; the *.dll dynamic libraries themselves should > be copied into the $(bindir) directory. Should be fixed, thanks to Martin. > Problem #3: Tests crash because they don't find libhogweed-2-1.dll. This is > because Makefile uses "ln -sf" to create .lib/*.dll. Not fixed. Using an LN_S make variable makes sense to me, but there should also be a corresponding configure check (hopefully there's some standard autoconf test?). Patch appreciated. > Problem #4: Tests in `examples' crash, cannot find libhogweed-2-1. > >Solution: add ../.lib to PATH, like testsuite/Makefile.in does. Seems right. Checked in now. > Problem #5: testsuite/pkcs1-conv fails due to CRLF vs LF issue in compared > files (MinGW programs produce text files where each line ends in CRLF, > while the test expects the Unix-style LF-only end-of-line format). > >Solution: add --strip-trailing-cr switch to diff. Fixed, I think (and also #6). Files are massaged with tr as needed, since that's more portable than relying on GNU diff. > Problem #7: examples/setup-env fails because it tries to read from > rsa-decrypt, which doesn't exist. It should instead read from > rsa-decrypt.exe. > > Solution: fix setup-env to check which program file is actually > present and read from that. Fixed, by passing $EXEEXT in the environment and using it in setup-env and also in other test scripts. > Problem #8: examples/rsa-encrypt-test fails because rsa-encrypt.c and > rsa-decrypt.c read/write binary data from stdin to stdout, but do > not set these streams to binary mode. > > To solve this, I added code to the test programs to use binary > mode. Let me know if you want me to submit patches for that. These files now do #ifdef WIN32 setmode(0, O_BINARY); setmode(1, O_BINARY); #endif Do you think this is a correct solution? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Building libnettle on MS-Windows
Eli Zaretskii writes: > Doesn't building from CVS require additional tools, like Autoconf and > Automake? Autoconf is needed. So if you don't have autoconf on the windows box, what you'd need to do is check it out to a unix/gnu/linux-system, run the .bootstrap scripts (as per the instructions), and do a ./configure && make && make dist in the nettle directory. And then copy the resulting .tar.gz to the windows machine. So it's not very convenient. When the lsh xenofarm is up and running, you can also cheat and get a recent lsh snapshot from http://www.lysator.liu.se/xenofarm/lsh/builds/latest. At the moment, the most recent snapshot there is from October, but if things goes well a current one should be prepared within an hour or so. I'm not sure when I'll get around to making a new release. > AC_PROG_LN_S > > is probably all you need. [...] > Yes, except that I would use _setmode, as that will also work for > Windows compilers other than MinGW. Noted. I'll see what I can do. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Building libnettle on MS-Windows
Eli Zaretskii writes: >I found that having this in configure.ac: > > AC_PROG_LN_S > > is probably all you need. I have added this now. > Yes, except that I would use _setmode, as that will also work for > Windows compilers other than MinGW. And this. I also found out that dlls apperantly weren't linked into the .lib directory, so I tried to fix that as well. This directory is added to LD_LIBRARY_PATH (for ELF systems) and PATH (for windows), when running the testsuite. Unfortunately, I couldn't figure out how to get wine to add the .lib directory to the initial PATH. So for now, as a workaround, I create symlinks also in the testsuite and examples subdirectories in the build tree, when cross compiling for windows. With that change, ./configure '--host=i586-mingw32msvc' '--enable-shared' make make check works for me. I just put up a prerelease at http://www.lysator.liu.se/~nisse/archive/nettle-2.5-pre.tar.gz (and .sig), any testing (in particular on windows) is appreciated. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Building libnettle on MS-Windows
Simon Josefsson writes: > With MinGW-64 I got the following error when building: For clarity: Is this MinGW-64 *natively* on a windows machine, or a cross compiler? > make[1]: Entering directory `/home/jas/src/nettle-2.5-pre/testsuite' > i686-w64-mingw32-g++ -g -O2 -L.. cxx-test.o testutils.o -lnettle -o > cxx-test.exe > /home/jas/src/mingw-w64-32/build/root/lib/gcc/i686-w64-mingw32/4.5.1/../../../../i686-w64-mingw32/bin/ld: > cannot find -lgcc_s > make[1]: *** [cxx-test.exe] Fel 1 > > It may be that my MinGW-64 g++ installation is not working properly. Seems likely; I can't see any reason why the compilation command line should give that error. > FAIL: ./teardown-env > make[1]: *** [check] Fel 1 > > The call to find in teardown-env turns out empty. Ooops. I should replace that backtick expression with an -exec argument to find. > This seems to be the case when I build with --enable-shared as well -- > then there is only one hit (./.lib/libnettle-4-3.dll), but it is not > under testsuite/. Should there be more *.dll files? For a native build: That's how it should be. The .lib directory is added to PATH, which should be sufficient for running the testprograms. The additional symlinks in the testsuite and example directories should be there only when cross compiling (detected by $EMULATOR matching wine*). Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Building libnettle on MS-Windows
Simon Josefsson writes: > I have the binfmt-support package installed, so an emulator is not > strictly required -- i.e., running ./foo.exe will work directly and > using 'wine ./foo.exe' is not necessary. > Will $EMULATOR be empty in > this case? It will most likely have been set automatically to wine64. Check the substituted variable in config.make. Do you think some additional configure tests are needed? (Alternatively, one could do something similar to automake's "make check TESTS_ENVIRONMENT=wine", but that's not as general since some of the test programs are shell scripts, not windows executables). But I think I have found out why the links weren't created. I forgot to set the executable bit on testsuite/setup-env. And since this is still cvs, that's a bit painful to get fixed. *sigh* Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Building libnettle on MS-Windows
Eli Zaretskii writes: >> Unfortunately, I couldn't figure out how to get wine to add the .lib >> directory to the initial PATH. > > Is that a wine-specific problem, or a general Windows problem? That's wine specific. Wine copies most environment variables from the unix environment it is started from into the environment of the executed windows program. With some exceptions for "special" environment variables, including PATH. After a quick look at the source code, it looks one should be able to set WINEPATH when starting wine, and have that copied to the windows path (possibly without any automagic translation of the filenames). But I couldn't get that to work. Anyway, it's a wine-specific problem, and I have a workaround. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Migration from CVS to GIT
I'm finally looking into conversion of the lsh repository from CVS to GIT, and this naturally also includes nettle. A public test repository can be found at lysator's gitorious installation, at http://git.lysator.liu.se/lsh/test-2. The conversion was done by the pcvs2git.pike program (see git://pike-git.lysator.liu.se/pcvs2git.git), and I got some help from Henrik Grubbström to write a config file to handle the few peculiarities in the lsh repository. The intention is that the new git repository should include all branches and tags from the old cvs repository, and record major merge events, like the 2006-05-16 merge from the experimental branch to the trunk. Please test, and if all goes well I'll rename this repository to "lsh" (or recreate, if I can't figure out how to do repository renames with gitorious). If this first steps works out ok, step two is to do a some cleanups (switching to utf-8 for the files, deleting old $Id$ tags, etc). And then step three is to extract the nettle subdirectory as an independent project and repository, using git subtree of git filter-branch or so (I'm not sure what's the best tool for that job). Other sub-projects, e.g., the argp implementation, can be split out later, if desired. For the few "common files" (e.g., misc/run-tests), they'll simply have to be duplicated in several repositories. If I still want to bundle nettle with the lsh distribution, I'll handle that by setting up some symlink in my working tree. git submodule is probably not a solution, and git subtree is most likely overkill. The old CVS repository can be considered read-only now. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Migration from CVS to GIT
Martin Storsjö writes: > I'd hope for a round of filter-branch to rewrite author names in git > to the original author of patches. I was thinking that it's good enough to convert the information recorded by cvs. But it's certainly possible to add specified author names for certain commits, as a part of the conversion process. The config/Pike-real-authors file (from the git://pike-git.lysator.liu.se/pcvs2git.git repository) is an example of what that input file should look like. Since I haven't used it I'm not sure how it works, but I could try to find out. But it's going to be some manual work, going through the ChangeLog files looking for contributed changes, and then looking at the cvs log to identify affected revisions and writing the input file for --contributors. > If you don't feel up to doing this yourself, I can try to give it a go. If you want to give it a try, I'll explain what's needed. 1. Get pike 7.8 release 550 or later, http://pike.ida.liu.se/pub/pike/beta/7.8.550/Pike-v7.8.550.tar.gz Annoyingly enough, it doesn't support the most recent version of nettle, resulting in compilation errors on the DES glue. I had to #if out the DES and DES3 ciphers from the Nettle module. Alternatively, there should be some configure argument to force Pike to build with the bundled version of nettle, rather than the installed version. 2. Get git://pike-git.lysator.liu.se/pcvs2git.git. This includes Henrik's configuration file in config/lsh.pcvs2git. 3. Get the CVS repository. I'm putting a copy at http://www.lysator.liu.se/~nisse/misc/lsh-cvsroot.tar.gz 4. Create an authors.txt file, containing nisse=Niels Möller uid444=Niels Möller _cvs_pont=Pontus Freyhult 5. To do the conversion, I used the command line pike ../pcvs2git/pcvs2git.pike -c ../pcvs2git/config/lsh.pcvs2git \ -A authors.txt -k -l -C lsh.git -d lsh-cvsroot/lsh It spawns a git fast-import process which populates the new repository. The result should be almost identical to the current "test-2" repository (Henrik has committed some tweaks for the generated .gitattributes files). To use a contributors file, add --contributors contributors.txt early on the above command line (the -d option and argument has to come after other options). Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Migration from CVS to GIT
Now I've went through the history, back from the previous millennium, startig from the authors and contributors files that Martin was kind enough to prepare. It's taken a few days. The early ChangeLog entries were a bit messy. The new repository is now git://git.lysator.liu.se/lsh/test-3.git And I also found out some things which I had forgotten. E.g., * The very first version of the lsh-export-key program was written by Jean-Pierre Stierlin. * Dan Egnor wrote the base64 code in Nettle, with much effort spent on finding the right interface design. * Pieces of Balázs Scheidler's now obsolete lsh_proxy program still survives, since current gateway_channel.c evolved from his proxy_channel.c. The recorded authors are listed below. These are all people I have been able to find who have contributed a larger or smaller change to lsh or nettle (not counting bug reports or sugestions for changes). Change sets which mix a contributed patch with other changes also don't get the contributor listed as author. So we have 37 authors over the years: Adam Langley Andres Mejia Balázs Scheidler Dagobert Michelsen Dan Egnor Daniel Kahn Gillmor David Hoyt Gordon Matzigkeit Grant Robinson Henrik Grubbström J.H.M. Dassen James Ralston Jean-Pierre Stierlin Joseph Galbraith Kalle Olavi Niemitalo Karl Berry Keresztfalvi Gabor Agoston Luiz Eduardo Gava Magnus Holmgren Martin Storsjö Meilof Veeningen Niels Möller Nikos Mavrogiannopoulos Pavel Roskin Per Cederqvist Pontus Freyhult Pontus Sköld Rafael Sevilla Rafal Maszkowski Ruud de Rooij Ryan Schmidt Sebastian Reitenbach Simon Josefsson Stefan Pfetzing Thayne Harbaugh Vincent Torri Volker Zell (Some statistics on first and latest contribution for each author, lines contributed, contributed lines still surviving in the tree, etc, would be interesting). Testing and general browsing of the history is appreciated. In a few days, I think I'll consider the conversion final. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Migration from CVS to GIT
Martin Storsjö writes: > The author mapping looks good to me at least, looking forward to the > final repo Now "final". Repo url git://git.lysator.liu.se/lsh/lsh.git. I renamed the old gitorious "project" to get the various test repositories out of the way. After the conversion, I have pushed some tags to all branches to mark the conversion. On master only, I have eliminatd $Id tags in files, and converted all textfiles to utf-8 (encoding marks in texinfo and html not yet updated, though). > (including separated nettle)! Not there yet. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Migration from CVS to GIT
Martin Storsjö writes: > The author mapping looks good to me at least, looking forward to the > final repo (including separated nettle)! Thanks for your work on this! I now have a first nettle test repo at git://git.lysator.liu.se/lsh-test/nettle-test.git It was created by first cloning the lsh repository, all branches. Then git filter-branch --subdirectory-filter nettle --prune-empty -- --all followed by git update-ref -d on all refs which the previous command warned about being unchanged. Including branches other than master is probably overkill. One file (nettle/tools/nettle-lfib-stream.c) seems to have originated on the lsh-1.4.2 branch, but I think it was copied manually to the main trunk. However, this conversion loses quite a lot of history, including all nettle-1.15 releases. To actually build old versions, one would need to use the lsh repo (due to the shared files linked by lsh's ./.bootstrap), but it would be nice to still have the history in the nettle repo. I think the following approach would make some sense, using git filter-branch --tree-filter or possibly --index-filter: 1. Delete everything except nettle, src/nettle and src/symmetric. 2. If nettle exists, move its contents up one level and delete nettle. 3. Otherwise, if src/nettle exists (and is non-empty), move its contents up two levels and delete the original directory. 4. Otherwise, if src/symmetric exists (and is non-empty), move its contents up two levels and delete the original directory. 5. Otherwise, the tree should be empty. It's from the first few weeks of lsh development, not relevant to nettle. Help from any git guru on the list is appreciated. In particular if the more efficient --index-filter method is to be used, it's not obvious to me how to examine the index and do the right tests and deletions. One could also try to extract all src/symmetric ChangeLog entries from lsh's ChangeLog and copy to nettle's (prior to spring 2001 or so) . But I think that can be done after the git migration; it's not much use to modify earlier revisions of the ChangeLog. Regards, /nisse -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: make issues
Senvey Lee writes: > Another success! Thanks. > > But got an ensuing error: > md5-compress.asm:100:suffix or operands invalid for `push' Sorry for the late reply. > Could someone help one this? Thanks. The md5-compress.asm file exists only for the 32-bit x86 target. I'm assuming you're building for x86_64? Then either configure and config.guess stil doesn't recognize your platform correctly, or the md5.comress.asm link is a left-over from an earlier run of configure. In the latter case, run make distclean to clean up (with gnu conventions, this is the make target to use to undo everything done by configure), and rerun configure. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Migration from CVS to GIT
Simon Josefsson writes: > configure: error: cannot find install-sh, install.sh, or shtool in . "."/. > jas@latte:~/src/nettle-test master$ > > However perhaps that is one of the unresolved issues. This is one of the files that was setup using symlinks in the lsh repo. I'll add this and other files to the nettle repo, *after* the conversion of the history is satisfactory. > However, I'm not sure it is that important to make the git repo usable > for building older nettle releases I mostly agree here; you won't be able to build from the nettle repo out of the box (just like you currently can't build HEAD out of the box). But I still think it's desirable to have older history, before directory renames, available for git log. Another approach I've been considering is to do a conversion which purges unrelated files (most of src except src/nettle and src/symmetric, most of misc, all contents in doc, argp, sftp, spki, most top-level files). And then use version controlled operations for the remaining cleanup and renames. The aim would then be to make it possible to check out old versions (with their different directory layout) and build them. But at the moment, I'm leaning towards moving directories in the conversion, since I think that will be less confusing with git log and diff. E.g., I'd expect git diff master nettle_1.7_release_20030311 -- configure.ac to show a diff of nettle's configure.ac in different revisions, not a diff between nettle's current configure.ac and a historic configure.ac from lsh. /nisse -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Migration from CVS to GIT
ni...@lysator.liu.se (Niels Möller) writes: > However, this conversion loses quite a lot of history, including all > nettle-1.15 releases. To actually build old versions, one would need to > use the lsh repo (due to the shared files linked by lsh's ./.bootstrap), > but it would be nice to still have the history in the nettle repo. Now I have a new test repo. Not created using git filter-branch on the lsh git repository, but converted from the same old cvs files, using pcvs2git and a new configuration file written primarily by Henrik Grubbström. The conversion moves files from nettle, src/nettle and src/symmetric (whichever is found first) to the top level. Also tries to keep the shared files, also putting them at top-level in the new repo (getopt*, config.guess, misc/run-tests, and a few more). Some symlinking still needs to be added to the .bootstrap script before one can build. See git://git.lysator.liu.se/lsh-test/nettle-test-2.git /nisse -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Migration from CVS to GIT
ni...@lysator.liu.se (Niels Möller) writes: > Now I have a new test repo. Not created using git filter-branch on the > lsh git repository, but converted from the same old cvs files, using > pcvs2git and a new configuration file written primarily by Henrik > Grubbström. Yet another try, and unless I discover any problems with this soon, it's going to be the final one. git://git.lysator.liu.se/lsh-test/nettle-test-3.git Difference from the previous one is that I've hacked the pcvs2git.pike program to keep track of the original path to each RCS file (as it moves directories up one or two levels), and use that in the generated Rev: comments. E.g, for git log -- twofish.c (a file at the top-level in the new git repo), git log includes the following commits (among others): commit f9ec0110676f16e263688b208c3a2e8735723e7d Author: Niels Möller Date: 2010-07-07 21:32:03 +0200 * aes.h (aes_encrypt, aes_decrypt): Declare ctx argument as const. Also updated implementation. * blowfish.h (blowfish_encrypt, blowfish_decrypt): Likewise. * cast128.h (cast128_encrypt, cast128_decrypt): Likewise. * serpent.h (serpent_encrypt, serpent_decrypt): Likewise. * twofish.h (twofish_encrypt, twofish_decrypt): Likewise. Rev: nettle/ChangeLog:1.91 Rev: nettle/aes-decrypt.c:1.2 Rev: nettle/aes-encrypt.c:1.2 Rev: nettle/aes.h:1.2 Rev: nettle/blowfish.c:1.3 Rev: nettle/blowfish.h:1.3 Rev: nettle/cast128.c:1.2 Rev: nettle/cast128.h:1.2 Rev: nettle/serpent.c:1.2 Rev: nettle/serpent.h:1.2 Rev: nettle/twofish.c:1.2 Rev: nettle/twofish.h:1.2 commit dd06afa4b49913037dabe6cab40ae1b9d49a0344 Author: Niels Möller Date: 2004-10-05 23:46:33 +0200 (q_table): Use a const pointer array. Rev: src/nettle/twofish.c:1.7 commit 7b6ff2dcdaef64e194c9b83eed3354a5acda9168 Author: Niels Möller Date: 1999-03-08 00:52:36 +0100 Moved UNUSED attribute to be compatible with gcc-2.x, x<8. Rev: src/symmetric/twofish.c:1.3 Note that the Rev: comments refer to different RCS files, and this information is needed to locate the corresponding change in the old CVS repo. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Migration from CVS to GIT
ni...@lysator.liu.se (Niels Möller) writes: > Yet another try, and unless I discover any problems with this soon, it's > going to be the final one. Turns out I had broken the handling of deleted files. So another try, git://git.lysator.liu.se/lsh-test/nettle-test-4.git Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Migration from CVS to GIT
I think the conversion can be declared final now. New repo at git://git.lysator.liu.se/nettle/nettle.git I have fixed the Makefiles so that they work in the new setting. After cloning, you need to run the ./.bootstrap script, then ./configure && make as usual. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: GNU MP not found (mingw)
Sorry for the late reply. yyy writes: > config.log did not contain any recognizable links to missing files > (there were multiple references to "-lgmp", but it was not a file) > (entire config.log is ~35KB, should I post it here? In the config.log there should be a line like configure:6551: checking for __gmpz_getlimbn in -lgmp (possibly with a different line number). If that test fails, you should find the test program, the compiler command line, and error messages, close by. Have you tried writing any testprogram of your own to link to gmp? One possible issue is if you have compiled gmp in 64-bit mode (gmp's configure does this by default, whenever possible), but you're compiling nettle in 32-bit mode. If so, try ./configure CC="gcc -m64" when building nettle. > Compiling and building GMP was successful, it produced file libgmp.a > with size of 648 236 bytes. So it's a static library. May make things simpler. > Where nettle's configure script is looking for lgmp and what is the > required filename? The answer to those questions are "whatever the used compiler and linker does.". To get nettle's configure to look in different directories for libraries (and include files! It also needs gmp.h), either use the -with-library-path and --with-include-path flags, or set LDFLAGS and CPPFLAGS on the configure command line. > Could it be, that nettle 2.4 does not work with > GMP 5.0.4 and requires older version? I think it should work fine with the most recent gmp version. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Salsa20
->input[8] = PLUSONE(ctx->input[8]);
> +if (!ctx->input[8]) {
> + ctx->input[9] = PLUSONE(ctx->input[9]);
> + /* stopping at 2^70 length per nonce is user's responsibility */
> +}
followed by an increment of the iv, where the second half appearantly is
used as a counter.
> +if (length <= 64) {
> + for (i = 0;i < length;++i) c[i] = m[i] ^ output[i];
> + return;
> +}
> +for (i = 0;i < 64;++i) c[i] = m[i] ^ output[i];
Followed by xoring the generated key stream to get the ciphertext.
Do I understand it correctly that there's nothing really non-linear
anywhere in this cipher? Only a mix of + and ^ which both are linear,
but over different rings. So the security aginst a known plaintext
attack would rest on the carry propagation, together with the large
state space of 512 bits (448 bits of expanded key material, and 64 bits
counter).
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Salsa20
ni...@lysator.liu.se (Niels Möller) writes: > I'm not familiar with this cipher... Could you explain briefly why one > may want to use it? I've done some more homework, reading some of djb's papers and the wikipedia page. Some questions: 1. Any protocols that specify use of salsa20? And in combination with which MAC? With claimed cycle numbers, hmac with sha1 or sha2 is going to take much more time than the encryption. 2. What about the later "ChaCha" cipher? As far as I see, it has not been studied as much as Salsa20. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Salsa20
Simon Josefsson writes: > Please find attached a port of DJB's public domain code for Salsa20 > to nettle. The patch is not meant to be applied as-is but to start a > discussion. Nevertheless, I have now commited salsa20.[ch] and the testcase, postponing remaining work for later. ;-) Needed: * Support in nettle-benchmark in some way (can probably get away with a stupid nettle_cipher setting the iv to some fixed value). * A bit of cleanup of the code. * Try optimization of the C code for 64-bit machines. One ought to be able to do two column or row operations in parallel by putting two salsa20 words into a uint64_t variable. May need some tricks to avoid carry propagation between the words, but I suspect it may be a win due to lower register pressure. A bit similar to the HAVE_NATIVE_64_BIT in camellia-crypt-internal.c. * Try an sse2 assembly implementation (the djb:s papers outline how to do that). Or copy some existing implementation. * Documentation. As for the salsa20_* interface: * It would be possible to change the interface to not expose the block size, doing a little buffering instead. But I think it's better to not do that, and follow what the ctr code and gcm code does. * One advertised feature of the cipher is random access. I think we should have something like a salsa20_set_pos, taking a block count as argument. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Salsa20
And now I've added support for salsa20 benchmarking as well. Performance
is pretty good, even for this reference implementation. Seems to run at
12 cycles per byte on my laptop, a little faster than 128-bit aes.
To get that working, I added a very kludgy
const struct nettle_cipher nettle_salsa20 = {...};
to nettle-internal.c, for benchmarking only.
I also arranged in the Makefile so that nettle-internal.o no longer is
included in the nettle library. Will that cause any trouble for anybody?
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Salsa20
ni...@lysator.liu.se (Niels Möller) writes: > And now I've added support for salsa20 benchmarking as well. Performance > is pretty good, even for this reference implementation. Seems to run at > 12 cycles per byte on my laptop, a little faster than 128-bit aes. Now I've done some cleanup and reorganization work. Using memxor3 for the actual xoring saves almost 3 cycles per byte, so it's a considerable speedup in this case (and then memxor3 can maybe be sped up a bit more on this platform, from Nikos' work a while ago). I wonder if there's any potential for simd-style parallel processing using plain 64-bit operations (no sse2 assembly). If one puts two 32-bit values in a 64-bit variable, parallel xor is trivial, but we also need 32-bit rotations and adds. Parallel rotations are possible as two shifts and some extra masking, so it might be slightly faster than two 32-bit rotations of two shifts each. For parallel mod 2^32 additions, one need to cancel one of the carries. Something like uint64_t x, y, z; z = x + y; z += (- (uint64_t) ((uint32_t) z < (uint32_t) y)) << 32; This can hardly be faster than two 32-bit additions (two lea, cmp, cmov on x86_64, or alternatively, one lea, cmp, sbb, shl, add, depending on code genereration). Any speedup depends on the relative speedup or slowdown of each primitive, the cost of permuting values as needed, and then the effects of reduced register pressure on top of that. For x86_64 (and maybe x86_32), assembly implementation also seems attractive, but I'd like to do any general or 64-bit specific optimizations in the C code first. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: rsa blinding patch
Nikos Mavrogiannopoulos writes:
> I can see it on my sent folder. Could it be that the list manager removed it?
Possibly. The mailman config is known to be a bit picky (and I'm not
very good at configuring it), but I thought it would usually bounce
messages rather than silently remove attachments.
> I've put it at:
> http://homes.esat.kuleuven.be/~nikos/0001-Added-timing-resistant-versions-of-rsa_compute_root-.patch
Thanks! I've had a quick look. A few comments:
I'm not sure if the low-level rsa_compute_root should be aware of the
blinding, or if it should be the responsibility of its callers (using
_rsa_blind, _rsa_unblind helper functions, put in rsa_blind.c or so).
Support for blinding is desirable not only for rsa_decrypt, but also for
the various rsa_*_sign functions, right?
The blinding function should probably use nettle_mpz_random, which
provides for *almost* uniform distribution mod n by generating a few
extra bits before the mpz_fdiv_r.
As for interface, I have been considering to also add some kind of
deterministic dsa signatures, substituting something like HMAC(private
key, message) for the random input, and if possible, it would be nice to
have a consistent interface for {rsa, dsa} signatures {with, without}
randomness input.
Not sure if we should have separate functions for operation with and
without blidning, or a single function with an optional randomness
source as argument. If we have separate functions, we have to decide on
the name (I don't quite like "_timing": If the name is supposed to
describe intended use, it needs to be more verbose, maybe
"_timing_resistant". I think it may be more handy to rather describe
what it *does*, something like "_blinding" or "_randomized" or so).
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: rsa blinding patch
Nikos Mavrogiannopoulos writes: > What about _ct for constant time? The _blinding is really specific > on the method used to achieve constant time. But it's not really constant time, is it? Rather, timing is random but independent of the inputs which are under control of the attacker. While without RSA blinding, timing depends on the secret key and on data provided by the attacker, which is a bad combination. The function mpz_powm_sec in recent GMP is supposed to really be "constant time" (assuming the underlying multiply-instruction doesn't have data-dependent timing). I.e., the instructions executed and the memory access pattern should depend only on the sizes of the input operands, not on the actual values. Hence it should be resistant both to timing attacks, and attacks manipulating or observing the memory cache hit rate. But RSA operations uses a couple of additional functions, which doesn't yet have constant-time counterparts, so I don't yet use that function yet. BTW, what's a good reference for the recommendation to use RSA blinding? Is it in Handbook of applied cryptography? (I think pointers to papers on attacks have been posted previously, but that's describing the problem, not the solution...). Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: rsa blinding patch
1,11 @@
-/* rsa_decrypt.c
+/* rsa-decrypt.c
*
* The RSA publickey algorithm. PKCS#1 encryption.
*/
/* nettle, low-level cryptographics library
*
- * Copyright (C) 2001 Niels Möller
+ * Copyright (C) 2001, 2012 Niels Möller
*
* The nettle library is free software; you can redistribute it and/or modify
* it under the terms of the GNU Lesser General Public License as published by
@@ -27,54 +27,22 @@
# include "config.h"
#endif
-#include
-#include
-#include
-
#include "rsa.h"
-#include "bignum.h"
-#include "nettle-internal.h"
+#include "pkcs1.h"
int
rsa_decrypt(const struct rsa_private_key *key,
unsigned *length, uint8_t *message,
const mpz_t gibberish)
{
- TMP_DECL(em, uint8_t, NETTLE_MAX_BIGNUM_BITS / 8);
- uint8_t *terminator;
- unsigned padding;
- unsigned message_length;
-
mpz_t m;
+ int res;
mpz_init(m);
rsa_compute_root(key, m, gibberish);
- TMP_ALLOC(em, key->size);
- nettle_mpz_get_str_256(key->size, em, m);
+ res = pkcs1_decrypt (key->size, m, length, message);
mpz_clear(m);
-
- /* Check format */
- if (em[0] || em[1] != 2)
-return 0;
-
- terminator = memchr(em + 2, 0, key->size - 2);
-
- if (!terminator)
-return 0;
-
- padding = terminator - (em + 2);
- if (padding < 8)
-return 0;
-
- message_length = key->size - 3 - padding;
-
- if (*length < message_length)
-return 0;
-
- memcpy(message, terminator + 1, message_length);
- *length = message_length;
-
- return 1;
+ return res;
}
diff --git a/rsa.h b/rsa.h
index a4ef835..75eaafc 100644
--- a/rsa.h
+++ b/rsa.h
@@ -32,9 +32,6 @@
#include "md5.h"
#include "sha.h"
-/* For nettle_random_func */
-#include "nettle-meta.h"
-
#ifdef __cplusplus
extern "C" {
#endif
@@ -64,7 +61,10 @@ extern "C" {
#define rsa_sha512_verify_digest nettle_rsa_sha512_verify_digest
#define rsa_encrypt nettle_rsa_encrypt
#define rsa_decrypt nettle_rsa_decrypt
+#define rsa_decrypt_tr nettle_rsa_decrypt_re
#define rsa_compute_root nettle_rsa_compute_root
+#define _rsa_blind _nettle_rsa_blind
+#define _rsa_unblind _nettle_rsa_unblind
#define rsa_generate_keypair nettle_rsa_generate_keypair
#define rsa_keypair_to_sexp nettle_rsa_keypair_to_sexp
#define rsa_keypair_from_sexp_alist nettle_rsa_keypair_from_sexp_alist
@@ -260,7 +260,7 @@ rsa_sha512_verify_digest(const struct rsa_public_key *key,
int
rsa_encrypt(const struct rsa_public_key *key,
/* For padding */
- void *random_ctx, nettle_random_func random,
+ void *random_ctx, nettle_random_func *random,
unsigned length, const uint8_t *cleartext,
mpz_t cipher);
@@ -274,12 +274,31 @@ rsa_decrypt(const struct rsa_private_key *key,
unsigned *length, uint8_t *cleartext,
const mpz_t ciphertext);
+/* Timing-resistant version, using randomized RSA blinding. */
+int
+rsa_decrypt_tr(const struct rsa_public_key *public,
+ const struct rsa_private_key *key,
+ void *random_ctx, nettle_random_func random,
+ unsigned *length, uint8_t *message,
+ const mpz_t gibberish);
+
/* Compute x, the e:th root of m. Calling it with x == m is allowed. */
void
rsa_compute_root(const struct rsa_private_key *key,
mpz_t x, const mpz_t m);
+/* Blinds the c, by computing c *= r^e (mod n), for a random r. Also
+ returns the inverse (ri), for use by rsa_unblind. */
+void
+_rsa_blind (const mpz_t n, const mpz_t e,
+ void *random_ctx, nettle_random_func *random,
+ mpz_t c, mpz_t ri);
+
+/* c *= ri mod n */
+void
+_rsa_unblind (const mpz_t n, mpz_t c, const mpz_t ri);
+
/* Key generation */
/* Note that the key structs must be initialized first. */
@@ -287,8 +306,8 @@ int
rsa_generate_keypair(struct rsa_public_key *pub,
struct rsa_private_key *key,
-void *random_ctx, nettle_random_func random,
- void *progress_ctx, nettle_progress_func progress,
+void *random_ctx, nettle_random_func *random,
+void *progress_ctx, nettle_progress_func *progress,
/* Desired size of modulo, in bits */
unsigned n_size,
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: rsa blinding patch
ni...@lysator.liu.se (Niels Möller) writes: > I think it makes some sense to implement rsa_decrypt_tr now, with no > advertised internals, and give the signature interface more time. I've committed an rsa_decrypt_tr now, based on Nikos' code. I reordered the arguments a bit, in an attempt to be more consistent with other rsa functions, so the prototype is now /* Timing-resistant version, using randomized 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); Does this make sense? If you are using the rsa encrypt/decrypt functions, and the interface is ok, I guess we should also document them. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: rsa blinding patch
Nikos Mavrogiannopoulos writes: > Although the HMAC avoids the need for randomness, you need to get a key > somehow, so the gain might not be much. The idea is to reuse (hash of) the private RSA key as the HMAC key. And similarly for deterministic DSA. > What about the rsa_compute_root? This is the only function I can use > from nettle for RSA signatures I wasn't aware of that. That's an argument for an rsa_compute_root_tr (or alternatively, public rsa_blind and rsa_unblind helpers). Can you explain briefly what special signatures are used by tls? (It was more then 10 years since I wrote an implementation, then it was ssl version 3). > If there was an rsa_pkcs1_sign() and rsa_pkcs1_verify() with similar > interface to encrypt/decrypt, I could use those instead. Can you propose such an interface? Currently, rsa_md5_sign calls pkcs1_rsa_md5_encode followed by rsa_compute_root. If it's easy for you to use rsa_compute_root in the same way, then I guess there's no need to introduce new low-level primitives, but maybe it could be rearranged in some better way? Or, since tls is an important application, it may make sense to directly add tls-style signatures to Nettle. > I had modified the rsa-encrypt-test.c to include a test for the > timing resistant version as well. Other than that I have no other test > cases. I see. It would really be helpful with some tools for measuring the input dependence in the timing of rsa_compute_root. GMP's mpz_powm may well behave quite differently from openssl's. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: rsa blinding patch
Nikos Mavrogiannopoulos writes: > I do the pkcs1 1.5 encoding in gnutls, and you also do it in the high > level functions in nettle, that I cannot use. It would be nice if we > can save some code and reduce error risk by having a common pkcs1 1.5 > signing function. I'll try to propose one the next few days. Have you looked at pkcs1_signature_prefix? It does part of the work, so maybe it's a good starting point. The reason it leaves space for the actual digest rather than copying it in place, is to avoid extra copies for the rsa_md5_sign-style functions. If this could be simplified, to reduce the amount of duplicated code to implement signatures for each supported hash function, while keeping low overhead for applications using only a single variant, that would be nice. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: rsa blinding patch
Nikos Mavrogiannopoulos writes: > /* RSA signatures, using PKCS#1 1.5 > * Input should be a BER encoded DigestInfo > */ > int > rsa_digest_info_sign(const struct rsa_private_key *key, > unsigned length, const uint8_t *digest_info, > mpz_t signature); > > int > rsa_digest_info_verify(const struct rsa_public_key *key, >unsigned length, const uint8_t *digest_info, >const mpz_t signature); That seems reasonable (if and how the implementation of nettle's other rsa sign/verify functions could be reorganized to make use of that, I'm not sure). Minor points: It should really be DER encoded, right? And I guess you'd also want a _sign_tr variant. As for naming, maybe I'd want to have "pkcs1" int he name, not sure. A question for all of you: Nettle currently has two flavors of sign functions for each algorithm. E.g., int rsa_sha1_sign(const struct rsa_private_key *key, struct sha1_ctx *hash, mpz_t signature); int rsa_sha1_sign_digest(const struct rsa_private_key *key, const uint8_t *digest, mpz_t s); The former could be implemented in terms of the latter (currently it's not, to avoid an unnecessary copy, which may be a pointless optimization in this context). The point of the first function is convenience, where you can create a signature simply by sha1_init sha1_update rsa_sha1_sign without bothering with allocating and writing the actual digest. Do you think this design makes sense? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Salsa20
ni...@lysator.liu.se (Niels Möller) writes: > For x86_64 (and maybe x86_32), assembly implementation also seems > attractive, I just push an x86_64 implementation of salsa20_crypt. Runs at 6.6 cycles/byte on my laptop (or 189 Mbyte/s), which is more than twice the speed of aes128, and slightly faster than arcfour. It's likely possible to squeeze out a cycle or two more, by doing two blocks in parallel (I think djb's x86_64 code does that, but I found it very hard to read), or by other micro-optimizations. Do any of you know of any protocols which specify use of salsa20? Is it usually combined with some *fast* MAC algorithm? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: AES assembler not compatible with Windows x64
Martin Storsjö writes: > This should already be fixed in the latest git version (and latest cvs > version prior to the conversion), and in the 2.5-prerelease at > http://www.lysator.liu.se/~nisse/archive/nettle-2.5-pre.tar.gz. Guess I should make a 2.5 release soon. I had planned to get xenofarm up and running for the new repository before release, but that has turned out to be harder than I expected. So maybe the release shouldn't have to wait for that. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Salsa20
> > Yes. Suggestions for name? I think set_iv should still set the count to zero, so you need to use the new function only if you want to do seeeks in the data. >> Do any of you know of any protocols which specify use of salsa20? Is it >> usually combined with some *fast* MAC algorithm? > > I suspect people who like Salsa are inclined to also like CubeHash, > which could be used in HMAC variants. CubeHash is fast with optimistic > parameters, but the "default" is pretty conservative making it not so > fast. Maybe it's possible to do something in the style of ofb, to get authentication cheaply as a side effect (haven't looked very closely at ofb, though, and ofb itself seems to be unusable in Nettle due to patents). Maybe I should mail djb and ask. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc
Dagobert Michelsen writes: > I just verified that the problem persists with nettle 2.4 and gnutls-3.0.19. > As you seem to have > access to the Solaris buildfarm it would be cool if you could finally fix > this as it blocks > new releases of gnutls for the OpenCSW distribution. It's some time since I looked in to this. My understaning of the problem is that 1. This Solaris version lack both and . (A comment in AX_CREATE_STDINT_H seems to imply that it does have a , should we use that?) 2. Nettle defines uint32_t and friends using the AX_CREATE_STDINT_H autoconf macro. 3. gnulib defines them in a different way. 4. The multiple definitions of, e.g., uint32_t, agree and are no problem. 5. The definitions of some other (unused) types are incompatible, e.g., int_fast8_t, and cause the compilation errors. 6. The definitions from AX_CREATE_STDINT_H is compatible with the definitions of these types in Solaris 10. gnulib's definitions aren't, so any code using them can potentially break if linked together with code compiled on Solaris 10. Hence I think it ought to be fixed in gnulib. Simon (and any other gnulib people on these lists), do you agree? To address (1), maybe you can try diff --git a/configure.ac b/configure.ac index 6bf2b8b..77bb9b1 100644 --- a/configure.ac +++ b/configure.ac @@ -518,7 +518,7 @@ LSH_GCC_ATTRIBUTES # According to Simon Josefsson, looking for uint32_t and friends in # sys/types.h is needed on some systems, in particular cygwin. -AX_CREATE_STDINT_H([nettle-stdint.h], [sys/types.h]) +AX_CREATE_STDINT_H([nettle-stdint.h], [sys/types.h], [sys/inttypes.h]) # Check for file locking. We (AC_PROG_CC?) have already checked for # sys/types.h and unistd.h. but I suspect you would still get compilation errors due to incompatible definitions in gnulib and sys/inttypes.h. Maybe the easiest nettle workaround would be to somehow disable the definitions of the problematic types, which we don't use anyway. Could you try something like the following? diff --git a/nettle-types.h b/nettle-types.h index b694332..d0aa332 100644 --- a/nettle-types.h +++ b/nettle-types.h @@ -23,6 +23,9 @@ #ifndef NETTLE_TYPES_H #define NETTLE_TYPES_H +/* Pretend this type always exists. Nettle doesn't use it. */ +#define _STDINT_HAVE_INT_FAST32_T 1 + #include "nettle-stdint.h" #ifdef __cplusplus Have a look into the generated nettle-stdint.h (or the template in aclocal.m4) for other potentially useful defines. The closest Solaris 5.8 box I used to have acccess to (hanna.lysator.liu.se) seems to have been decomissioned. Regardss, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc
Simon Josefsson writes: > Yes. Understanding what the differences is, and which one is right, > seems useful first though. If the problem is in gnulib, we can fix > that and GnuTLS will have the new variant soon. Quoting my investigation from an old (off-list) email thread, from November last year: And the problem seems to be that inttypes.h doesn't define int_fast8_t types. And then AX_CREATE_STDINT_H (used by nettle) and gnulib (used by gnutls) both decide to define them, and they do that in an incompatible way. --- From a quick look at gl/stdint.h.in and on posted error messages, I think glib uses long for all of int_fast8_t, int_fast16_t and int_fast32_t, and int64_t for int_fast64_t, while nettle uses int8_t, int, int32_t and int64_t. --- >> Actually, one ought to have a look at the definitions in the stdint.h >> provided by gcc (and at the definitions in the solaris10 stdint.h), and >> make sure the definitions of the int_fast* types are equivalent. >> Otherwise one might end up with subtle ABI differences and errors when >> linking together code compiled by different compilers. > > Agreed. I did a quick check. The following seems to be the correct sizes: int_fast8_t: 1 int_fast16_t: 4 int_fast32_t: 4 int_fast64_t: 8 This is using sizeof on the types defined in stdint.h, trying: gcc -m32 on solaris 9 gcc -m64 on solaris 9 cc -m32 on solaris 10 cc -m64 on solaris 10 Remarkably enough, they all agree. I also get the same sizes from nettle-stdint.h, for both 32 bit and 64 bit configurations. So I think nettle (or really, AX_CREATE_STDINT_H) gets this right. While if I understand gl correctly, it uses 4,4,4,8 for a 32-bit build and 8,8,8,8 for a 64-bit build (the size of long is different). This seems wrong. Sure, these are perfectly ok sizes according to C99, but they differ from the sparc conventions (and possibly conventions for other architectures as well). Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Release plans
I've updated the todo page http://www.lysator.liu.se/~nisse/nettle/plan.html (also as misc/plan.html in the git repo). Any missing items? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
RSA private key abstraction
I'm thinking about how to represent private keys. The context is the
desire to support RSA blinding. I'd like to avoid having to duplicate
all the signature functions (of which there's already a large number).
This email is an expansion of a 3.0 entry in plan.txt.
One way would be to pass a function pointer (and some optional ctx) for
doing the private key operation. This would then be used wherever the
current code calls _rsa_compute_root, and it would represent an RSA
private key oracle.
If we stick to software implementation, one could pass it as an extra
argument, or one could extend the private key struct like
struct rsa_private_key
{
mpz_t d;
...
rsa_compute_root_func *f;
};
and one could then "subclass" that as
struct rsa_private_key_blinding
{
struct rsa_private_key super;
struct whatever_random_ctx_needed ctx;
};
(not sure this is the best design, but it's one possibility).
Now I have a question: Would it be feasible to support smartcards (and
similar hardware) at the same time? Then the secret key wouldn't be
available at all to nettle, and a signature function might have an
interface like
int
rsa_sha1_sign(rsa_compute_root_func *f, void *private,
struct sha1_ctx *hash,
mpz_t signature);
where the actual private key data is totally dependent on the smartcard
and its interface software.
But what interfaces do typical smartcards use? Do they allow you to
compute an arbitrary rsa root, or do they only more specific operations
like "pkcs#1 v1.5 decrypt", "pkcs#1 v1.5 sha1 sign", #pkcs#1 v2.0 sha256
sign"?
I want to figure out if smartcard support at this level is at all
feasible. If not, we have to leave that for applications and libraries
on top of nettle, and then the nettle interface should be tailored for
software keys only.
I've also had a quick look at the ssh-agent and gpgagent protocols. Both
seems a bit too application specific, so I don't think it's feasible to
hook in those as general "private key oracles" here.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc
Dagobert Michelsen writes: > I see different possibilities on how this can be resolved: > > 1. nettle uses the gnulib definitions I currently have no plans to switch to using gnulib. As far as I'm aware, there's no problem with the types which nettle actually uses. So it would be a reasonable workaround to simply not define the int_fast*_t types; then they won't collide with the incompatible definitions gnutls gets from gnulib. Question is just what's the least intrusive way to do that (*if* it's easy to avoid, I'd prefer not to modify the definition of AX_CREATE_STDINT_H). I would appreciate if you can try the workarounds I suggested the other day and let me know how it works. > 2. gnulib changes the definitions to conform to nettle The problem with gnulib is not primarily that it doesn't "conform to nettle", but that it defines some types in a way that differs both from on later releases on the OS (where the types are included), and from the definition in the stdint.h which comes with gcc. So code which uses the int_fast*_t types and relies on gnulib will get a slightly different ABI if compiled on SunOS-5.9 (or earlier) using Sun's compiler, than if compiled with gcc on the same system, or compiled with Sun's compiler on any later release of the OS. I think that's what needs to be fixed in gnulib. Do the gnulib folks agree? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc
Paul Eggert writes: > Generally speaking, it's unwise to use > the int_fast*_t types in a public header file. Why (feel free to point to the relevant section of gnulib docs, if it's explained well there)? Maybe nobody uses these types so it's an academic issue, but if these types are used in the interface to any library (possibly some system library), then it's important that applications agree on the definition. To me, it seems like the authoritative definition of int_fast*_t ought to be the system's ABI specification. And in the case of SunOS-5.9, where the types are missing, I think it makes the most sense to adopt the ABI of SunOS-5.10. Which also seems to be what gcc does. I'm a bit confused by your statement. I had the impression that gnulib *does* fall back on the definitions in public headers like and , for the types which *are* defined there. And that's why nettle and gnutls seem to work together on SunOS-10. Correct? > This is a documented issue in Gnulib. > It's hard to imagine a general fix for this. 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. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc
Bruno Haible 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 in nettle-types.h before it includes nettle-stdint.h. Or if that doesn't work out, it's fine to hack away in the definition in aclocal.m4 to take out the unneded types. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc
Paul Eggert 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 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. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc
Paul Eggert 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 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 . 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. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc
Paul Eggert 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 -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc
Paul Eggert 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 nettle-stdint.h. Maybe not the prettiest way to do it, but apparantly it solves the problem, independently of your fixes to gnulib. (But I'd still like to know if your fixes also solves this problem, independently of that Nettle workaround). > I'd rather have an approach where the code simply does "#include > " and assumes that int_fast8_t works. I don't understand the > overall situation, though, so I don't know what exactly to suggest. I think when you build gnutls on a system lacking stdint.h, a typical compilation unit will contain /* From gnulib's stdint.h */ typedef unsigned int gl_uint32_t; #define uint32_t gl_uint32_t ... /* From nettle/nettle-stdint.h */ typedef unsigned int uint32_t; where the final line is macro-expanded to typedef unsigned int gl_uint32_t; >From what I've seen, this has been no problem. And I hope nettle-stdint.h and gnulib/stdint.h always do these types in the same way. There is some freedom in how to define these types; on a system where for example int and long are the same size, typedef unsigned long uint32_t; typedef unsigned int uint32_t; would be a two distinct but correct definitions, and I imagine the compiler would complain. And to consider the problematic int_fast*_t types, until a day or two ago, you got /* From gnulib's stdint.h */ typedef long gl_int_fast8_t; #define int_fast8_t gl_int_fast8_t ... /* From nettle/nettle-stdint.h */ typedef char int_fast8_t; which no reasonable compiler will accept. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc
Dagobert Michelsen writes: > If Paul or you could provide a bootstrapped tarball I'll be happy to test it > as > I am not really familiar with gnulib bootstrapping. I'm also not very familiar with gnulib. But 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. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Configure problem on OS-X
William Morris writes: > 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? config.h.in is generated from configure.ac. You need to run the .bootstrap script after you check out the sources from git. Currently, that script just runs autoconf and autoheader, and it's the latter program which generates config.h.in. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc
Dagobert Michelsen writes: > 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. Thanks. > However, I didn't change anything on the nettle includes and now get > lots of warnings. Are these warnings harmless? If so, I think this is good enough. > Probably the gl_* definitions should not belong to the installed > nettle headers? They don't, they're defined in gnulib, and appear in the nettle-stdint.h warnings because of gnulib's preprocessor macros. In gnutls/gl/stdint.h: typedef signed char gl_int_fast8_t; ... #define int_fast8_t gl_int_fast8_t; In nettle-stdint.h (included later in the compilation unit): typedef int8_t int_fast8_t; > CC pkcs12_bag.lo > "/opt/csw/include/nettle/nettle-stdint.h", line 237: warning: typedef > redeclared: gl_int_fast8_t > "/opt/csw/include/nettle/nettle-stdint.h", line 238: warning: typedef > redeclared: gl_int_fast16_t > "/opt/csw/include/nettle/nettle-stdint.h", line 239: warning: typedef > redeclared: gl_int_fast32_t > "/opt/csw/include/nettle/nettle-stdint.h", line 241: warning: typedef > redeclared: int64_t > "/opt/csw/include/nettle/nettle-stdint.h", line 244: warning: typedef > redeclared: gl_uint_fast8_t > "/opt/csw/include/nettle/nettle-stdint.h", line 245: warning: typedef > redeclared: gl_uint_fast16_t > "/opt/csw/include/nettle/nettle-stdint.h", line 246: warning: typedef > redeclared: gl_uint_fast32_t > "/opt/csw/include/nettle/nettle-stdint.h", line 248: warning: typedef > redeclared: uint64_t I don't understand why you get "uint64_t" rather than "gl_uint64_t", it seems gnulib handles this type (and int64_t) differently from the rest. But if it works now, despite these warnings, I think we can consider this problem solved. Do you agree? (And then I also have the fix in nettle to avoid defining the *int_fast*_t types at all, which you have tested previously and which also solved the problem, right?) Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Interface for new rsa features
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 "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. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Interface for new rsa features
Nikos Mavrogiannopoulos writes: >> 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. > If this is because of me, feel free to correct it. It must have been a typo. I don't think you introduced that. I changed the typedef from typedef void (*nettle_random_func)(void *ctx, unsigned length, uint8_t *dst); to typedef void nettle_random_func(void *ctx, unsigned length, uint8_t *dst); some versions ago (and similarly for other typedefs for function type). And I tried to update all uses at the time, but I'm afraid I didn't get them all (rsa_encrypt, rsa_generate_keypair). And then we got it wrong for the recent rsa_decrypt_tr. So I'll fix them as I find them. Technically, that may be an API change, but I think it's very unlikely to cause any problems. >> 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? > > I'd say this is a good option. If you care about backwards compatibility > then the old function could also be present. The possibility of keeping the old one hadn't occured to me, but that's a good suggestion. It's easy to do, and nice to users. Maybe I should also read up on how to tell gcc that it is considered both internal and obsolete. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Getting a bit closer to release
I've done some documentatiion for Salsa20, so we're getting closer to release. See http://www.lysator.liu.se/~nisse/nettle/plan.html. NEWS-file review and some more testing remains on the list. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Using alloca on windows
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 malloc.h, but only if *not* using gcc. Should I always include malloc.h if it exists, regardless of the compiler used? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Getting a bit closer to release
Martin Storsjö writes: > Re testing, I tried doing a build on 64 bit OS X, which fails at: > > salsa20-crypt.s:364:suffix or operands invalid for `movq' > salsa20-crypt.s:370:suffix or operands invalid for `movq' That sounds vaguely familiar. I think it has been reported earlier, but not fixed. This instruction, "movq %xmm4, %r8" is used to copy the low 64 bits from an %xmm register to a regular 64-bit register. Any idea on how to write that in a way which makes the osx assembler happy? I'm not aware of any other instruction for doing that type of copy, but any reasonable workaround is appreciated. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Using alloca on windows
Martin Storsjö writes: > That sounds like a sane solution to me - if it exists, including it > shouldn't hurt I guess. Ok. Done and pushed now. Another windows problem: I get link warnings, e.g., i586-mingw32msvc-gcc -g -O2 -ggdb3 -Wno-pointer-sign -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wpointer-arith -Wbad-function-cast -Wnested-externs -L.. nettle-benchmark.o nettle-openssl.o ../getopt.o ../getopt1.o ../nettle-internal.o -lnettle -o nettle-benchmark.exe Info: resolving _nettle_aes128 by linking to __imp__nettle_aes128 (auto-import) Info: resolving _nettle_aes192 by linking to __imp__nettle_aes192 (auto-import) Info: resolving _nettle_aes256 by linking to __imp__nettle_aes256 (auto-import) Info: resolving _nettle_arcfour128 by linking to __imp__nettle_arcfour128 (auto-import) Info: resolving _nettle_camellia128 by linking to __imp__nettle_camellia128 (auto-import) Info: resolving _nettle_camellia192 by linking to __imp__nettle_camellia192 (auto-import) Info: resolving _nettle_camellia256 by linking to __imp__nettle_camellia256 (auto-import) Info: resolving _nettle_cast128 by linking to __imp__nettle_cast128 (auto-import) Info: resolving _nettle_serpent256 by linking to __imp__nettle_serpent256 (auto-import) Info: resolving _nettle_twofish128 by linking to __imp__nettle_twofish128 (auto-import) Info: resolving _nettle_twofish192 by linking to __imp__nettle_twofish192 (auto-import) Info: resolving _nettle_twofish256 by linking to __imp__nettle_twofish256 (auto-import) Info: resolving _nettle_md2 by linking to __imp__nettle_md2 (auto-import) Info: resolving _nettle_md4 by linking to __imp__nettle_md4 (auto-import) Info: resolving _nettle_md5 by linking to __imp__nettle_md5(auto-import) Info: resolving _nettle_sha1 by linking to __imp__nettle_sha1 (auto-import) Info: resolving _nettle_sha224 by linking to __imp__nettle_sha224 (auto-import) Info: resolving _nettle_sha256 by linking to __imp__nettle_sha256 (auto-import) Info: resolving _nettle_sha384 by linking to __imp__nettle_sha384 (auto-import) Info: resolving _nettle_sha512 by linking to __imp__nettle_sha512 (auto-import) Info: resolving _nettle_ripemd160 by linking to __imp__nettle_ripemd160 (auto-import) Info: resolving __nettle_sha1_compress by linking to __imp___nettle_sha1_compress (auto-import) /usr/lib/gcc/i586-mingw32msvc/4.4.4/../../../../i586-mingw32msvc/bin/ld: warning: auto-importing has been activated without --enable-auto-import specified on the command line. This should work unless it involves constant data structures referencingsymbols from auto-imported DLLs. I get similar warnings for building most or all executables. Most seem harmless; make check succeeds (running all testprograms via wine). However wine examples/nettle-benchmark.exe crashes. wine: Unhandled page fault on execute access to 0x66210226 at address 0x66210226 (thread 0009), starting debugger... Unhandled exception: page fault on execute access to 0x66210226 in 32-bit code (0x66210226). [...] Backtrace: =>1 0x66210226 (0x0062feb8) 2 0x004010a7 in nettle-benchmark (+0x10a7) (0x0062fee8) 3 0x00401143 in nettle-benchmark (+0x1143) (0x0062ff08) 4 0x7b8783a8 in kernel32 (+0x583a8) (0x0062ffe8) And it links in nettle-internal.o, which indeed defines a couple of constant structures with pointers to functions in nettle.dll. Is there any easy way to improve the situation? At this time, I don't want to redo the dll rules and add dllimport and dllexport clutter to headers (if that would even help?). Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Getting a bit closer to release
Martin Storsjö writes: > If I change it into movd instead of movq, it builds fine on OS X, and > the tests pass. Curious. That use of movd is not in accord with my intel manuals, as far as I understand them. > On Linux, it doesn't seem to break anything either. And if checking > the output with objdump -d, it is encoded into the same opcode (which > objdump reports as movq). I think I'll double check that, and then check in that change. Thanks for the help! Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Getting a bit closer to release
ni...@lysator.liu.se (Niels Möller) writes: > I think I'll double check that, and then check in that change. Done now. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Final nettle-2.5 prerelease
I think everything's in shape for release. But I'll postpone the formal release to an evening *before* having a glass or two of wine. ;-) So here's a final prerelease http://www.lysator.liu.se/~nisse/archive/nettle-2.5-pre2.tar.gz http://www.lysator.liu.se/~nisse/archive/nettle-2.5-pre2.tar.gz.sig Hopefully the 2.5 release will differ in filename only. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
ANNOUNCE: Nettle-2.5
I'm happy to annnounce a new version of GNU Nettle, a low-level cryptographics library. The Nettle home page can be found at http://www.lysator.liu.se/~nisse/nettle/. NEWS for the 2.5 release This release includes important portability fixes for Windows and MacOS. There are also a few new features. First a *warning*: Some internal functions have been removed from the library. Since the functions in question are internal and not documented, this is not considered a change of ABI or API. Programs explicitly using any of these functions will break. * The function pkcs1_signature_prefix has been renamed to _pkcs1_signature_prefix, and with slightly different behavior. * The file nettle-internal.c is no longer included in the library (the features defined there are used by the benchmark and test programs, and were never intended for public use). New features: * Support for the salsa20 block cipher, including x86_64 assembler. Originally contributed by Simon Josefsson, based on the reference implementation, then further optimized. * Tentative interface for timing-resistant RSA functions, contributed by Nikos Mavrogiannopoulos. * A more general interface for PKCS#1 signatures, taking the input in the form of a "DigestInfo". Suggested by Nikos Mavrogiannopoulos. Configuration: * Building of shared libraries (./configure --enable-shared) is now enabled by default. * Various portability fixes for MacOS and M$ Windows. A lot of this work done by Martin Storsjö. * In particular, Nettle now hopefully works on 64-bit Windows builds, "W64", including the x86_64 assembly code. Miscellaneous: * Documentation and example programs for the base16 and base64 functions. Was contributed by Jeronimo Pellegrini back in 2006, but unfortunately forgotten until now. * Use an additional table to avoid GF2^8 multiplications in aes_invert_key (mainly used by aes_set_decrypt_key). Also tabulate round constants in aes_set_encrypt_key. * The nettle repository has been migrated from cvs to git, with a public repository at http://git.lysator.liu.se/nettle. To make it independent of the LSH repository, a few files have been moved around. While at it, files have also been converted from latin-1 to utf-8. The libraries are intended to be binary compatible with nettle-2.2 and later. The shared library names are libnettle.so.4.4 and libhogweed.so.2.2, with sonames still libnettle.so.4 and libhogweed.so.2 Available at http://www.lysator.liu.se/~nisse/archive/nettle-2.5.tar.gz ftp://ftp.gnu.org/gnu/nettle/nettle-2.5.tar.gz and soon also at ftp://ftp.lysator.liu.se/pub/security/lsh/nettle-2.5.tar.gz Happy hacking, /Niels Möller -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Patch: Fix building of nettle-benchmark on uclibc systems
"Anthony G. Basile" writes: > Attached is a patch to fix the building of examples/nettle-benchmark > on uclibc systems while not introducing a regression on glibc. If the use of ldexp is the only reason libm is needed, maybe it's better to rewrite bench_sha1_compress (or the GET_CYCLE_COUNTER macro)? For now, I'm adding -lm to BENCH_LIBS. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH] some patches to fix compiler warnings
Tim Ruehsen writes: > Some things I fixed, when having a look at the sources. Thanks. I'm going to a reply to one or a few issues at a time. Feel free to remind me if some things are still left unaddressed in a few weeks. > #define NONNULL(...) __attribute__ ((nonnull(__VA_ARGS__))) > is contains a C99 feature (...), but there are also C99 long long constants > somewhere in the code (if you mind C89 compliancy). I intend to stick to C89, except that I'll happily use features which have been widely available for a long time even though not standardized. Maybe the use of long long constants (where?) are of that type? So I don't want to use __VA_ARGS__. In this particular case, shouldn't it work fine with #define NONNULL(args) __attribute__ ((nonnull args)) to be used as, e.g., NONNULL((1)) ? About __attribute__ nonnull, I have some questions. 1. Does it give any significant benefit, in terms of significant optimizations (I don't think I understand what optimizations it should make possible) or real bugs catched? 2. Since when (release and year) is it supported by gcc? 3. To really make use of it, we should add it to a lot of prototypes in the installed headers. That makes things a bit more complicated, since those headers can't use config.h. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH] some patches to fix compiler warnings
Tim Ruehsen writes:
>> #define NONNULL(args) __attribute__ ((nonnull args))
>
> Yes, functions with several non-null args than need several NONNULL(x)
> occurrences.
I don't think so. NONNULL((1,3,5)) should work, with "(1,3,5)" treated
as a single argument by the preprocessor. I would actually prefer to
have NONNULL declaration on each argument in question, just like UNUSED,
but if I understand it correctly, that won't work.
> The idea of nonnull is to enable the compiler detecting possible NULL
> arguments where they must not be. E.g. char *s=NULL; strlen(s); would let the
> compiler print a warning.
I'm not entirely convinced about the usefulness of that.
> At the same time, when optimizing a function with a nonnull argument,
> gcc optimizes away checks against NULL for the appropriate variables.
I'm not entirely convinced that makes for any real improvements of
performance on real code. And I think I'd rather get a warning from the
compiler about a useless comparison (like, like gcc warns for for
unsigned x = ...; if (x >= 0)...) than having the optimizer silently
remove the code.
In particular, if I have a funtion where a pointer must not be NULL, and
I have an assert (p != NULL); to that effect, then I will *not* consider
it an improvement if the compiler decides to remove that assert.
Is there anything more useful and interesting that the compiler can do,
knowing that a pointer can't be NULL?
Sorry if I sound extremely negative. I think nonnull declarations in
header files could serve some purpose for documentation, but I doubt it
will improve performance or make it easier to find real bugs.
> Since gcc can't detect indirect NULL values, the function may crash the
> process.
I'm not sure what you mean here, but I guess it won't work well to have
the nonnull attribute propagate (say, in the same way as const). With
the following code,
int foo (const char *a, const char *b) __attribute__ ((nonnull)
{
return strcmp (a, b);
}
int bar (const char *a)
{
return foo (a, "foo");
}
should gcc issue a warning (since as far as we have told the compiler,
bar (NULL) is allowed, but that is not allowed for it's call to foo)?
Does it, or clang, issue warnings for such code?
>> 2. Since when (release and year) is it supported by gcc?
>
> I found it to be for gcc >= 3.3,
> see http://ohse.de/uwe/articles/gcc-attributes.html#func-nonnull
Released back in 2004 (http://gcc.gnu.org/releases.html). Then I guess
it shouldn't be too bad to use it unconditionally when compiling with
gcc. Or check the gcc version predefines, that's not a very big hassle.
> The reason I used nonnull were several compiler warnings. The current libc6
> header files seem to use nonnull by default (gcc 4.7.1, libc6 2.13).
Can you quote the warnings in question? I'd like to understand why it
complains.
> Maybe there should be -std=c89 in den CFLAGS to prevent that ?
That would make sense. Or at least *some* flag to issue warnings for c99
additions like C++-style comments and declarations not at the start of a
block.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH] some patches to fix compiler warnings
Tim Ruehsen writes:
> In cast128.c I removed the wiping of t, l and r. Instead I set t=0 at the
> beginning of the loops (It seemed to be used uninitialized in F1
> macro).
I don't think the wiping has any meaning. Perhaps it was intended to
somehow avoid leaking intermediate values. (I'm not the original author
of this file).
I don't understand the comment on t being used before initialized. As
far as I see, all of F1, F2 and F3 first assign t, then apply some sbox
substitutions on it. Am I missing something?
If you are addressing some compiler warnings, please, *pretty please*,
quote them accurately.
I do get several warnings (false positives) on a different function in
this file when I compile with gcc:
cast128.c: In function `nettle_cast128_set_key':
cast128.c:276:1: warning: `t[3]' may be used uninitialized in this function
[-Wmaybe-uninitialized]
cast128.c:210:26: warning: `z[3]' may be used uninitialized in this function
[-Wmaybe-uninitialized]
and a bunch more similar ones. I think I'd prefer to reorganize this
function completely, I find the current organization hard to understand.
> diff --git a/examples/eratosthenes.c b/examples/eratosthenes.c
> index 2b9d04f..0eea941 100644
> --- a/examples/eratosthenes.c
> +++ b/examples/eratosthenes.c
> @@ -399,5 +399,10 @@ main (int argc, char **argv)
> printf("%lu\n", n);
> }
> }
> +
> + /* silence static analyzers */
> + free(block);
> + free(sieve);
> +
>return EXIT_SUCCESS;
> }
Why this? It ought to be the job of the C library to free all malloced
storage after main returns. Do you get a warning for this? That sounds
overly noisy to me.
> diff --git a/examples/io.c b/examples/io.c
> index 7b2289c..cda9ed3 100644
> --- a/examples/io.c
> +++ b/examples/io.c
> @@ -125,7 +125,10 @@ read_file(const char *name, unsigned max_size, char
> **contents)
>fclose(f);
>
>/* NUL-terminate the data. */
> - buffer[done] = '\0';
> + if (buffer)
> +buffer[done] = '\0';
> + else
> +done = 0;
>*contents = buffer;
This ought not to happen. Hmm. I think the only way the execution can
omit the realloc call (and the check for NULL return value) in the loop
is if feof returns true immediately after fopen. Does you analyzer agree
with that?
Then the correct fix is to move the feof call to after fread, as
suggested in the preceding FIXME comment.
> diff --git a/examples/nettle-benchmark.c b/examples/nettle-benchmark.c
> index b76a91c..48e53d0 100644
> --- a/examples/nettle-benchmark.c
> +++ b/examples/nettle-benchmark.c
> @@ -96,7 +96,7 @@ static double frequency = 0.0;
> #define BENCH_ITERATIONS 10
> #endif
>
> -static void
> +static void NORETURN
> die(const char *format, ...)
> {
>va_list args;
Applied.
> diff --git a/tools/misc.h b/tools/misc.h
> index 70c9eeb..af55998 100644
> --- a/tools/misc.h
> +++ b/tools/misc.h
> @@ -28,19 +28,10 @@
> #endif
>
> void
> -die(const char *format, ...)
> -#if __GNUC___
> - __attribute__((__format__ (__printf__,1, 2)))
> - __attribute__((__noreturn__))
> -#endif
> - ;
> +die(const char *format, ...) PRINTF_STYLE(1,2) NORETURN;
>
> void
> -werror(const char *format, ...)
> -#if __GNUC___
> - __attribute__((__format__ (__printf__,1, 2)))
> -#endif
> - ;
> +werror(const char *format, ...) PRINTF_STYLE(1,2);
>
> void *
> xalloc(size_t size);
Applied. I found one more werror prototype, in examples/io.h, which I
improved in the same way (maybe that was in another patch of yours? I
haven't reviewed all yet).
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH] some patches to fix compiler warnings
Tim Ruehsen writes:
> diff --git a/examples/base16enc.c b/examples/base16enc.c
> index c3cb58f..3fc410e 100644
> --- a/examples/base16enc.c
> +++ b/examples/base16enc.c
> @@ -47,21 +47,6 @@
> int
> main(int argc UNUSED, char **argv UNUSED)
> {
> -
> - /* "buffer" will hold the bytes from disk: */
> - uint8_t * buffer = (uint8_t *) malloc (CHUNK_SIZE * sizeof(uint8_t));
> - if (buffer == NULL) {
> -fprintf (stderr, "Cannot allocate read buffer.\n");
> -return EXIT_FAILURE;
> - }
> -
> - /* "result" will hold bytes before output: */
> - uint8_t * result = (uint8_t *) malloc (ENCODED_SIZE * sizeof(uint8_t));
> - if (result == NULL) {
> -fprintf (stderr, "Cannot allocate write buffer.\n");
> -return EXIT_FAILURE;
> - }
> -
> #ifdef WIN32
>_setmode(0, O_BINARY);
> #endif
Applied.
Thanks,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH] some patches to fix compiler warnings
Tim Ruehsen writes:
> diff --git a/pgp-encode.c b/pgp-encode.c
> index 9a69922..f84373c 100644
> --- a/pgp-encode.c
> +++ b/pgp-encode.c
> @@ -246,7 +246,6 @@ pgp_put_rsa_sha1_signature(struct nettle_buffer *buffer,
>unsigned hash_end;
>unsigned sub_packet_start;
>uint8_t trailer[6];
> - uint8_t digest16[2];
>mpz_t s;
>
>/* Signature packet. The packet could reasonably be both smaller and
> diff --git a/rsa2openpgp.c b/rsa2openpgp.c
> index c4666f3..4c62f49 100644
> --- a/rsa2openpgp.c
> +++ b/rsa2openpgp.c
> @@ -64,7 +64,6 @@ rsa_keypair_to_openpgp(struct nettle_buffer *buffer,
>time_t now = time(NULL);
>
>unsigned key_start;
> - unsigned key_length;
>unsigned userid_start;
>
>struct sha1_ctx key_hash;
Applied.
> diff --git a/desdata.c b/desdata.c
> index fc89c2d..6671b5d 100644
> --- a/desdata.c
> +++ b/desdata.c
> @@ -62,7 +62,7 @@ int sorder[] = {
> 7, 5, 3, 1, 6, 4, 2, 0,
> };
>
> -int printf(const char *, ...);
> +int printf(const char *, ...) PRINTF_STYLE(1,2);
>
> int
> main(int argc UNUSED, char **argv UNUSED)
Changed it to include stdio.h instead.
> diff --git a/examples/io.h b/examples/io.h
> index ff4a18d..e83b7eb 100644
> --- a/examples/io.h
> +++ b/examples/io.h
> @@ -37,11 +37,7 @@ void *
> xalloc(size_t size);
>
> void
> -werror(const char *format, ...)
> -#if __GNUC___
> - __attribute__((__format__ (__printf__,1, 2)))
> -#endif
> - ;
> +werror(const char *format, ...) PRINTF_STYLE(1,2);
>
> /* If size is > 0, read at most that many bytes. If size == 0,
> * read until EOF. Allocates the buffer dynamically. */
Did this a few days ago.
> index 48e53d0..3d07868 100644
> --- a/examples/nettle-benchmark.c
> +++ b/examples/nettle-benchmark.c
> @@ -96,7 +96,7 @@ static double frequency = 0.0;
> #define BENCH_ITERATIONS 10
> #endif
>
> -static void NORETURN
> +static void NORETURN PRINTF_STYLE(1,2)
> die(const char *format, ...)
> {
>va_list args;
Applied.
Thanks,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH] some patches to fix compiler warnings
Tim Ruehsen writes:
> 5. It is just a matter of good coding style.
I'll consider adding those free calls (motivated by the "good coding
style" argument, with no comment about static analyzers).
> Are you going to say "ahhh, it is the main function - I don't need to
> call free() here." ?
Yes, I'd definitely say that. And I would expect a static analyzer to do
the same (either by default, or with some reasonable command line flag).
I have a hard time to view this as a memory leak or a problem at all.
I'm a bit curious on how you and the analyzer reason about the
following three examples.
1.
int
main (int argv, char **argv)
{
char *p = malloc (4711);
return 0;
}
2.
int
main (int argv, char **argv)
{
char *p = malloc (4711);
exit (0);
}
3.
static void
foo (void)
{
fprintf (stderr, "Failed!\n");
exit (1);
}
int
main (int argv, char **argv)
{
char *p = malloc (4711);
foo ();
free (p); /* Let's keep the main function itself "clean" */
return 0;
}
Is there any good reason to say that that in one of these cases, it's a
memory leak, while in some of the other cases, it is not?
To arrange for proper freeing before program exit in case (3) (or more
complex real programs with that pattern), one would have to add an
atexit call in main and potentially also in lots of other functions
doing allocation. That would really clutter the code, for very little
benefit.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH] some patches to fix compiler warnings
Tim Ruehsen writes: > Then you don't close files, sockets, locks etc. either just because your are > in main ? IMHO, you should change your habits... ;-) At some point, I choose to trust that the operating system and C library does its job. E.g, if I set the close-on-exec flag on some file descriptors, I don't try to close them explicitly between fork and exec. And "close-at-exit" seems like a more basic feature of the system. Then I'm aware that for output files, one ought to close them and check the return value. In particular if using FILE, since it's bad if closing fails silently due to full disks at the time buffered data is written out. But I guess one can't close the C library stdout; there, fflush is the best one can do. > As Simon Josefsson made clear, the main reason are automated tests for memory > leaks using valgrind. Something, that a library test suite should not miss. > > In nettle/run-tests just replace the line > "$1" $testflags > by > valgrind --error-exitcode=1 --leak-check=full --show-reachable=yes "$1" > $testflags > > and 'make check': > ... > = > 36 of 51 tests failed > = I see. So from this perspective, it's desirable that the code path leading to exit(EXIT_SUCCESS) frees all allocated storage. While it doesn't matter for failure exits. And one ought to run the tests both with and without valgrind, to get proper testing also for testscases where programs are expected to fail (and I guess one could also make careful use of the value of the exit code, not jsut chek thhat it's non-zero). Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH] some patches to fix compiler warnings
Simon Josefsson writes: > However, as far as I recall, the Nettle library does not contain any > calls to malloc or other memory allocating functions. So I don't think > there could be any memory leaks from the library? The publickey functions which use gmp allocate memory for the bignums (unfortunately). There may even be some leaks there in the form of missing mpz_clear, so testing for memory leaks would be useful. The functions using nettle_buffer (mainly sexp_format) may allocate, depending on how the buffer is initialized. > But if it is a small effort, and it leads to being able to > run all the testsuite under valgrind without any warnings, I would > support doing it. I don't think it's a big deal to get the testsuite to deallocate storage. Not a very high priority for me, though. I think we should also modify the use of $EMULATOR to make it easier to run with valgrind (mainly, remove quoting when it's expanded for the shell), and perhaps rename it to TESTS_ENVIRONMENT for consistency with projects using automake. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH] PKCS #5 PBKDF2
Simon Josefsson writes:
> How about adding KDFs? Here is a starting pointer for the most common
> function, PKCS #5 PBKDF2. Review appreciated.
I don't have time to review it at the moment, but I hope to be able to do
that within a few days. You may also want to have a look at
http://git.lysator.liu.se/lsh/lsh/blobs/master/src/pkcs5.c
which I wrote a long time ago. Probably not very useful for Nettle as
is, but I'll happily relicense it as LGPL if anything is derived from it.
One immediate comment: "PBKDF2" is an awful name :-/
Are there any other key derivation methods which are important?
Regards,
/Niels
> /Simon
>
> From 2fe9180d4b0afb7acb77622d541d5be21830fc7b Mon Sep 17 00:00:00 2001
> From: Simon Josefsson
> Date: Wed, 12 Sep 2012 22:05:30 +0200
> Subject: [PATCH] New PKCS #5 PBKDF2 function.
>
> ---
> ChangeLog | 14 ++
> Makefile.in|2 +
> NEWS |6 +++
> nettle-internal.h |1 +
> nettle.texinfo | 38 +++-
> pbkdf2.c | 103
>
> pbkdf2.h | 49 +
> testsuite/.gitignore |1 +
> testsuite/.test-rules.make |3 ++
> testsuite/Makefile.in |2 +-
> testsuite/meta-hash-test.c |3 ++
> testsuite/pbkdf2-test.c| 51 ++
> 12 files changed, 270 insertions(+), 3 deletions(-)
> create mode 100644 pbkdf2.c
> create mode 100644 pbkdf2.h
> create mode 100644 testsuite/pbkdf2-test.c
>
> diff --git a/ChangeLog b/ChangeLog
> index fe61ad9..a35f747 100644
> --- a/ChangeLog
> +++ b/ChangeLog
> @@ -1,3 +1,17 @@
> +2012-09-12 Simon Josefsson
> +
> + * NEWS: Mention addition of PBKDF2.
> + * pbkdf2.c (pbkdf2_hmac): New file and function.
> + * pbkdf2.h: Declare it.
> + * Makefile.in (nettle_SOURCES): Add pbkdf2.c.
> + (HEADERS): Add pbkdf2.h.
> + * testsuite/pbkdf2-test.c: New test case.
> + * nettle-internal.h (NETTLE_MAX_HASH_CONTEXT_SIZE): New constant.
> + * testsuite/meta-hash-test.c (test_main): Validate
> NETTLE_MAX_HASH_CONTEXT_SIZE.
> + * nettle.texinfo (Key derivation functions): New section.
> + * testsuite/Makefile.in (TS_NETTLE_SOURCES): Add pbkdf2-test.c.
> + * testsuite/.test-rules.make (pbkdf2-test): New target.
> +
> 2012-09-10 Niels Möller
>
> * examples/eratosthenes.c (main): Explicitly deallocate storage
> diff --git a/Makefile.in b/Makefile.in
> index cf93593..7c6cf33 100644
> --- a/Makefile.in
> +++ b/Makefile.in
> @@ -77,6 +77,7 @@ nettle_SOURCES = aes-decrypt-internal.c aes-decrypt.c \
>des3.c des-compat.c \
>hmac.c hmac-md5.c hmac-ripemd160.c hmac-sha1.c \
>hmac-sha224.c hmac-sha256.c hmac-sha384.c hmac-sha512.c \
> + pbkdf2.c \
>knuth-lfib.c \
>md2.c md2-meta.c md4.c md4-meta.c \
>md5.c md5-compress.c md5-compat.c md5-meta.c \
> @@ -123,6 +124,7 @@ HEADERS = aes.h arcfour.h arctwo.h asn1.h bignum.h
> blowfish.h \
> cbc.h ctr.h gcm.h \
> des.h des-compat.h dsa.h \
> hmac.h \
> + pbkdf2.h \
> knuth-lfib.h \
> macros.h \
> md2.h md4.h \
> diff --git a/NEWS b/NEWS
> index 4957f80..ea846a7 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -1,3 +1,9 @@
> +
> + New features:
> +
> + * Support for PKCS #5 PBKDF2. Contributed by Simon Josefsson.
> + Specification in RFC 2898 and test vectors in RFC 6070.
> +
> NEWS for the 2.5 release
>
> This release includes important portability fixes for Windows
> diff --git a/nettle-internal.h b/nettle-internal.h
> index e85e3c5..a7a37f8 100644
> --- a/nettle-internal.h
> +++ b/nettle-internal.h
> @@ -48,6 +48,7 @@ do { if (size > (sizeof(name) / sizeof(name[0]))) abort();
> } while (0)
> #define NETTLE_MAX_BIGNUM_SIZE ((NETTLE_MAX_BIGNUM_BITS + 7)/8)
> #define NETTLE_MAX_HASH_BLOCK_SIZE 128
> #define NETTLE_MAX_HASH_DIGEST_SIZE 64
> +#define NETTLE_MAX_HASH_CONTEXT_SIZE 2
> #define NETTLE_MAX_SEXP_ASSOC 17
> #define NETTLE_MAX_CIPHER_BLOCK_SIZE 32
>
> diff --git a/nettle.texinfo b/nettle.texinfo
> index 4904d91..d887ed9 100644
> --- a/nettle.texinfo
> +++ b/nettle.texinfo
> @@ -70,6 +70,7 @@ Reference
> * Cipher functions::
> * Cipher modes::
> * Keyed hash functions::
> +* Key derivation functions::
> * Public-key algorithms::
> * Randomness::
> * Ascii encoding::
> @@ -316,6 +317,7 @@ This chapter describes al
Re: Three tests can't be created
Tim Ruehsen writes: > there are three tests which cannot be build from source: > > testsuite/sexp-conv-test > testsuite/symbols-test > testsuite/pkcs1-conv-test Those test cases are shell scripts. Don't remove them. If they were removed by make clean (but doesn't happen for me, at least), that's a bug in the Makefile. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH] PKCS #5 PBKDF2
Simon Josefsson writes: > Possibly the block_count stuff could be used, although I'm not sure how > it works: if you have a large dkLen wouldn't more than the final octet > be needed? In general, one could have something larger. In lsh I use it only for encrypted private keys, and then I don't need anything larger than, say 256 bits key and 128 bits iv. > However, I'm not certain 1) it makes sense to implement several KDFs in > nettle, I imagine main use would be to decrypt alien password-encrypted data. E.g., gpg keyrings and private keys for any other tools (what is openssh using?) So any method which is used in more than one non-obscure application would make some sense to support. 2) whether an generic interface can be found. I don't think we need to worry about a generic interface now. I was more thinking about proper naming for the non-generic interface. E.g, can we say "pkcs5" rather than "pbdwhatever", or are there other methods defined in pkcs#5 (or likely to be in the future)? Naming should be reasonable now, and still not break down if we add other methods later. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Salsa20/8 and Salsa20/12
Simon Josefsson writes: > I quickly discovered that I needed the round-reduced variants of > Salsa20. Here they are. I didn't update the assembler part, so I would > need help finishing that part. Nice. Key setup is the same, just the number of iterations in the main loop is different? > +static void > +salsa20r_crypt(struct salsa20_ctx *ctx, > +int rounds, > +unsigned length, > +uint8_t *c, > +const uint8_t *m) This is the function which should be implemented in assembly. Do you think this should be a public, documented function (in which case salsa20r_crypt sounds like a reasonable name), or internal, in which case nettle convention would be something like _salsa20_crypt? > --- a/testsuite/salsa20-test.c > +++ b/testsuite/salsa20-test.c > @@ -13,13 +13,18 @@ memzero_p (const uint8_t *p, size_t n) >return 1; > } > > +typedef void (*salsa20_func) (struct salsa20_ctx *ctx, > + unsigned length, uint8_t *dst, > + const uint8_t *src); > + A very minor point... I've decided to try to stick to non-pointer typedefs for function types. I.e., typedef void salsa20_func (struct salsa20_ctx *ctx, unsigned length, uint8_t *dst, const uint8_t *src); That way, it is possible (although maybe not useful very often) to use the typedef for declaring functions, like salsa20_func salsa20_crypt; salsa20_func salsa20r8_crypt; salsa20_func salsa20r12_crypt; Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
List administrivia (was: Re: [PATCH] some patches to fix compiler warnings)
Tim Ruehsen writes: > Yesterday, I send a 170Kb patch to the list... but it did not appear. > What can/should I do ? It was held for moderation due to its size (current limit seems to be 40 KB). I just approved it. Did you get any useful reply from the list manager? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH] some patches to fix compiler warnings
Tim Ruehsen writes:
> There is just changed file outside testsuite/ and examples/ : buffer.c.
> nettle_buffer_clear() used to call realloc() with a length of 0 to wipe the
> allocated memory. But at least here it comes back with a valid pointer to one
> allocated byte (as valgrind reports). I use free() after the realloc if the
> returned pointer is not NULL (maybe realloc() should not be called at all
> !?).
This is a bit tricky. The nettle_buffer interface lets the user
configure memory allocation using a single function pointer to the
user's realloc function. It's not required to be compatible in any way
with libc free.
My man page for realloc says
realloc() changes the size of the memory block pointed to by ptr
to size bytes. [...] if size is equal to zero,
and ptr is not NULL, then the call is equivalent to free(ptr).
The spec at
http://pubs.opengroup.org/onlinepubs/9699919799/functions/realloc.html
seems to agree. But when describing the return value, it allows a valid
pointer to be returned,
If size is 0, either a null pointer or a unique pointer that can be
successfully passed to free() shall be returned.
Does that mean that the spec allows the program
int main (int argc, char **argv)
{
void *p;
while ( (p = malloc(1)) )
realloc (p, 0);
return 1;
}
to leak one byte of storage per iteration? If we need a workaround, the
right place is in the realloc wrapppers in realloc.c.
> I did not remove or add any tests, just changed / added / removed some stuff
> from testutils.c and of course within the *-test.c(xx).
I think it would have been good to discuss the aproach on list, before
doing that work.
> Niels, please remove the quotes from "$EMULATOR" in run-tests (my run-tests
> is
> somehow already in the local repo with some other changes I just can't
> revert).
I'm aware that needs fixing.
> int
> test_main(void)
> {
>/* 128 bit keys */
> - test_cipher(&nettle_aes128,
> - HL("0001020305060708 0A0B0C0D0F101112"),
> - HL("506812A45F08C889 B97F5980038B8359"),
> - H("D8F532538289EF7D 06B506A4FD5BE9C9"));
> + test_cipher(&nettle_aes128,
> + "0001020305060708 0A0B0C0D0F101112",
> + "506812A45F08C889 B97F5980038B8359",
> + "D8F532538289EF7D 06B506A4FD5BE9C9");
The reason I introduced the HL and LDATA macros was that I find it
useful that the testcases can chose either hex data or raw binary data.
A change requiring hex everywhare is not so attractive. Maybe the macros
can be fixed to arrange for deallocation (e.g, put all allocated strings
on a list and free it at the end of main). Or, of we pass only a const
char * to the various functions, include some prefix to say if it's hex
or raw data (with length; I'd prefer to not rely on strlen here).
> + unsigned key_length = decode_hex_length(key_hex);
> + const uint8_t *key = decode_hex_dup(key_hex);
> + unsigned length = decode_hex_length(cleartext_hex);
> + const uint8_t *cleartext = decode_hex_dup(cleartext_hex);
> + const uint8_t *ciphertext = decode_hex_dup(ciphertext_hex);
> +
>struct arctwo_ctx ctx;
>uint8_t *data = xalloc(length);
>
> @@ -46,6 +50,9 @@ test_arctwo(unsigned ekb,
> FAIL();
>
>free(data);
> + free((void *)ciphertext);
> + free((void *)cleartext);
> + free((void *)key);
> }
It's unfortunate that the free prototype doesn't take a const void *,
but we have to live with that. In this case, I think it's preferable to
drop const from the declaration of those pointers, so there's no need
for those explicit casts.
The less intrusive changes I'll try to get to within a few days.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH] some patches to fix compiler warnings
Tim Ruehsen writes:
> Am Friday 14 September 2012 schrieb Niels Möller:
>> If we need a workaround, the
>> right place is in the realloc wrapppers in realloc.c.
>
> We need a workaround since different libraries handle it differently.
> But simplified it is just a if (p) free(p);
I think something like this (untested) should solve the problem. We
should also document somewhere that buffer->realloc(p, 0) is expected to
free the storage completely.
--- a/realloc.c
+++ b/realloc.c
@@ -34,13 +34,25 @@
void *
nettle_realloc(void *ctx UNUSED, void *p, unsigned length)
{
+ if (length == 0)
+{
+ free (p);
+ return NULL;
+}
return realloc(p, length);
}
void *
nettle_xrealloc(void *ctx UNUSED, void *p, unsigned length)
{
- void *n = realloc(p, length);
- if (length && !n)
+ void *n;
+ if (length == 0)
+{
+ free (p);
+ return NULL;
+}
+
+ n = realloc(p, length);
+ if (!n)
{
fprintf(stderr, "Virtual memory exhausted.\n");
> You could tell which points you would like to have changed, and i'll change
> them here. After we are done, the patch could be applied in whole.
> I'll do the coding and you the review...
Thanks. Then I'd like you to try to keep the interface of the HL, H,
LDATA, LDUP macros intact, so you don't need to modify each and every
test case, but add whatever additional machinery is needed to avoid
memory leaks (linked list of allocated strings, GNU obstack, allocation
from a static area, or whatever seems suitable). For the test files, I
don't think it's a problem if we keep the allocations a bit longer than
necessary. If that approach gets too painful, we'll have to consider
some other way.
I prefer to do things in small pieces, so if I get to it before the rest
of the fixes are ready, I'll check in missing mpz_clear and similar.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Salsa20/8 and Salsa20/12
Simon Josefsson writes:
> Actually, sleeping on this, I realized that we really want to export the
> Salsa20 core primitive (this was what I actually needed), and that is
> the primitive that should be implemented in assembler. I've fixed this
> in the attached patch.
>
> The Salsa20 core is a hash function (not your typical hash function
> though) described here:
I guess it could be named salsa20_hash, then? (I think there was such a
function in a previous version of the code).
> If we implement that quickly in assembler, with a variable round
> parameter, that will be sufficient to build fast C code around.
Then you'd first write the hash output to memory, then read it back to
xor it with the message. Since sals20 is pretty fast, I think you'll get
a measurablle performance penalty compared to the currrent code which
keeps the hash output in registers until it is xored to the message. You
really need to get just the hash output, without xoring it to anything?
It would definitely be cleaner to have the hash function separately.
> +salsa20_core (uint32_t src[_SALSA20_INPUT_LENGTH],
> + uint32_t dst[_SALSA20_INPUT_LENGTH],
> + unsigned rounds)
[...]
> + for (i = 0;i < _SALSA20_INPUT_LENGTH;++i)
> +{
> + uint32_t t = x[i] + src[i];
> + dst[i] = LE_SWAP32 (t);
> +}
> +}
This makes for a very peculiar interface for a non-internal function. It
would make more sense from an interface perspectivve to either not do
these byte swaps, or have the output parameter be of type uint8_t *. Or
do something like the union gcm_block in gcm.h (although that's also not
pretty), if we want to be able to store the byte swapped value with a
word-sized store.
I don't remember precisely the background of the current implementation,
but I think the point was to do as much as possible of the processing as
word operations, including the byte swapping.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH] some patches to fix compiler warnings
Tim Ruehsen writes: > The HL and LDUP macros were really ugly and in very most cases not even > needed. They're intended as a kind of "mini-language" for the tests. I have earlier (in the lsh project, years ago) tried using m4 for the same purpose, but in the end I concluded that it was overal less trouble to just use the C preprocessor. What in particular do you find ugly? That they expand to two arguments? Short cryptic names? Something else? Wold you like them better if they expanded to some constructor calls for proper string objects olding both length and data, which were then passed to the various test helper functions? I don't care very much about the implementation of the mini-language. > But if you insist in keeping the H, HL, LDUP macros, I have to cancel my > offer, sorry. I'll do that myself then. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Salsa20/8 and Salsa20/12
Simon Josefsson writes: > Yes, although if necessary I could xor it to a zero buffer if there were > no other way... I was going to suggest using something like void salsa20_core (const uint32_t *input, unsigned rounds, unsigned length, uint8_t *dst, const uint8_t *src) which would compute the hash of the INPUT. If SRC is NULL, it would just store the LENGTH first bytes at DST. And if SRC is non-NULL, it would xor that data before storing. A bit clumsy, but reasonably general. But then I remembered that for high performance encryption, it's not sufficient with an assembly function which does only one block. You can gain a lot of performance (current code doesn't do that) by hashing two input blocks in parallel. So at the moment, I'm inclined to let the assembly function do encryption, including xoring data and incrementing the counter. And if you only need the hash, you'd need a wrapper which encrypts a zero buffer and undoes the incrementing (the assembly function could leave the input block unmodified and maintain the updated counter locally; that would be a bit extra hassle but I don't think it would impact performance). Then we have sufficient freedom for optimizing salsa20 encryption, with a small performance disadvantage for using just the hash. > however I'll loose performance, and my application > (scrypt) would benefit from good performance. Will you be hashing several independent blocks? If so, for highest perforamnce you would also neeed an interface which lets the assembly routines do several blocks in parallel. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH] some patches to fix compiler warnings
Tim Ruehsen writes:
> But after all, you still won't need them. Just have a look in the patched
> hmac-test.c, where you can find are mixtures of hex data and strings.
I haven't read the complete patch very carefully. In hmac-test.c, you
have introduced a flag argument, which is not as clumsy as I had
expected (but I prefer my preprocessor hack before your algorithm enum
and corresponding switch statement; I think it's clear that we have
somewhat different taste).
In other places, you have introduced additional functions, like
test_hash and test_hash_hex. I prefer a style which looks more like
functional programming, with a single test_hash using a canonical
representation of the input, and then the caller invokes any helper
macro or function needed to convert data from whatever form is most
convenient in the test file.
Then I happily admit that the current implementation with macros is not
very beautiful.
> /* example test function with testdata_t */
> void
> test_cipher(const struct nettle_cipher *cipher,
> testdata_t *key,
> testdata_t *cleartext,
> testdata_t *ciphertext)
> {
> // use key.length instead of key_length, etc.
> ...
>
> free(ciphertext);
> free(cleartext);
> free(key);
> }
In this model, we have a producer/consumer convention. The passed in
data is *always* malloced, to be freed by the test function. That's a
good idea, if we now consider deallocation important, that convention
will simplify things (at the cost of an unnecessary allocation in the
few cases where we now pass a string literal as the pointer).
> xmalloc should be slightly changed to not allow size 0 (either fail or
> allocated a 1 byte size).
> From my man pages:
> If size is 0, then malloc() returns either NULL, or a unique pointer value
> that can later be successfully passed to free().
I don't see the problem.
First, it is important to note that callers of xalloc are not expected
to check the return value of xalloc, it will never return NULL except
maybe when size == 0, and in that case it does *not* indicate that
allocation failed. By definition, if xalloc returned, then it did not
fail.
Noow, xalloc is sometimes called with size 0, for example if you do
decode_hex_dup(""). That's why its check for malloc failing also has to
check size. It will succeed (i.e., not abort) no matter which convention
for size == 0 which malloc follows, and simply return whatever malloc
returns.
As far as I see, it doesn't matter if malloc (and hence xalloc) returns
NULL or a valid pointer, in either case, the caller should not
dereference the pointer, and eventually pass it to on to free.
In which way do you think it fails?
Reggards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH] some patches to fix compiler warnings
Tim Ruehsen writes: > Yes, it was some hours of work, but here is a patch that releases all memory > and now runs fine with valgrind. I've now done the same, in a slightly different manner. I first tried to keep the convention that strings are passed as two arguments (length, pointer), and tried to make callers always allocate the data, and callees always free it. That turned out to be a bit inconvenient in a few places. So I rewrote it with a simple string class, and then I could just as well put all allocated strings on a linked list to be freed at the end. I'll try to clean it up and commit it soon. I just pushed two simpler fixes, not quoting $EMULATOR in run-tests, and memory leaks in the pkcs1-conv command line tool. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH] PKCS #5 PBKDF2
Simon Josefsson writes:
> Preparing an updated patch was easy, here it is and should apply to git
> master. This improves on a few minor issues compared to the old patch.
Looks solid to me.
I was at first considering if one could do it without the struct
nettle_hash abstraction, but since that is used for the hmac functions
(I think I tried without, and that turned out to be too inconvenient),
I think it makes sense to use it here as well.
--- a/nettle-internal.h
+++ b/nettle-internal.h
@@ -48,6 +48,7 @@ do { if (size > (sizeof(name) / sizeof(name[0]))) abort();
} while (0)
#define NETTLE_MAX_BIGNUM_SIZE ((NETTLE_MAX_BIGNUM_BITS + 7)/8)
#define NETTLE_MAX_HASH_BLOCK_SIZE 128
#define NETTLE_MAX_HASH_DIGEST_SIZE 64
+#define NETTLE_MAX_HASH_CONTEXT_SIZE 216
#define NETTLE_MAX_SEXP_ASSOC 17
#define NETTLE_MAX_CIPHER_BLOCK_SIZE 32
I'm a bit uncomfortable with that magic number. If sha512_ctx is the
largest one, writing sizeof(struct sha512_ctx) is clearer. Or one could
even go for sizeof(union { struct struct sha512_ctx sha512; struct
foo_ctx foo; ... }).
> +Derive symmetric key from a password according to PKCS #5 PBKDF2. The
> +PRF is the HMAC familly with @var{hash} indicating the underlying hash
s/familly/family/
> +void
> +pbkdf2_hmac (unsigned Plen, const uint8_t * P,
> + unsigned Slen, const uint8_t * S,
> + const struct nettle_hash *hash,
> + unsigned int c, unsigned dkLen, uint8_t * DK)
> +{
> + unsigned int hLen = hash->digest_size;
> + char U[NETTLE_MAX_HASH_DIGEST_SIZE];
> + char T[NETTLE_MAX_HASH_DIGEST_SIZE];
[...]
> + TMP_DECL (inner, uint8_t, NETTLE_MAX_HASH_CONTEXT_SIZE);
> + TMP_DECL (outer, uint8_t, NETTLE_MAX_HASH_CONTEXT_SIZE);
> + TMP_DECL (state, uint8_t, NETTLE_MAX_HASH_CONTEXT_SIZE);
Any good reason to allocate the digests and the contexts in different
ways? (One issue with the current hash and hmac interfaces is that all
three of inner, outer and state include a buffer, while we really need
only one).
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH] PKCS #5 PBKDF2
Simon Josefsson writes: > Did you notice that testsuite/meta-hash-test.c was modified as well to > make sure the magic number is OK? Yes, that's good, but I'd still prefer to have it defined in terms of sizeof. > A sizeof or sizeof-union could work > too, but then nettle-internal.h would need more #include's. Since it's for internal use only, I don't think that's a problem. And including sha.h should be sufficient I guess? (I still haven't checked, but I would think sha512_ctx is the largest one). >>> + TMP_DECL (inner, uint8_t, NETTLE_MAX_HASH_CONTEXT_SIZE); >>> + TMP_DECL (outer, uint8_t, NETTLE_MAX_HASH_CONTEXT_SIZE); >>> + TMP_DECL (state, uint8_t, NETTLE_MAX_HASH_CONTEXT_SIZE); [...] > Ah, no reason really. I wrote the inner/outer/state part later, after > settling on the nettle_hash abstraction, so this was code inspired by > hmac.c. I found the hmac interface a bit odd here, so there may be > better ways to do this. Hmm. I don't think using TMP_DECL like that is right. If HAVE_ALLOCA, then it's going to be a plain alloca, which is what we really want. The problem is the fallback case, when we don't use allloca. Then it expands to uint8_t inner[NETTLE_MAX_HASH_CONTEXT_SIZE]; which may not be properly aligned. We shouldn't use malloc here, so if we can't think up something completely different, I think nettle-internal.h needs to define some union type which makes the C compiler to provide sufficient space and proper alignment. Somewhat like sockaddr_storage. And the hmac code uses TMP_DECL/TMP_ALLOC for input blocks and digests, not for the context structs. (Maybe it should be designed differently? I'll send a separate reply on that). Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH] PKCS #5 PBKDF2
Simon Josefsson writes: > +void > +pbkdf2_hmac (unsigned Plen, const uint8_t * P, > + unsigned Slen, const uint8_t * S, > + const struct nettle_hash *hash, > + unsigned int c, unsigned dkLen, uint8_t * DK); Maybe it would make more sense for pbkdf2 to use an arbitrary mac? The caller would provide the mac an dinitialize it with the password. And then the pbkdf2 functions takes the mac, the salt, count, and generates the key. Like void pbkdf2 (void *mac_ctx, unsigned digest_size, nettle_hash_update_func *update, nettle_hash_digest_func *digest, unsigned length, uint8_t *dst, unsigned iterations, unsigned salt_length, const uint8_t *salt); Example usage: hmac_sha1_ctx ctx; uint8_t key[57]; hmac_sha1_set_key (&ctx, 8, "password"); pbkdf2 (&ctx, SHA1_DIGEST_SIZE, hmac_sha1_update, hmac_sha1_digest, sizeof(key), key, 4711, 6, "pepper"); Would that make sense? I guess one may also want some convenience macros/functions for using hmac-sha1 etc. I think that design would even make the implementation more natural. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH] PKCS #5 PBKDF2
And a couple of comments on the implementation.
Simon Josefsson writes:
> + for (i = 1; i <= l; i++)
> +{
> + memset (T, 0, hLen);
> +
> + for (u = 1; u <= c; u++)
> + {
> + hmac_set_key (outer, inner, state, hash, Plen, P);
> +
> + if (u == 1)
> + {
> + tmp[0] = (i & 0xff00) >> 24;
> + tmp[1] = (i & 0x00ff) >> 16;
> + tmp[2] = (i & 0xff00) >> 8;
> + tmp[3] = (i & 0x00ff) >> 0;
> +
> + hmac_update (state, hash, Slen, S);
> + hmac_update (state, hash, 4, tmp);
> + }
> + else
> + {
> + hmac_set_key (outer, inner, state, hash, Plen, P);
> + hmac_update (state, hash, hLen, U);
> + }
> +
> + hmac_digest (outer, inner, state, hash, hLen, U);
There's no need for all those hmac_set_key. You can set it once, and
compute several macs usign the same key, each with a sequence of update,
update, ..., update, digest.
If documentation or implementation doesn't agree, patches are appreciated.
> + for (k = 0; k < hLen; k++)
> + T[k] ^= U[k];
> + }
And that's what memxor is for ;-)
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH] PKCS #5 PBKDF2
Simon Josefsson writes: > This feels a bit inconsistent with the hmac interface, Anything in particular which you think is inconsistent? HMAC is a bit special both in theory and practice. In that it isn't defined on top of any arbitrary hash function, it's defined only for hash functions in the Merkle-Damgård family (if I get the terminology right), and needs to know the underlying blocksize, which is usually considered an internal property of the hash function. And then nettle's hmac_update and hmac_digest are a bit peculiar, since they avoid using types from HMAC_CTX, and use const for the two contexts which depend on the key only. PBDKF2 is a more regular construction, which doesn't depend on the internals of the underlying mac/prf. > Do you want me to submit an updated patch? It would be great if you could try out the proposed interface. And if it works out well, submit a new patch. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH] PKCS #5 PBKDF2
Simon Josefsson writes:
> ni...@lysator.liu.se (Niels Möller) writes:
> That the HMAC interface takes this parameter:
>
>const struct nettle_hash *hash
>
> but the new PBKDF2 interface would take these:
>
>void *mac_ctx,
>unsigned digest_size,
>nettle_hash_update_func *update,
>nettle_hash_digest_func *digest
>
> which feels low-level, especially considering that those parameters are
> captured through the nettle_hash abstraction together with hard-coding
> PBKDF2 for HMAC.
The "low-level" interface is the preferred style in Nettle. See
cbc_encrypt/cbc_decrypt for other examples. It's intended that the
nettle_hash abstraction should be optional, and not used internally. But
then it's used with hmac anyway, iirc that's because the alternative
interface got *too* clumsy.
> However, I suppose this complexity could be hidden with a utility
> function 'pbkdf2_hmac' that is similar to my original function
> signature.
Do you think a "half-general" pbkdf2_hmac function really is useful? I
think specific wrapper functions, pbkdf2_hmac_sha256, etc, would be more
useful.
> pbkdf2-test.c:27:3: warning: passing argument 3 of 'nettle_pbkdf2' from
> incompatible pointer type [enabled by default]
> ../pbkdf2.h:40:1: note: expected 'void (*)(void *, unsigned int, const
> uint8_t *)' but argument is of type 'void (*)(struct hmac_sha1_ctx *,
> unsigned int, const uint8_t *)'
>
> The reason is that pbkdf2 has this signature:
> typedef void nettle_hash_update_func(void *ctx,
>unsigned length,
>const uint8_t *src);
>
> which is not compatible with any instantiation like this one:
>
> void
> sha1_update(struct sha1_ctx *ctx,
> unsigned length,
> const uint8_t *data);
This is a problem shared with almost every function in nettle accepting
function pointer arguments. I think we have to live with casts one way
or the other; I don't see any good solution.
> Casting the parameter would solve this. Is there any other way to
> resolve the warning? Do you think casting is an acceptable solution
> here? The problem seems to be that the casting needs to happen in the
> application not in the library.
At least specific functions like pbkdf2_hmac_sha256 functions will not
expose the problem to users. It's also possible to write some macros to
do the cast but preserve some type checking, something like
#define PBKDF2(ctx, update, digest, ...) \
(0 ? (update(ctx, 0, NULL), digest(ctx, 0, NULL)) \
: pbkdf(ctx, (nettle_hash_update_func *) update, (nettle_hash_digest_func
*) digest, ..,))
The CBC_ENCRYPT and CBC_DECRYPT macros do this, and it seems to work
fine, but it's not particularly pretty.
Any other ideas?
Thanks for the implementation, I'll try to get it integrated soon. Some
minor comments (which I can fix):
> --- a/nettle-internal.h
> +++ b/nettle-internal.h
> @@ -48,6 +48,7 @@ do { if (size > (sizeof(name) / sizeof(name[0]))) abort();
> } while (0)
> #define NETTLE_MAX_BIGNUM_SIZE ((NETTLE_MAX_BIGNUM_BITS + 7)/8)
> #define NETTLE_MAX_HASH_BLOCK_SIZE 128
> #define NETTLE_MAX_HASH_DIGEST_SIZE 64
> +#define NETTLE_MAX_HASH_CONTEXT_SIZE 216
> #define NETTLE_MAX_SEXP_ASSOC 17
> #define NETTLE_MAX_CIPHER_BLOCK_SIZE 32
This is no longer needed, right?
> +void
> +pbkdf2 (void *mac_ctx, unsigned digest_size,
> + nettle_hash_update_func *update,
> + nettle_hash_digest_func *digest,
> + unsigned length, uint8_t *dst,
> + unsigned iterations,
> + unsigned salt_length, const uint8_t *salt)
> +{
> + char U[NETTLE_MAX_HASH_DIGEST_SIZE];
> + char T[NETTLE_MAX_HASH_DIGEST_SIZE];
It would make sense to use TMP_ALLOC for those. And I think I'd use uint8_t
rather than char (unless there's some reason for char I'm missing?).
> + tmp[0] = (i & 0xff00) >> 24;
> + tmp[1] = (i & 0x00ff) >> 16;
> + tmp[2] = (i & 0xff00) >> 8;
> + tmp[3] = (i & 0x00ff) >> 0;
There's WRITE_UINT32 for this.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH] PKCS #5 PBKDF2
Simon Josefsson writes: > I can submit an updated patch if that would speed things up. Recall > that the ChangeLog, manual etc was not updated for the new interface in > my most recent patch, so there is some cleaning up to do. If you can make an updated patch for manual and ChangeLog, that'd be great. I'll take care of the code. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH] some patches to fix compiler warnings
Tim Ruehsen writes: > There are just two little things left open: > * added mpz_clear in rsa-encrypt.c > * added nettle_buffer_clear, rsa_private_key_clear and free in rsa-keygen.c Thanks. Applied. /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH] PKCS #5 PBKDF2
Simon Josefsson writes:
> ni...@lysator.liu.se (Niels Möller) writes:
>> If you can make an updated patch for manual and ChangeLog, that'd be
>> great. I'll take care of the code.
>
> Here it is.
Thanks. Checked in now. Hope I got all the pieces. I also added a PBKDF2
macro with the casting tricks.
And a pbkdf2_hmac_sha1 function can now be implemented as follows:
void
pbkdf2_hmac_sha1 (unsigned key_length, const uint8_t *key,
unsigned length, uint8_t *dst,
unsigned iterations,
unsigned salt_length, const uint8_t *salt)
{
struct hmac_sha1_ctx ctx;
hmac_sha1_set_key (&ctx, key_length, key);
PBKDF2 (&ctx, SHA1_DIGEST_SIZE, hmac_sha1_update, hmac_sha1_digest,
length, dst, iterations, salt_length, salt);
}
Any final interface tweaks? Is the order of the arguments sensible and
consistent with other nettle interfaces? I.e., currently
void
pbkdf2 (void *mac_ctx, unsigned digest_size,
nettle_hash_update_func *update,
nettle_hash_digest_func *digest,
unsigned length, uint8_t *dst,
unsigned iterations,
unsigned salt_length, const uint8_t *salt);
Hmm, looking at cbc_encrypt/cbc_decrypt, it might be more consistent to
(1) put digest_size after the function pointers, and (2) put the length,
dst arguments last (this depends a bit on whether or not one wants to
think of the salt as an src input or as some auxillary "parameter". At
east the iteration count should go earlier in the list. So maybe
void
pbkdf2 (void *mac_ctx,
nettle_hash_update_func *update,
nettle_hash_digest_func *digest,
unsigned digest_size,
unsigned iterations,
unsigned salt_length, const uint8_t *salt,
unsigned length, uint8_t *dst);
What do you think? This *is* nit-picking, but interface consistency is
important and this is the right time to tweak it.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH] PKCS #5 PBKDF2
Simon Josefsson writes: > ni...@lysator.liu.se (Niels Möller) writes: >> Thanks. Checked in now. Hope I got all the pieces. Turned out I forgot to commit your test case. Fixed now. I've also done the suggested reordering of the arguments (including the prototype in the manual). > Could you add that, or should I submit a patch? A patch including tests and documentation would be very nice. Your prototype looks right to me, >void >pbkdf2_hmac_sha1 (unsigned key_length, const uint8_t *key, > unsigned iterations, > unsigned salt_length, const uint8_t *salt, > unsigned length, uint8_t *dst) The declarations can go i pbkdf2.h, with implementation in separate source files pkbdf2-hmac-sha1.c and -sha256.c. And I can now almost write "pbkdf2" correctly without thinking. Scary... ;-) Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH] PKCS #5 PBKDF2
Simon Josefsson writes: > See patch below. I also improved the manual a bit. Thanks! Committed now. > --- a/pbkdf2.h > +++ b/pbkdf2.h > @@ -35,6 +35,8 @@ extern "C" > > /* Namespace mangling */ > #define pbkdf2 nettle_pbkdf2 > +#define pbkdf2_hmac_sha1 nettle_pbkdf2_sha1 > +#define pbkdf2_hmac_sha256 nettle_pbkdf2_sha256 I changed the symbols to nettle_pbkdf2_hmac_sha1 and nettle_pbkdf2_hmac_sha256. I take it the abbreviation was unintentional? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: [PATCH] PKCS #5 PBKDF2
Simon Josefsson writes: > I'll proceed cleaning up the Salsa code next, to reach my goal of having > scrypt in here as well (I have it working on > <https://www.gitorious.org/scrypt/nettle-scrypt>). That's the algorihtm described in https://tools.ietf.org/html/draft-josefsson-scrypt-kdf-00, right? What features do you need for the salsa interface? After a quick look, it seems you will not be processing independent blocks with salsa20, so you will not be able to take any advantage of parallelism there (which I imagine is an intended feature of scrypt). It's straight forward to add a round parameter to salsa20. But it's still not clear to me what's the best way to support hashing only. It would have been a bit easier if you could replace X = Salsa(X xor B[i]) by X = Salsa(X) xor B[i] since the latter is closer to the standard encryption operation. I think the iteration *can* be rewritten in that form by some change of variables, but you'd need an extra xor at the end to really get Y[i] rather than Y[i] xor B[i]. The algorithm specification is already set in stone? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Salsa20 core
Simon Josefsson writes: > I realized that I didn't have any use for the round-reduced Salsa20 > stream functions. So I'll focus on what I needed instead, which > resulted in a much smaller patch. What do you think? Looks reasonable to me. > Open issues: > > * I'm not particular happy about the name SALSA20_CORE_INOUT_SIZE. Just use SALSA20_BLOCK_SIZE. It's the same thing, right? > * Where could this be documented in the manual? "Miscellaneous > functions"? We could also create a new section "Non-cryptographic > Hash functions". I think it would make sense to put it in the salsa section, possibly with a reference from the section on hash functions and any other place where it may be relevant. As I understand it, it *is* like a cryptographic function, but with a fixed input size. What about assembly implementation? Do you think that is desirable? I think it should be fairly easy. Start with x86_64/salsa20-crypt.asm, move the QROUND macro to some other file (and maybe define some additional macros for shared code). And write a new salsa20-core.asm, which can be pretty simple, in particular, it doesn't need the complex code for handling partial blocks. > +void > +salsa20_core (unsigned rounds, > + uint8_t dst[SALSA20_CORE_INOUT_SIZE], > + const uint8_t src[SALSA20_CORE_INOUT_SIZE]) You settled on uint8_t input, rather than uint32_t? IIRC, the corresponding function in the salsa20 paper is defined with uint32_t array as input and an uint8_t array as output. I guess little endian byte order of the input (matching the byte order for the output) is the only sensible choice? This ought to be clearly documented somewhere. In nettle I currently don't use array types for function arguments. If you write them as arrays, like you do here, do current compilers make any use that for bounds checking, or do you just think it's clearer for humans? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Salsa20 core
Simon Josefsson writes: > No, it is not a cryptographic hash function since it is not > collision-resistant. Think of it as CRC or FNV. I'd like to understand better the properties of Salsa. As I see it, we have a complicated non-linear, but easily invertible, permutation on blocks of 64 bytes (or 512 bits). Call this function P(X). Then we construct a hash function F(X) = X xor P(X) The XOR is intended to destroy invertibility both in theory (it's no longer a one-to-one map, or a permutation) and practice (given F(X), it's hard to find a preimage). Am I right so far, or is there some working trick or attack which finds a preimage? But then I have no idea on the number and structure of the collisions, and on the difficulty of finding a pair of colliding inputs X != Y, F(X) = F(Y). > Right. I considered it, as a way to learn to assembler stuff in Nettle. > However, I'm not sure there is a lot to gain, since there is no loop > unrolling to speak off. For salsa20 and x86_64, the main gain comes from using sse2 instructions to exploit the parallelism in the QROUND function. > However, the Salsa20 stream cipher seems to use the core function with > uint32_t inputs, Well, it does use little endian explicitly, when copying key material into the salsa core input. > and scrypt does too. Reading the internet draft, it looks like it treats input and output as 64 bytes. I haven't read any other scrypt materials. > It seems scrypt doesn't little endian convert inputs but expects the > output uint32_t to be little endian converted though... I'll bring > this up with Colin. Please do, this needs to be sorted out. >> In nettle I currently don't use array types for function arguments. > I've always regarded it as something intended for humans. I'm not sure > what a compiler could do with the information. Perhaps it could be > useful for optimizations though. I tend to use pointer notation, because (1) it's what really happens, (2) it's shorter to write, and (3) because arrays may give a casual reader the impression that something more complicated happens. Neither is a very good reason, but for now I think we should stick to pointers for consistency within Nettle. If arrays notation is better, we should change that in all places where we pass arrays of constant size. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Salsa20 core
Simon Josefsson writes: > Do you think a uint32_t->uint32_t interface would be acceptable? If that's what is really needed for scrypt (the only application so far), and it lets you avoid converting back and forth between bytes and uint32_t, then it seems like the right thing to do. We may add a function with uint8_t (and little endian convention, I guess) later if the need arises. So we should take that possibility into account when naming the function. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Salsa20 core
Simon Josefsson writes:
>> I'd like to understand better the properties of Salsa. As I see it, we
>> have a complicated non-linear, but easily invertible, permutation on
>> blocks of 64 bytes (or 512 bits). Call this function P(X). Then we
>> construct a hash function
>>
>> F(X) = X xor P(X)
>
> There is no XOR in the Salsa20 core?
Sorry, the final operation is addition (applied independently to 32 bit
pieces), not xor. But structure is the same, P(X) represents the QROUND
loop, where each step is invertible, and then at the end we add together
the output of the QROUNDs and the original input. Collisions are
introduced in the final addition, in the sense that we have
P(x) == P(y) if and only if x = y
but F(x) = F(y) is possible for x != y. A collision means that
P(x) xor x == P(y) xor y
which can be rearrange, since P is invertible, as
x = P^{-1}(x xor y xor P(y)
Examples of such colliding pairs seem non-trivial to find (difficulty
increasing wth the number of rounds).
You write that the function is not collision resistant. I'd like to know
in which way it fails (ideally with either a simple argument, or a
reference).
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Salsa20 core
Simon Josefsson writes: > So you don't think we should implement the uint8_t interface now? I > think there is little cost in doing that directly, and allows us to > directly use the only test vectors that I'm aware of. I don't have a strong opinion. If it helps testing, and we are confident that it should be little-endian, let's add it. > What's a good name? Is there any precedent for something like this in > Nettle? If we look at internal building blocks, there are a couple of examples: gcm_hash, and sha1_compress (and similar compression functions for other hashes). Neither of those are advertised/documented. I think it would make sense to call the uint32_t function salsa_core, and the uint8_t function salsa_hash. We'll see if we can sort out what properties it really has, but it definitely has important similarities to a hash function. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Salsa20 core
Simon Josefsson writes: > See also: > > https://groups.google.com/forum/?fromgroups=#!msg/sci.crypt/AkQnSoO40BA/o4eG96rjkgYJ > http://cr.yp.to/snuffle/reoncore-20080224.pdf Thanks for the references. I'm now convinced we should avoid using the word "hash" here. I should revise the corresponding section of the Nettle manual as well. Which leaves us with an unsolved naming problem... I don't quite like salsa_core and salsa_core32, but I have no better suggestions right now. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
