jedisct1 / libsodium

A modern, portable, easy to use crypto library.

Sodium is an easy-to-use software library for encryption, decryption, signatures, password hashing, and more.

It is a portable, cross-compilable, installable, packageable fork of NaCl, with a compatible API, and an extended API to improve usability even further.

Its goal is to provide all of the core operations needed to build higher-level cryptographic tools.

Sodium supports a variety of compilers and operating systems, including Windows (with MingW or Visual Studio, x86 and x64), iOS, Android, as well as Javascript and Webassembly.

Documentation

The documentation is available on Gitbook and built from the libsodium-doc repository:

• libsodium documentation - online, requires Javascript.

Integrity Checking

The integrity checking instructions (including the signing key for libsodium) are available in the installation section of the documentation.

Community

A mailing-list is available to discuss libsodium.

In order to join, just send a random mail to sodium-subscribe {at} pureftpd {dot} org.

Contributors

Code Contributors

This project exists thanks to all the people who contribute. [Contribute].

Financial Contributors

Become a financial contributor and help us sustain our community. [Contribute]

Individuals

Organizations

Support this project with your organization. Your logo will show up here with a link to your website. [Contribute]

License

ISC license.

libsodium's Issues

Floodyberry's Poly1305

You should consider adding some of Floodyberry's Poly1305 implementations. They're significantly faster than ref, but don't need those weird floating point techniques.

https://github.com/floodyberry/poly1305-donna

In particular poly1305-donna-unrolled.c only needs standard 32 and 64 bit integers. poly1305-donna-c64-unrolled needs 128 bit ints, but since you're already using those for Ed25519 it might still be useful for 64 bit builds.

It also includes some really fast SSE implementations, but those aren't easily portable.

Issue with Poly1305-Donna on iOS

I encounter some issues on iOS (on device) when using the new Poly1305 implementation crypto_onetimeauth_poly1305_donna_implementation in conjunction with NSData.

In some cases, but not for every calls, when I use the secret box functions with NSData arguments I get a EXC_BAD_ACCESS (SIGBUS), EXC_ARM_DA_ALIGN.

Below is an example of call I make, which in some cases trigger this error:

NSMutableData *data = [NSMutableData dataWithLength:[encryptedData length] - crypto_secretbox_noncebytes()];
// encryptedData and key are NSData objects
ret = crypto_secretbox_open([data mutableBytes],
                              [encryptedData bytes] + crypto_secretbox_noncebytes(),
                              [encryptedData length] - crypto_secretbox_noncebytes(),
                              [encryptedData bytes],
                              [key bytes]);
// The error is triggered when encryptedData is accessed in crypto_onetimeauth_poly1305_donna() 

However, when I set crypto_onetimeauth_poly1305_53_implementation as default implementation at runtime I don't have this issue anymore (as before).

I'd like to help more but it seems difficult to track it down. Maybe it's due to the NSData implementation, I don't know, I don't really have tested with non-NSData arguments.

Zero-copy crypto_sign and crypto_sign_open

Currently the crypto_sign function prepends the signature to the message though this is undocumented and hence I'm not sure whether I can rely on this to remain the same.

Secondly the crypto_sign and crypto_sign_open functions copy the message to and from the signed message though I see no reason this has to happen. Could they be implemented as:

 const unsigned char sk[crypto_sign_SECRETKEYBYTES];
 const unsigned char m[...]; unsigned long long mlen;
 unsigned char s[crypto_sign_BYTES];

 bool crypto_sign(s, m, mlen, sk);

where s contains the signature if successful and

 const unsigned char pk[crypto_sign_PUBLICKEYBYTES];
 const unsigned char m[...]; unsigned long long mlen;
 unsigned char s[crypto_sign_BYTES];

 bool crypto_sign_open(m, mlen, s, pk);

to verify this signature? This will give a bit more flexibility as to there to store the signature and at the same time prevent a copy.

The reason I care about this is because I'm working on a certificate authority setup based around libsodium. The public key to verify a Certificate Signing Request is within the request itself thus I need to know the layout of the signed message.

Windows: Set a value for CROSS_COMPILING during configure

Hello,

Seems that configure.ac checks for $cross_compiling and performs an Autoconf define, yet no value is provided:

AS_IF([test "$cross_compiling" != no],
  AC_DEFINE(CROSS_COMPILING,,[define if you are cross-compiling])
)

This produces some noise to DEFS: -DCROSS_COMPILING=/\*\*/

A simple change:

diff --git a/configure.ac b/configure.ac
index 15628df..a89d362 100644
--- a/configure.ac
+++ b/configure.ac
@@ -33,7 +33,7 @@ AC_USE_SYSTEM_EXTENSIONS
 CPPFLAGS="$CPPFLAGS -D_FORTIFY_SOURCE=2"

 AS_IF([test "$cross_compiling" != no],
-  AC_DEFINE(CROSS_COMPILING,,[define if you are cross-compiling])
+  AC_DEFINE(CROSS_COMPILING,[1],[define if you are cross-compiling])
 )

 AX_CHECK_COMPILE_FLAG([-fPIC], [

Will produce a cleaner define: -DCROSS_COMPILING=1

Thank you

❤️ ❤️ ❤️

Build 32bit version on Mac OSX with Brew?

How would I build a 32bit version on Mac OSX with Brew?
Or a 32bit & 64bit universal version on Mac OSX with Brew?

Thanks

Can't install .deb (The package is of bad quality)

I downloaded http://download.dnscrypt.org/libsodium/releases/libsodium_0.3+fpm0_amd64.deb and tried installing on Ubuntu 12.10. Software Center gave me that error message.

Clang Static Analyzer results

I've run the Clang Static Analyzer (http://clang-analyzer.llvm.org) on libsodium and the results can be found here: http://vexocide.org/scan-build-2013-07-05-1.

Colour me impressed by the cleanliness of the code, but it did uncover two things which might warrant closer inspection.

Expose crypto constants through function calls

Currently, many of the constants used throughout this code are only available as #define. This is okay for C code, but means that constants have to be manually transcribed for an FFI interface. It would be helpful if there were some function(s) that could be called to retrieve this information.

This came up in RubyCrypto/rbnacl#49

"Use /dev/random instead of /dev/urandom"

I noticed something mildly disturbing in the configure help, which led me to think that /dev/urandom is used to generate encryption keys. If "--enable-blocking-random" is not specified, then the "randombytes" function will always use the output from /dev/urandom. /dev/urandom is not supposed to be used for encryption keys, and I think that's one thing which caused the fiasco with Debian where libssl traffic could be retroactively brute forced.

In libsodium/crypto_box/curve25519xsalsa20poly1305/ref/keypair_curve25519xsalsa20poly1305.c for instance... crypto_box_keypair calls randombytes to initialize a secret key. In the case of using /dev/urandom for that, wouldn't that make using that crypto box susceptible to attacks that target the low(er) randomness of /dev/urandom?

I don't know much about encryption. I may be blowing it out of proportion. Is that curve25519 not used for long lived keys? I sure couldn't figure out how to reverse engineer a key generated with /dev/urandom. I wanted to bring attention to it because I would like to know whether I should specify --enable-blocking-random so that my keys are not guessable, or to not specify it so that my program isn't slamming to a halt when /dev/random blocks?

Bug in crypto_box_open_afternm

return crypto_box_curve25519xsalsa20poly1305_open_afternm(m, c, clen, m, k);
in crypto_box_open_afternm should be:
return crypto_box_curve25519xsalsa20poly1305_open_afternm(m, c, clen, n, k);

File not tagged

In the release tarball, README said:

See README.markdown

But no such file included in the release tarball.

Please fix.

Thanks.

from git to tarball

Hi,
im currently working on a debian package, and i want to not only make debianization but git-buildpackage configuration as well. because of that, i wanted to ask how do you generate (per script i assume?) a tarball from your git?
secondly i wanted to know, how one can define a certain architecture for the buildprocess (i386, i586, i686, x86_64, amd64, powerpc?)

I already have some debian packages, but i just want to solve these issues before i release them.

thanks,
deknos

documentation?

There is no documentation whatsoever?

Using the .sig file to verify the download

Hi,

I think it would be a good idea to give instuctions on verifying the download, especially since when I did it using gpg --verify libsodium-0.2.tar.gz.sig libsodium-0.2.tar.gz I end up with

gpg: BAD signature from "Jedi/Sector One [email protected]"

Whatever happened to md5? ;)

Regards,
yb

Using/not using SHA256

In the most cases the code uses SHA512.
However the code randombytes_salsa20_random.c uses SHA256.
Is it possible to change it to SHA512/256 (I don't know enough for this about the cryptography)?
In that case I could throw out SHA256 for smaller implementation. :)

Initialization design

This is a follow up to the the initialization discussion in the Support assembly ed25519 with Python extensions issue.

1. I don't like reinit.

   Forks should only affect the rng and it should detect it automatically (check process id or something).

   Having to call this adds complexity and doesn't interact well with modular applications. The part doing the forking probably doesn't even know there is such thing as libsodium.

2. I don't like shutdown

   Shutdown essentially can't be called in a modular application and I don't see when it'd be useful. Just leave it to the OS to free the memory when the process terminates.

3. Current implementation of init is not threadsafe. The flag is set before the initialization completes. So on a second thread init can return before initialization is complete. BOOM.

   Just take a normal lock at the beginning of the init function and release it at the end.

   If you really want you can use a double checked lock, but getting it right is tricky. There are subtle issues related to the memory model.

Nevermind

It's my stupid mistake, I mean dnscrypt-proxy Issue.

Integrate aes128ctr, aes192ctr, and aes256ctr from SUPERCOP

One of the biggest complaints I've heard about NaCl is that it doesn't support anything but crypto djb invented himself (well, except for SHA* and HMAC).

Having djb's implementation of AES would definitely be a killer app for libsodium. Actually shipping the ASM would be super too, but seems hard! ;)

"Clean" way to get the public key from a secret key

So the Curve25519 implementation has a "seed" which it uses as a secret key, and then it runs crypto_scalarmult_curve25519_base on that to get the public key. It would be great if this was exposed using a nicer name like crypto_box_public_key_from_secret_key() or something.

Contribution of Reference Documentation

Currently, there appears to be no reference documentation for the API contained within Sodium. For another activity, I spent some time generating a 'documented' header (using Doxygen) for the API. The results can be found in the following gist: https://gist.github.com/jfdm/5255788

I wish to contribute the documentation to the libsodium project, yet I am unsure as to how best the documentation should be integrated without stepping on peoples toes. That is: I can integrate the documentation within the header files in include; provide a doc folder with the documentation separate from the header files; or have a separate project for this.

Do you guys have a preference?

Constants for Curve25519 ScalarMult are not exposed via API

That more or less sums it up. I'll work on a patch if this isn't fixed soon, hopefully.

Fail to export version routines in libsodium-0.4

A minor nit. version.h should be:

ifndef SODIUM_VERSION_H

define SODIUM_VERSION_H

include "export.h"

define SODIUM_VERSION_STRING "0.4"

define SODIUM_LIBRARY_VERSION_MAJOR 4

define SODIUM_LIBRARY_VERSION_MINOR 0

ifdef __cplusplus

extern "C" {

endif

SODIUM_EXPORT
const char *sodium_version_string(void);
SODIUM_EXPORT
int sodium_library_version_major(void);
SODIUM_EXPORT
int sodium_library_version_minor(void);

ifdef __cplusplus

}

endif

endif

Support assembly ed25519 with Python extensions

We're using ed25519 for BitTorrent live - live.bittorrent.com and about half of our CPU usage is currently going towards ed25519. Pretty please support assembly ed25510 with Python extensions, so we can support low end devices reasonably.

make libsodium binary-callable

There's a lot of interest in creating a Julia package wrapping libsodium, but the use of C macros in the libsodium API means that there's isn't actually a usable ABI for the library, only a C source-level API. Since Julia prefers to call external code using an ABI without any C wrapper code at all, this makes calling libsodium from Julia more awkward that necessary. See this discussion for further details. It seems like having an actual ABI rather than requiring C wrappers would be in line with the goals of libsodium to be easily callable from everywhere (e.g. Java, Fortran). Julia and libsodium also discussed here.

Building for Windows: undefined reference to `__stack_chk_fail'

I'm not sure what the ideal setup is for this, but when trying Cygwin, MSYS, and cross compiling from Xubuntu using mingw32 (at the point of running "make"), I get these errors

undefined reference to `__stack_chk_fail'
undefined reference to `__stack_chk_guard'

in an inumerable amount of places. I checked some of the lines and it appears to happen at every beginning or ending brace of any function. This only occurs when trying to build on or for Windows; OSX, Xubuntu, MineOS Crux, and Arch all built perfectly.

Sorry about this if this isn't the method for building for Windows. I can post a full log if necessary but it is really long (>1000 lines) and redundant so I omitted it in the OP.

Windows: -fPIC is added even platform is position independent

Hello,

While attempting to cross-compile libsodium to Windows (from OSX using mingw-w64 GCC 4.5.4), I've encountered several warnings during compilation:

Making all in include
make[3]: Nothing to be done for `all'.
  CC       libsodium_la-core_hsalsa20.lo
crypto_core/hsalsa20/ref2/core_hsalsa20.c:1:0: warning: -fPIC ignored for target (all code is position independent)
  CC       libsodium_la-core_salsa20.lo
crypto_core/salsa20/ref/core_salsa20.c:1:0: warning: -fPIC ignored for target (all code is position independent)
  CC       libsodium_la-core_salsa2012.lo
crypto_core/salsa2012/ref/core_salsa2012.c:1:0: warning: -fPIC ignored for target (all code is position independent)
  CC       libsodium_la-core_salsa208.lo
crypto_core/salsa208/ref/core_salsa208.c:1:0: warning: -fPIC ignored for target (all code is position independent)

Perhaps -fPIC check done in configure.ac can evaluate the platform being targeted?

Environment information:

$ uname -v
Darwin Kernel Version 12.2.1: Thu Oct 18 12:13:47 PDT 2012; root:xnu-2050.20.9~1/RELEASE_X86_64

$ i686-w64-mingw32-gcc --version
i686-w64-mingw32-gcc (GCC) 4.5.4 20110822 (prerelease)

Cross-compiler was obtained from mingw-w64 project.

Thank you

❤️ ❤️ ❤️

Problems building 0.4.3 on OS X under homebrew

I'm trying to update the homebrew formula to 0.4.3 and running into the following errors. It only occurs when building under homebrew :( Running ./configure; make check on the extracted tarball by hand works just dandy! Argh!

  CC       crypto_onetimeauth/poly1305/donna/libsodium_la-verify_poly1305_donna.lo
  CC       crypto_scalarmult/libsodium_la-crypto_scalarmult.lo
brew: superenv removed: -g -O2 -Winit-self -Wwrite-strings -Wdiv-by-zero -Wsometimes-uninitialized
brew: superenv removed: -g -O2 -Winit-self -Wwrite-strings -Wdiv-by-zero -Wsometimes-uninitialized
brew: superenv removed: -g -O2 -Winit-self -Wwrite-strings -Wdiv-by-zero -Wsometimes-uninitialized
brew: superenv removed: -g -O2 -Winit-self -Wwrite-strings -Wdiv-by-zero -Wsometimes-uninitialized
brew: superenv removed: -g -O2 -Winit-self -Wwrite-strings -Wdiv-by-zero -Wsometimes-uninitialized
brew: superenv removed: -g -O2 -Winit-self -Wwrite-strings -Wdiv-by-zero -Wsometimes-uninitialized
In file included from crypto_onetimeauth/poly1305/donna/auth_poly1305_donna.c:6:
crypto_onetimeauth/poly1305/donna/portable-jane.h:672:27: error: expected ';' after top level declarator
        typedef unsigned __int128 uint128_t;
                                 ^
                                 ;
crypto_onetimeauth/poly1305/donna/portable-jane.h:745:16: error: unknown type name 'uint128_t'
        static INLINE uint128_t
                      ^
crypto_onetimeauth/poly1305/donna/portable-jane.h:747:11: error: use of undeclared identifier 'uint128_t'
                return (uint128_t)a * b;
                        ^
crypto_onetimeauth/poly1305/donna/portable-jane.h:751:9: error: unknown type name 'uint128_t'
        shr128(uint128_t v, const int shift) {
               ^
crypto_onetimeauth/poly1305/donna/portable-jane.h:757:24: error: use of undeclared identifier 'uint128_t'
                return (uint64_t)((((uint128_t)hi << 64) | lo) >> shift);
                                     ^
crypto_onetimeauth/poly1305/donna/portable-jane.h:760:16: error: unknown type name 'uint128_t'
        static INLINE uint128_t
                      ^
crypto_onetimeauth/poly1305/donna/portable-jane.h:761:9: error: unknown type name 'uint128_t'
        add128(uint128_t a, uint128_t b) {
               ^
crypto_onetimeauth/poly1305/donna/portable-jane.h:761:22: error: unknown type name 'uint128_t'
        add128(uint128_t a, uint128_t b) {
                            ^
crypto_onetimeauth/poly1305/donna/portable-jane.h:765:16: error: unknown type name 'uint128_t'
        static INLINE uint128_t
                      ^
crypto_onetimeauth/poly1305/donna/portable-jane.h:766:12: error: unknown type name 'uint128_t'
        add128_64(uint128_t a, uint64_t b) {
                  ^
crypto_onetimeauth/poly1305/donna/portable-jane.h:771:8: error: unknown type name 'uint128_t'
        lo128(uint128_t a) {
              ^
crypto_onetimeauth/poly1305/donna/portable-jane.h:776:8: error: unknown type name 'uint128_t'
        hi128(uint128_t a) {
              ^
12 errors generated.
make[3]: *** [crypto_onetimeauth/poly1305/donna/libsodium_la-auth_poly1305_donna.lo] Error 1
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [check-recursive] Error 1
make[1]: *** [check-recursive] Error 1
make: *** [check-recursive] Error 1

Any ideas what might've changed? Since this only breaks when installing via the homebrew formula it's rather hard to bisect :(

Please write changelog

I'm packaging this module into Fedora, I don't want users to see ChangeLog like this:

git log is your friend.

Can you write the changelog?

Thanks.

Fix running time in edwards25519sha512batch

In the file fe25519_edwards25519sha512batch.c int issquare(const fe25519 *x) function:
The last line should be:
return isone(&t) | iszero(&t);
for the fix running time instead of:
return isone(&t) || iszero(&t);

Not a serious problem, but I have just noticed it.

Unifying Ed25519 and Curve25519

Curve25519 and Ed25519 are closely related, yet your code treats them as completely separate. It might be a good idea to move those code-bases closer together, perhaps even offering support for the same kind of key-pair.

Some ideas:

1. Add a Curve25519 implementation that builds on the Ref10 Ed25519 code. This only requires copying a few files from SUPERCOP.

2. Use the Ed25519 scalarmult_base function followed by a conversion to Montgomery coordinates to generate Curve25519 public keys. This quite simple and should speed up key-pair generation about two fold.

3. Offer a key-exchange API that works on Ed25519 keys. This allows people to use the same key-pair for both signatures and key-exchange, instead of using Ed25519 for one, and Montgomery Curve25519 for the other.

   A naive implementation (convert to montgomery before key-exchange) will be about 6% slower than Montgomery based key-exchange, but I believe key-exchange using Edwards coordinates can be sped up to the same level as Montogmery coordinates by modifying the scalar_mult implementation a bit.

My C# implementation already uses those techniques, so I can help you with making those changes.

Problem using crypto_auth_hmacsha256 for signing AWS requests.

From http://docs.aws.amazon.com/general/latest/gr/signature-version-2.html :

Signing this string:

"GET\nelasticmapreduce.amazonaws.com\n/\nAWSAccessKeyId=AKIAIOSFODNN7EXAMPLE&Action=DescribeJobFlows&SignatureMethod=HmacSHA256&SignatureVersion=2&Timestamp=2011-10-03T15%3A19%3A30&Version=2009-03-31"

with this key "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"

is supposed to give a url escaped Base64 : "i91nKc4PWAt0JJIdXwz9HxZCJDdiy6cf%2FMj6vPxyYIs%3D"

Instead I get the following :

• Using above key as is : "DdOZcIpGhZnkgCISxkRj6VBe7w03ZSSimZBi8ADNS88="
• Treating the above key as a base64 encoded string : "5BGiXRbrhl/pEy2Mh7g2C4W1sTvpmvPK0/bvQ6+cpGg="

I suspect it has to be do with supporting keys longer than the blocksize (64 bytes) in this case. See http://en.wikipedia.org/wiki/HMAC#Definition_.28from_RFC_2104.29

OSX: Cannot compile from a build directory

Hello,

I'm trying to compile libsodium on OSX using GCC 4.7.2 from a build directory inside the source code.

Steps to reproduce:

$ git clone git://github.com/jedisct1/libsodium.git jedisct1/libsodium
...

$ cd jedisct1/libsodium

$ ./autogen.sh
...

$ mkdir build-osx

$ cd build-osx

$ ../configure --prefix=/Users/luis/local/osx/libsodium
checking build system type... x86_64-apple-darwin12.2.1
checking host system type... x86_64-apple-darwin12.2.1
...
configure: creating ./config.status
config.status: creating Makefile
config.status: creating config.h
config.status: executing depfiles commands
config.status: executing libtool commands

$ make
Making all in libltdl
...
  CC       libsodium_la-randombytes_sysrandom.lo
  CC       libsodium_la-version.lo
../../../src/libsodium/version.c:2:21: fatal error: version.h: No such file or directory
compilation terminated.
make[3]: *** [libsodium_la-version.lo] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1

Environment information:

$ uname -v
Darwin Kernel Version 12.2.1: Thu Oct 18 12:13:47 PDT 2012; root:xnu-2050.20.9~1/RELEASE_X86_64

$ gcc --version
gcc (MacPorts gcc47 4.7.2_2) 4.7.2

$ make --version
GNU Make 3.81
...
This program built for i386-apple-darwin11.3.0

$ autoconf --version
autoconf (GNU Autoconf) 2.69

Running configure from the top level of libsodium works as expected.

Please note that building on a separate folder/tree is something that autoconf/automake supports without problems and is used to keep source from build artifacts for several packaging tools.

Thank you

❤️ ❤️ ❤️

Where is crypto_box_curve25519xsalsa20poly1305_open defined?

I'm interested in looking at the source code behind crypto_box_open.

crypto_box_curve25519xsalsa20poly1305_open is aliased as crypto_box_open here, but where is it defined?

Multiple tests fail on Linux PowerPC64

This is openSUSE 12.3 on PowerPC64,

ERROR: box
ERROR: box2
ERROR: box7
ERROR: scalarmult
ERROR: scalarmult2
ERROR: scalarmult5
ERROR: scalarmult6
ERROR: stream5
ERROR: stream6

Couldn't find a way to get a verbose output from the test programs. Let me know if you need further details.

Describe build requirements for android.sh

android.sh uses the tools "droid-gcc", "droid-as" etc. which are not part of the android ndk. It is not clear how to build on android.

Windows 64bit build

I'm trying to build a 64bit version of libsodium for Windows. I have so far been unsuccessful and wanted to make sure this was a supported scenario.

I'm using Windows 7 64bit. I have downloaded various mingw-w64 toolchains (in particular rubenvb's personal build, Mingw-builds, and TDM-GCC) along with MSYS and built numerous versions using various options which have all failed. By "fail" I mean "make check" fails all tests and my application which uses the library crashes when calling "crypto_secretbox" (but succeeds on some other, simpler calls such as sodium_init, sodium_version_string, crypto_secretbox_keybytes, etc).

I believe configure should be something along the lines of:
./configure --host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32 CFLAGS="-march=x86-64 -mtune=generic"

Is a 64bit Windows build a supported scenario? Has anyone else been able to do this successfully?

Testvectors for non canonical Curve25519 public keys

When parsing public keys there are two different approaches:

1. Interpret the input as a 256 bit integer and reduce modulo p
2. Interpret the input as 255 bit integer and reduce modulo p. Ignore the final bit.

For canonical points there is no difference between these approaches since for the the final bit is always zero. But in principle Curve25519 can be used with arbitrary 32 byte values as public key.

Ed25519 uses the second approach since it needs the final bit for the sign of the other coordinate.

Unfortunately Curve25519is specified to use the first approach. Ref and Ref10 conform to the specification, but some alternative implementations (including AGL's donna) use the second approach.

---

Some test vectors which verify that the first rule is used:

Frank's key (32*0xFF):

0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,
0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,
0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,
0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF

Must be equivalent to:

0x25,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00

And Alice's non canonical key:

0x72, 0x20, 0xf0, 0x09, 0x89, 0x30, 0xa7, 0x54,
0x74, 0x8b, 0x7d, 0xdc, 0xb4, 0x3e, 0xf7, 0x5a,
0x0d, 0xbf, 0x3a, 0x0d, 0x26, 0x38, 0x1a, 0xf4,
0xeb, 0xa4, 0xa9, 0x8e, 0xaa, 0x9b, 0x4e, 0xea

Must be equivalent to:

0x85, 0x20, 0xf0, 0x09, 0x89, 0x30, 0xa7, 0x54,
0x74, 0x8b, 0x7d, 0xdc, 0xb4, 0x3e, 0xf7, 0x5a,
0x0d, 0xbf, 0x3a, 0x0d, 0x26, 0x38, 0x1a, 0xf4,
0xeb, 0xa4, 0xa9, 0x8e, 0xaa, 0x9b, 0x4e, 0x6a

---

Probably the easiest way to verify those is to run a scalarmult on the non canonical version with the exponent set to 1. This should return the canonical version.

Corresponding issue on AGL's curve25519-donna repo: Differing interpretation of non canonical points between donna and ref

smult_curve25519_donna_c64 Doesn't build on RHEL5 (gcc-Version 4.1.2 20080704 (Red Hat 4.1.2-54))

This is with 0.4.2
only used ./configure && make and got this result.

  CC       libsodium_la-smult_curve25519_donna_c64.lo
crypto_scalarmult/curve25519/donna_c64/smult_curve25519_donna_c64.c: In function 'crypto_scalarmult_curve25519':
crypto_scalarmult/curve25519/donna_c64/smult_curve25519_donna_c64.c:424: error: unrecognizable insn:
(insn 9952 6932 9953 20 crypto_scalarmult/curve25519/donna_c64/smult_curve25519_donna_c64.c:236 (parallel [
            (set (reg:CC 17 flags)
                (unspec:CC [
                        (reg:DI 39 r10 [orig:375 t$0.844 ] [375])
                        (const_int 2251799813685229 [0x7ffffffffffed])
                    ] 24))
            (set (reg:DI 39 r10 [orig:375 t$0.844 ] [375])
                (plus:DI (reg:DI 39 r10 [orig:375 t$0.844 ] [375])
                    (const_int 2251799813685229 [0x7ffffffffffed])))
        ]) -1 (nil)
    (nil))
crypto_scalarmult/curve25519/donna_c64/smult_curve25519_donna_c64.c:424: internal compiler error: in extract_insn, at recog.c:2084

./configure --disable-blocking-random doesn't work

I downloaded the latest version, 0.4.2, and ran this command:

./configure --disable-blocking-random

I would expect that would disable use of /dev/random, but in the generated Makefile, I see:

DEFS = -DPACKAGE_NAME=\"libsodium\" -DPACKAGE_TARNAME=\"libsodium\" -DPACKAGE_VERSION=\"0.4.2\" -DPACKAGE_STRING=\"libsodium\ 0.4.2\" -DPAC
KAGE_BUGREPORT=\"https://github.com/jedisct1/libsodium/issues\" -DPACKAGE_URL=\"https://github.com/jedisct1/libsodium\" -DPACKAGE=\"libsodi
um\" -DVERSION=\"0.4.2\" -DUSE_BLOCKING_RANDOM=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_
H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -D__EXTENSIONS__=1 -D_ALL_SOURCE=1 -D_GNU_
SOURCE=1 -D_POSIX_PTHREAD_SEMANTICS=1 -D_TANDEM_SOURCE=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_EMMINTRIN_H=1 -DHAVE_TMMINTRIN_H=1 
-DHAVE_SMMINTRIN_H=1 -DHAVE_IMMINTRIN_H=1 -DHAVE_X86INTRIN_H=1 -DHAVE_WMMINTRIN_H=1 -DHAVE_FENV_H=1 -DNATIVE_LITTLE_ENDIAN=1 -DHAVE_AMD64_A
SM=1 -DHAVE_TI_MODE=1 -DHAVE_CPUID=1 -DHAVE_LIBRT=1 -DHAVE_LIBM=1

Notably:

-DUSE_BLOCKING_RANDOM=1

The reason this comes up is I am using a Gentoo ebuild which calls configure with either --disable-blocking-random or --enable-blocking-random based on a use flag. I don't have the option of calling ./configure without one of those two parameters.

Release version 0.4.3?

Can version 0.4.3. be released?

I'm trying to use the OCaml bindings, which rely on libsodium trunk but installing via homebrew would be better, which is on release 0.4.2.

unknown section type: %progbits

The stack markings introduced in #60 lead to a compilation failure on OS X 10.8 using GCC 4.7 from MacPorts, with the following error:

  CCAS     crypto_stream/salsa20/amd64_xmm6/stream_salsa20_amd64_xmm6.lo
crypto_stream/salsa20/amd64_xmm6/stream_salsa20_amd64_xmm6.s:949:unknown section type: %progbits

This is rather odd given it's wrapped in an #if as follows:

#if defined(__linux__) && defined(__ELF__)
.section .note.GNU-stack,"",%progbits
#endif

Neither of the two defined hold true.

Hash musings

In my opinion the difference between the crypto_hash and crypto_generichash categories is not clear from their name. Given that the blake implementation accepts a key crypto_keyed_hash might be an alternative.

Whilst on the subject I'd love to see streaming versions of sha256 and sha512.

Enable CurveCP by default

Just a thought. There are some prerequisites to doing this responsibly:

• Work with the CurveCP mailing list and people who have expressed concernes about CurveCP security (e.g. CodesInChaos) to address security concerns in the current release, until these can be addressed upstream
• Document Sodium ;)
• Make it clear in the documentation that CurveCP is an experts-only power-user feature. In the RbNaCl documentation, I have been using the following to make this clear: https://raw.github.com/cryptosphere/rbnacl/master/images/dragons.png

Why isn't crypto_stream_keybytes exported while crypto_stream is?

I'd like to write a binding into NaCl via Sodium but when writing the marshaling layer for crypto_stream I realized I'd have to hardcode the size of the stream key since the constant is not exported. Is this intentional? Why so?

Clang crashes attempting to compile libsodium

Attempting to build libsodium crashes clang... I'm lost trying to debug this one:

CompileC /Users/kenneth/Library/Developer/Xcode/DerivedData/Chartboost-baettyqlcfhtllakyzswndxnicht/Build/Intermediates/Pods.build/Debug-iphonesimulator/Pods-Chartboost.build/Objects-normal/i386/smult-9406F1BCE2F234AE.o libsodium/src/libsodium/crypto_scalarmult/curve25519/donna_c64/smult.c normal i386 c com.apple.compilers.llvm.clang.1_0.compiler
    cd /Users/kenneth/Dropbox/dev/caffeine/client/Pods
    setenv LANG en_US.US-ASCII
    setenv PATH "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin:/Applications/Xcode.app/Contents/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin"
    /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -x c -arch i386 -fmessage-length=0 -std=gnu99 -Wno-trigraphs -fpascal-strings -O0 -Wno-missing-field-initializers -Wno-missing-prototypes -Wno-return-type -Wformat -Wno-missing-braces -Wparentheses -Wswitch -Wno-unused-function -Wno-unused-label -Wno-unused-parameter -Wno-unused-variable -Wunused-value -Wno-empty-body -Wno-uninitialized -Wno-unknown-pragmas -Wno-shadow -Wno-four-char-constants -Wno-conversion -Wno-constant-conversion -Wno-int-conversion -Wno-enum-conversion -Wno-shorten-64-to-32 -Wpointer-sign -Wno-newline-eof -DDEBUG=1 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk -fexceptions -fasm-blocks -fstrict-aliasing -Wdeprecated-declarations -g -Wno-sign-conversion -mios-simulator-version-min=4.3 -iquote /Users/kenneth/Library/Developer/Xcode/DerivedData/Chartboost-baettyqlcfhtllakyzswndxnicht/Build/Intermediates/Pods.build/Debug-iphonesimulator/Pods-Chartboost.build/Pods-Chartboost-generated-files.hmap -I/Users/kenneth/Library/Developer/Xcode/DerivedData/Chartboost-baettyqlcfhtllakyzswndxnicht/Build/Intermediates/Pods.build/Debug-iphonesimulator/Pods-Chartboost.build/Pods-Chartboost-own-target-headers.hmap -I/Users/kenneth/Library/Developer/Xcode/DerivedData/Chartboost-baettyqlcfhtllakyzswndxnicht/Build/Intermediates/Pods.build/Debug-iphonesimulator/Pods-Chartboost.build/Pods-Chartboost-all-target-headers.hmap -iquote /Users/kenneth/Library/Developer/Xcode/DerivedData/Chartboost-baettyqlcfhtllakyzswndxnicht/Build/Intermediates/Pods.build/Debug-iphonesimulator/Pods-Chartboost.build/Pods-Chartboost-project-headers.hmap -I/Users/kenneth/Library/Developer/Xcode/DerivedData/Chartboost-baettyqlcfhtllakyzswndxnicht/Build/Products/Debug-iphonesimulator/include -I/Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders -I/Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/ATValidations -I/Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/libsodium -I/Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/crypto_auth/hmacsha256/ref -I/Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/crypto_auth/hmacsha512256/ref -I/Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/crypto_box/curve25519xsalsa20poly1305/ref -I/Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/crypto_core/hsalsa20/ref -I/Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/crypto_core/hsalsa20/ref2 -I/Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/crypto_core/salsa20/ref -I/Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/crypto_core/salsa2012/ref -I/Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/crypto_core/salsa208/ref -I/Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/crypto_hash/sha256/ref -I/Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/crypto_hash/sha512/ref -I/Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/crypto_hashblocks/sha256/inplace -I/Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/crypto_hashblocks/sha256/ref -I/Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/crypto_hashblocks/sha512/inplace -I/Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/crypto_hashblocks/sha512/ref -I/Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/crypto_onetimeauth/poly1305/ref -I/Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/crypto_scalarmult/curve25519/donna_c64 -I/Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/crypto_scalarmult/curve25519/ref -I/Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/crypto_secretbox/xsalsa20poly1305/ref -I/Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/crypto_shorthash/siphash24/ref -I/Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/crypto_sign/ed25519/ref -I/Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/crypto_sign/edwards25519sha512batch/ref -I/Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/crypto_stream/aes128ctr/portable -I/Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/crypto_stream/salsa20/ref -I/Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/crypto_stream/salsa2012/ref -I/Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/crypto_stream/salsa208/ref -I/Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/crypto_stream/xsalsa20/ref -I/Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/crypto_verify/16/ref -I/Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/crypto_verify/32/ref -I/Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/libsodium/sodium -I/Users/kenneth/Library/Developer/Xcode/DerivedData/Chartboost-baettyqlcfhtllakyzswndxnicht/Build/Intermediates/Pods.build/Debug-iphonesimulator/Pods-Chartboost.build/DerivedSources/i386 -I/Users/kenneth/Library/Developer/Xcode/DerivedData/Chartboost-baettyqlcfhtllakyzswndxnicht/Build/Intermediates/Pods.build/Debug-iphonesimulator/Pods-Chartboost.build/DerivedSources -F/Users/kenneth/Library/Developer/Xcode/DerivedData/Chartboost-baettyqlcfhtllakyzswndxnicht/Build/Products/Debug-iphonesimulator -include /Users/kenneth/Library/Developer/Xcode/DerivedData/Chartboost-baettyqlcfhtllakyzswndxnicht/Build/Intermediates/PrecompiledHeaders/Pods-Chartboost-prefix-dejvmvlbrzxdxteyaxhjhccglvui/Pods-Chartboost-prefix.pch -MMD -MT dependencies -MF /Users/kenneth/Library/Developer/Xcode/DerivedData/Chartboost-baettyqlcfhtllakyzswndxnicht/Build/Intermediates/Pods.build/Debug-iphonesimulator/Pods-Chartboost.build/Objects-normal/i386/smult-9406F1BCE2F234AE.d --serialize-diagnostics /Users/kenneth/Library/Developer/Xcode/DerivedData/Chartboost-baettyqlcfhtllakyzswndxnicht/Build/Intermediates/Pods.build/Debug-iphonesimulator/Pods-Chartboost.build/Objects-normal/i386/smult-9406F1BCE2F234AE.dia -c /Users/kenneth/Dropbox/dev/caffeine/client/Pods/libsodium/src/libsodium/crypto_scalarmult/curve25519/donna_c64/smult.c -o /Users/kenneth/Library/Developer/Xcode/DerivedData/Chartboost-baettyqlcfhtllakyzswndxnicht/Build/Intermediates/Pods.build/Debug-iphonesimulator/Pods-Chartboost.build/Objects-normal/i386/smult-9406F1BCE2F234AE.o

0  clang 0x0000000100c539f2 main + 12919346
Stack dump:
0.  Program arguments: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -cc1 -triple i386-apple-ios4.3.0 -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name smult.c -pic-level 2 -mdisable-fp-elim -masm-verbose -target-cpu yonah -target-linker-version 136 -g -coverage-file /Users/kenneth/Library/Developer/Xcode/DerivedData/Chartboost-baettyqlcfhtllakyzswndxnicht/Build/Intermediates/Pods.build/Debug-iphonesimulator/Pods-Chartboost.build/Objects-normal/i386/smult-9406F1BCE2F234AE.o -resource-dir /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/4.2 -dependency-file /Users/kenneth/Library/Developer/Xcode/DerivedData/Chartboost-baettyqlcfhtllakyzswndxnicht/Build/Intermediates/Pods.build/Debug-iphonesimulator/Pods-Chartboost.build/Objects-normal/i386/smult-9406F1BCE2F234AE.d -MT dependencies -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk -iquote /Users/kenneth/Library/Developer/Xcode/DerivedData/Chartboost-baettyqlcfhtllakyzswndxnicht/Build/Intermediates/Pods.build/Debug-iphonesimulator/Pods-Chartboost.build/Pods-Chartboost-generated-files.hmap -iquote /Users/kenneth/Library/Developer/Xcode/DerivedData/Chartboost-baettyqlcfhtllakyzswndxnicht/Build/Intermediates/Pods.build/Debug-iphonesimulator/Pods-Chartboost.build/Pods-Chartboost-project-headers.hmap -include-pch /Users/kenneth/Library/Developer/Xcode/DerivedData/Chartboost-baettyqlcfhtllakyzswndxnicht/Build/Intermediates/PrecompiledHeaders/Pods-Chartboost-prefix-dejvmvlbrzxdxteyaxhjhccglvui/Pods-Chartboost-prefix.pch.pth -D DEBUG=1 -I /Users/kenneth/Library/Developer/Xcode/DerivedData/Chartboost-baettyqlcfhtllakyzswndxnicht/Build/Intermediates/Pods.build/Debug-iphonesimulator/Pods-Chartboost.build/Pods-Chartboost-own-target-headers.hmap -I /Users/kenneth/Library/Developer/Xcode/DerivedData/Chartboost-baettyqlcfhtllakyzswndxnicht/Build/Intermediates/Pods.build/Debug-iphonesimulator/Pods-Chartboost.build/Pods-Chartboost-all-target-headers.hmap -I /Users/kenneth/Library/Developer/Xcode/DerivedData/Chartboost-baettyqlcfhtllakyzswndxnicht/Build/Products/Debug-iphonesimulator/include -I /Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders -I /Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/ATValidations -I /Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/libsodium -I /Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/crypto_auth/hmacsha256/ref -I /Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/crypto_auth/hmacsha512256/ref -I /Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/crypto_box/curve25519xsalsa20poly1305/ref -I /Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/crypto_core/hsalsa20/ref -I /Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/crypto_core/hsalsa20/ref2 -I /Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/crypto_core/salsa20/ref -I /Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/crypto_core/salsa2012/ref -I /Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/crypto_core/salsa208/ref -I /Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/crypto_hash/sha256/ref -I /Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/crypto_hash/sha512/ref -I /Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/crypto_hashblocks/sha256/inplace -I /Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/crypto_hashblocks/sha256/ref -I /Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/crypto_hashblocks/sha512/inplace -I /Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/crypto_hashblocks/sha512/ref -I /Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/crypto_onetimeauth/poly1305/ref -I /Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/crypto_scalarmult/curve25519/donna_c64 -I /Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/crypto_scalarmult/curve25519/ref -I /Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/crypto_secretbox/xsalsa20poly1305/ref -I /Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/crypto_shorthash/siphash24/ref -I /Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/crypto_sign/ed25519/ref -I /Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/crypto_sign/edwards25519sha512batch/ref -I /Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/crypto_stream/aes128ctr/portable -I /Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/crypto_stream/salsa20/ref -I /Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/crypto_stream/salsa2012/ref -I /Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/crypto_stream/salsa208/ref -I /Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/crypto_stream/xsalsa20/ref -I /Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/crypto_verify/16/ref -I /Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/crypto_verify/32/ref -I /Users/kenneth/Dropbox/dev/caffeine/client/Pods/BuildHeaders/libsodium/sodium -I /Users/kenneth/Library/Developer/Xcode/DerivedData/Chartboost-baettyqlcfhtllakyzswndxnicht/Build/Intermediates/Pods.build/Debug-iphonesimulator/Pods-Chartboost.build/DerivedSources/i386 -I /Users/kenneth/Library/Developer/Xcode/DerivedData/Chartboost-baettyqlcfhtllakyzswndxnicht/Build/Intermediates/Pods.build/Debug-iphonesimulator/Pods-Chartboost.build/DerivedSources -F/Users/kenneth/Library/Developer/Xcode/DerivedData/Chartboost-baettyqlcfhtllakyzswndxnicht/Build/Products/Debug-iphonesimulator -fmodule-cache-path /var/folders/k6/xy3tmzhd6gsflq3h7qgxqvzc0000gn/T/clang-module-cache -O0 -Wno-trigraphs -Wno-missing-field-initializers -Wno-missing-prototypes -Wno-return-type -Wformat -Wno-missing-braces -Wparentheses -Wswitch -Wno-unused-function -Wno-unused-label -Wno-unused-parameter -Wno-unused-variable -Wunused-value -Wno-empty-body -Wno-uninitialized -Wno-unknown-pragmas -Wno-shadow -Wno-four-char-constants -Wno-conversion -Wno-constant-conversion -Wno-int-conversion -Wno-enum-conversion -Wno-shorten-64-to-32 -Wpointer-sign -Wno-newline-eof -Wdeprecated-declarations -Wno-sign-conversion -std=gnu99 -ferror-limit 19 -fmessage-length 0 -stack-protector 1 -mstackrealign -fblocks -fobjc-runtime=ios-4.3.0 -fobjc-default-synthesize-properties -fexceptions -fpascal-strings -fdiagnostics-show-option -fasm-blocks -serialize-diagnostic-file /Users/kenneth/Library/Developer/Xcode/DerivedData/Chartboost-baettyqlcfhtllakyzswndxnicht/Build/Intermediates/Pods.build/Debug-iphonesimulator/Pods-Chartboost.build/Objects-normal/i386/smult-9406F1BCE2F234AE.dia -o /Users/kenneth/Library/Developer/Xcode/DerivedData/Chartboost-baettyqlcfhtllakyzswndxnicht/Build/Intermediates/Pods.build/Debug-iphonesimulator/Pods-Chartboost.build/Objects-normal/i386/smult-9406F1BCE2F234AE.o -x c /Users/kenneth/Dropbox/dev/caffeine/client/Pods/libsodium/src/libsodium/crypto_scalarmult/curve25519/donna_c64/smult.c 
1.  <eof> parser at end of file
2.  Code generation
3.  Running pass 'Function Pass Manager' on module '/Users/kenneth/Dropbox/dev/caffeine/client/Pods/libsodium/src/libsodium/crypto_scalarmult/curve25519/donna_c64/smult.c'.
4.  Running pass 'X86 DAG->DAG Instruction Selection' on function '@fmul'
clang: error: unable to execute command: Segmentation fault: 11
clang: error: clang frontend command failed due to signal (use -v to see invocation)
Apple LLVM version 4.2 (clang-425.0.24) (based on LLVM 3.2svn)
Target: i386-apple-darwin12.2.1
Thread model: posix
clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script.
clang: note: diagnostic msg: 
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /var/folders/k6/xy3tmzhd6gsflq3h7qgxqvzc0000gn/T/smult-GarzVF.c
clang: note: diagnostic msg: /var/folders/k6/xy3tmzhd6gsflq3h7qgxqvzc0000gn/T/smult-GarzVF.sh
clang: note: diagnostic msg: 

********************
Command /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang failed with exit code 254

Build from source/Secure download

Could you provide an explanation of how to build from the source repository in the README?

Right now, I get

$ ./autogen.sh 
autoreconf2.50: Entering directory `.'
autoreconf2.50: configure.ac: not using Gettext
autoreconf2.50: running: aclocal --force -I m4
autoreconf2.50: configure.ac: tracing
autoreconf2.50: configure.ac: not using Libtool
autoreconf2.50: running: /usr/bin/autoconf --force
configure.ac:322: error: possibly undefined macro: AC_LIBTOOL_WIN32_DLL
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
autoreconf2.50: /usr/bin/autoconf failed with exit status: 1

Alternately, would it be possible to offer the source tarball over HTTPS?

Thank you! :-)

Failure building libsodium 4.3 on Win 8 MinGW

Steps to reproduce:
Fresh install of MinGW with MSYS.
Update paths to include MinGW and MSYS.
Untar libsodium-0.4.3.tar.gz
cd into libsodium directory
sh configure (succeeds)
make (fails with output below)

Last bit of output is:
CC crypto_auth/hmacsha512256/libsodium_la-auth_hmacsha512256_api.lo
crypto_auth/hmacsha512256/auth_hmacsha512256_api.c:1:0: warning: -fPIC ignored f
or target (all code is position independent) [enabled by default]
#include "crypto_auth_hmacsha512256.h"
^
CC crypto_auth/hmacsha512256/ref/libsodium_la-hmac_hmacsha512256.lo
crypto_auth/hmacsha512256/ref/hmac_hmacsha512256.c:1:0: warning: -fPIC ignored f
or target (all code is position independent) [enabled by default]
/*
^
CC crypto_auth/hmacsha512256/ref/libsodium_la-verify_hmacsha512256.lo
crypto_auth/hmacsha512256/ref/verify_hmacsha512256.c:1:0: warning: -fPIC ignored
for target (all code is position independent) [enabled by default]
#include "api.h"
^
CC crypto_box/libsodium_la-crypto_box.lo
crypto_box/crypto_box.c:1:0: warning: -fPIC ignored for target (all code is posi
tion independent) [enabled by default]

^
make[3]: *** No rule to make target crypto_box/curve25519xsalsa20poly1305/box_c urve25519xsalsa20poly1305_api.c', needed bycrypto_box/curve25519xsalsa20poly13
05/libsodium_la-box_curve25519xsalsa20poly1305_api.lo'. Stop.
make[3]: Leaving directory /c/Dev/libsodium-0.4.3/src/libsodium' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory/c/Dev/libsodium-0.4.3/src/libsodium'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/c/Dev/libsodium-0.4.3/src'
make: *** [all-recursive] Error 1

SHA1 and MD5

Some of Amazon's APIs, S3 for example, only supports HMAC-SHA1 signatures.

Will libsodium ever include support for creation of HMAC-SHA1 digests?
Also MD5 hashing. Again, it used with AWS S3 to verify correctness of uploaded data.

Support aes256ctr (and aes192ctr?)

So, having actually read the code this time, it seems libsodium only has aes128ctr. SUPERCOP has aes256ctr (and also aes192ctr):

http://bench.cr.yp.to/impl-stream/aes256ctr.html

djb says we should probably be using 256-bit keys:

http://cr.yp.to/snuffle/bruteforce-20050425.pdf

Having aes256ctr (and also aes192ctr maybe?) would be super!

Add licensing information

This repo is missing any reference to the license under which this code is published. Please add a license file and reference it directly in README.markdown.