p-h-c / phc-winner-argon2 Goto Github PK

View Code? Open in Web Editor NEW

4.7K 4.7K 397.0 5.77 MB

The password hash Argon2, winner of PHC

License: Other

Makefile 3.56% Shell 0.58% C 93.95% PowerShell 1.32% Swift 0.58%

phc-winner-argon2's People

Contributors

Stargazers

Watchers

Forkers

floyd-fuh jedisct1 remyroy rope93 0-wiz-0 technion uniqp samuelmarks agilemobiledev respu srfrog vdt thomasbhatia wflk ocharles m00dy optimiz3 bpd1069 lucab drooids tvdburgt claudiouzelac mbroz atlasian seanhussey khady cryptodeveloper ehowardtillit blamkiwi bryant ranisalt bwackwat alipha bowlingb darkdare securecloud-biz cjlarose aberaud novmicha janetizzy tboettch 607011 sjord apsalar beauhoyt kmaragon plasmapower qowyn ikarius6 fxfactorial abhishesh wonder93 gittermatt antelle macpass darwinairola jduncanator safari77 leont ionux josephlr quantumgravity444 jdconley jjediny kleetus yomgui1 riverrun aseptilena alexis-d p07r0457 liinnux cybernetics njjjcaustin flyingface dwihujianto zsvanderlaan looknd olivierh59500 iamspid3r ritsute enterstudio sru-systems alex-ilin quinndiggity codingmarkus vookimedlo nulledexceptions scdeveloper luc-lynx julianvolodia digideskio maarijbaig pshanoop goblin thusoy wrathematics modzilla patricktoca nosajoahs iampri

phc-winner-argon2's Issues

Use at most as many threads as the computer has cores?

At the moment argon2i_hash (and friends) will use as many threads as the lanes/parallelism parameter. If however we compute a 32-lanes argon2-hash on a 2-core machine, it does not make a lot of sense to spawn 32 threads. One can work around this by using argon2_core and setting the threads field of the executed argon2_context to the number of cores on the machine.

Would you think it's ok if argon2i_hash and friends cap threads to the number of cores on the machine? If so, I can write a patch.

Do not pass the password as a command-line argument

If the argon2 command line utility is ever used for anything but testing purposes, this is a bad idea:

./argon2 pwd salt [-d] [-t iterations] [-m memory] [-p parallelism]

The problem is that other users of the same system can see which programs are running and what their command line arguments are (for example using top -c).

It would be better to read the password from stdin like this:

echo "pwd"|./argon2 salt [-d] [-t iterations] [-m memory] [-p parallelism]

32- and 64-bit version

Shall we make separate makefiles for 32- and 64-bit systems? They can differ in maximum memory size at least.

Javascript implementation

I've created bindings for Javascript based on this implementation: https://github.com/ranisalt/node-argon2
Currently I didn't implement an option to choose between Argon2i and Argon2d but that's on the way.

Segmentation fault on -m 94 -m 95

So I've run fuzzing tests with American Fuzzy Lop (AFL, http://lcamtuf.coredump.cx/afl/ ), as argon2 takes all it's arguments from command line I used the argv fuzzer included in AFL (in experimental/argv_fuzzing/argv-fuzz-inl.h).

There are only two changes necessary to make argon2 fuzzable by AFL:

include the argv-fuzz-inl.h header file in main.c.
add as first line in the main function in main.c: AFL_INIT_SET0("argon2");

This means argon2 will read arguments from stdin as zero byte delimited values. See argv-fuzz-inl.h for details. You need to produce test corpus data first (input files where AFL can start from). I only started with one file "test" (where \x00 are zero bytes):

r\x00-y\x00i\x00-t\x004\x00-m\x003\x00-l\x004\x00-p\x003\x00-i\x00lalalal\x00\x00

To see if it that test file is correctly working with (reading zero byte delimited values from stdin):

$ cat input/test | ./argon2-afl/argon2 
Argon2i with
        t_cost = 4
        m_cost = 8
        password = lalalal
        salt = 00000000000000000000000000000000
0.011 seconds (74.406 mebicycles)
745182e43ac2b9a26584e100e1c98db657b3775a561a6de9abc5305bc9f7abef
$argon2i$m=8,t=4,p=4$AAAAAAAAAAAAAAAAAAAAAA$dFGC5DrCuaJlhOEA4cmNtlezd1pWGm3pq8UwW8n3q+8

Then AFL can be started with:

afl-fuzz -i /opt/argon2/input -o /opt/argon2/output-001 -M argon2-001 /opt/argon2/argon2-afl/argon2

Something like this should start:

                     american fuzzy lop 1.77b (argon2-001)

┌─ process timing ─────────────────────────────────────┬─ overall results ─────┐
│        run time : 0 days, 14 hrs, 36 min, 26 sec     │  cycles done : 2      │
│   last new path : 0 days, 0 hrs, 2 min, 27 sec       │  total paths : 1756   │
│ last uniq crash : 0 days, 6 hrs, 4 min, 4 sec        │ uniq crashes : 24     │
│  last uniq hang : 0 days, 12 hrs, 22 min, 16 sec     │   uniq hangs : 500+   │
├─ cycle progress ────────────────────┬─ map coverage ─┴───────────────────────┤
│  now processing : 1598 (91.00%)     │    map density : 2757 (4.21%)          │
│ paths timed out : 2 (0.11%)         │ count coverage : 2.14 bits/tuple       │
├─ stage progress ────────────────────┼─ findings in depth ────────────────────┤
│  now trying : havoc                 │ favored paths : 227 (12.93%)           │
│ stage execs : 74.1k/89.6k (82.70%)  │  new edges on : 1044 (59.45%)          │
│ total execs : 10.1M                 │ total crashes : 1967 (24 unique)       │
│  exec speed : 218.2/sec             │   total hangs : 341k (500+ unique)     │
├─ fuzzing strategy yields ───────────┴───────────────┬─ path geometry ────────┤
│   bit flips : 120/115k, 46/114k, 46/114k            │    levels : 13         │
│  byte flips : 8/14.4k, 11/14.0k, 4/13.2k            │   pending : 1356       │
│ arithmetics : 382/804k, 56/368k, 15/61.3k           │  pend fav : 49         │
│  known ints : 32/65.0k, 67/299k, 157/535k           │ own finds : 1638       │
│  dictionary : 0/0, 0/0, 87/495k                     │  imported : 116        │
│       havoc : 585/6.91M, 0/0                        │  variable : 1637       │
│        trim : 2.41%/3726, 0.00%                     ├────────────────────────┘
└─────────────────────────────────────────────────────┘             [cpu:204%]

I highly recommend you to set up your own AFL fuzzing instance (like a continuous testing environment). I'm not going to fuzz this project any further for now.

Now let's talk about the results. Turns out that argon2 segfaults on -m 94 or -m 95, but seem to wrap around (integer overflow?) when larger numbers are used (tested on 32bit and ARM):

$ ./argon2-asan/argon2 -m 93
Argon2i with
        t_cost = 3
        m_cost = 2097152
        password = password
        salt = 00000000000000000000000000000000
0.000 seconds (0.368 mebicycles)
4d8704087162b2bf2f00000000700508a247050803000000344cb2bf444cb2bf
$argon2i$m=2097152,t=3,p=4$AAAAAAAAAAAAAAAAAAAAAA$TYcECHFisr8vAAAAAHAFCKJHBQgDAAAANEyyv0RMsr8

$ ./argon2-asan/argon2 -m 94
Argon2i with
        t_cost = 3
        m_cost = 4194304
        password = password
        salt = 00000000000000000000000000000000
Segmentation fault

$ ./argon2-asan/argon2 -m 95
Argon2i with
        t_cost = 3
        m_cost = 8388608
        password = password
        salt = 00000000000000000000000000000000
Segmentation fault

$ ./argon2-asan/argon2 -m 96
Argon2i with
        t_cost = 3
        m_cost = 1
        password = password
        salt = 00000000000000000000000000000000
0.000 seconds (0.304 mebicycles)
4d8704087102e9bf2f00000000700508a247050803000000d4f2e8bfe4f2e8bf
$argon2i$m=1,t=3,p=4$AAAAAAAAAAAAAAAAAAAAAA$TYcECHEC6b8vAAAAAHAFCKJHBQgDAAAA1PLov+Ty6L8

Should be easy to reproduce. Here's a backtrace:

$ gdb --args ./argon2-asan/argon2 -m 95
GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./argon2-asan/argon2...done.
(gdb) run
Starting program: /opt/argon2/argon2-asan/argon2 -m 95
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
Argon2i with
        t_cost = 3
        m_cost = 8388608
        password = password
        salt = 00000000000000000000000000000000

Program received signal SIGSEGV, Segmentation fault.
blake2b_long (out=0x88058018 <error: Cannot access memory at address 0x88058018>, in=in@entry=0xbfffecf4, outlen=outlen@entry=1024, inlen=72) at src/blake2/blake2b-ref.c:320
320             memcpy( out, out_buffer, BLAKE2B_OUTBYTES / 2 );
(gdb) bt
#0  blake2b_long (out=0x88058018 <error: Cannot access memory at address 0x88058018>, in=in@entry=0xbfffecf4, outlen=outlen@entry=1024, inlen=72) at src/blake2/blake2b-ref.c:320
#1  0x08049b91 in fill_first_blocks (
    blockhash=blockhash@entry=0xbfffecf4 "\253\230\367\374W\024\315\204\326X\344\070\331I\267\311\200)\300\337\330\027\b\215\062\240\347\037\236n\377\213\027\333\213\330\n\034,\203m\227\206\224F\017\020*\334\016\071LW\301\206a\bV\376#A~\"<", instance=instance@entry=0xbfffed6c) at src/core.c:500
#2  0x08049f4b in initialize (instance=instance@entry=0xbfffed6c, context=context@entry=0xbfffee2c) at src/core.c:620
#3  0x0804a187 in argon2_core (context=context@entry=0xbfffee2c, type=type@entry=Argon2_i) at src/core.c:660
#4  0x08049227 in argon2i (context=context@entry=0xbfffee2c) at src/argon2.c:159
#5  0x0805412f in run (out=out@entry=0xbffff02c "M\207\004\bo\362\377\277/", pwd=pwd@entry=0x0, t_cost=t_cost@entry=3, m_cost=m_cost@entry=8388608, lanes=lanes@entry=4, 
    threads=threads@entry=4, type=type@entry=0x8054df6 "i", print=print@entry=false) at src/main.c:225
#6  0x08048baa in main (argc=3, argv=0xbffff104) at src/main.c:405

ASAN (address sanitizer) doesn't seem to catch the bug.

I know that an attacker controlling the m_cost of argon2 is probably a bad idea anyway and shouldn't happen, however, I do expect such a crypto tool to be rock solid.

Moreover I got various crashes that are not reproducible with vanilla argon2, but are probably poping up because of the memory restrictions that AFL enforces (for performance reasons, 25MB here, you can change that with -m to afl-fuzz). While I can't confirm this is an issue it might be worth checking how argon2 performs in memory limited environments.

secure_wipe_memory not found, with clang

Not time to fix this at the moment, so leaving this here to fix later.

➜  phc-winner-argon2 git:(master) make bin
gcc -std=c99 -pthread -O3 -Wall -g src/argon2.c src/core.c src/kat.c src/blake2/blake2b-ref.c src/thread.c src/ref.c src/main.c -Isrc  -o argon2
In file included from src/main.c:20:
src/argon2.h:282:16: warning: inline function 'secure_wipe_memory' is not defined [-Wundefined-inline]
__inline void  secure_wipe_memory(void *v, size_t n);
               ^
src/main.c:199:3: note: used here
                secure_wipe_memory(pwd, strlen(pwd));
                ^
1 warning generated.
Undefined symbols for architecture x86_64:
  "_secure_wipe_memory", referenced from:
      _clear_memory in core-4dbd10.o
      _finalize in core-4dbd10.o
      _initial_hash in core-4dbd10.o
      _initialize in core-4dbd10.o
      _run in main-54cfcb.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [argon2] Error 1

Document recommended parameter settings

What are some good starting points for the time, memory and parallelism parameters?

Compilation on Visual Studio/MSVC 9

Hi,

context: I’ve built friendly CFFI-base Python wrappers that work over all Python version and implementations (PyPy…). I also vendor Argon2 and want to offer binary packages (called wheels) for Windows.

This may become a story of multiple tickets I’m afraid since I’m not too skilled WRT Windows. Anyhow but the first problem I’ve run into is that Argon2 currently can’t be compiled using MSVC 9.0 (which I believe is VS 2008) which unfortunately is the one you have to use for Python 2.7 extensions (Microsoft even put it online just for that reason: Microsoft Visual C++ Compiler for Python 2.7
)

The first problem I ran into is that you’re including inttypes.h which VS 2008 lacks. I was able to work around that one by dropping http://msinttypes.googlecode.com/svn/trunk/stdint.h into the repo and change the includes.

As such, I was able to compile most of the project:

building 'libargon2' library
C:\Users\Hynek Schlawack\AppData\Local\Programs\Common\Microsoft\Visual C++ for Python\9.0\VC\Bin\cl.exe /c /nologo /Ox
/MD /W3 /GS- /DNDEBUG -Ilibargon2/src -Ilibargon2/src/blake2 /Tclibargon2/src/argon2.c /Fobuild\temp.win32-2.7\libargon2
/src/argon2.obj
argon2.c
C:\Users\Hynek Schlawack\AppData\Local\Programs\Common\Microsoft\Visual C++ for Python\9.0\VC\Bin\cl.exe /c /nologo /Ox
/MD /W3 /GS- /DNDEBUG -Ilibargon2/src -Ilibargon2/src/blake2 /Tclibargon2/src/blake2/blake2b.c /Fobuild\temp.win32-2.7\l
ibargon2/src/blake2/blake2b.obj
blake2b.c
C:\Users\Hynek Schlawack\AppData\Local\Programs\Common\Microsoft\Visual C++ for Python\9.0\VC\Bin\cl.exe /c /nologo /Ox
/MD /W3 /GS- /DNDEBUG -Ilibargon2/src -Ilibargon2/src/blake2 /Tclibargon2/src/core.c /Fobuild\temp.win32-2.7\libargon2/s
rc/core.obj
core.c
C:\Users\Hynek Schlawack\AppData\Local\Programs\Common\Microsoft\Visual C++ for Python\9.0\VC\Bin\cl.exe /c /nologo /Ox
/MD /W3 /GS- /DNDEBUG -Ilibargon2/src -Ilibargon2/src/blake2 /Tclibargon2/src/encoding.c /Fobuild\temp.win32-2.7\libargo
n2/src/encoding.obj
encoding.c
libargon2/src/encoding.c(407) : warning C4996: 'sprintf': This function or variable may be unsafe. Consider using sprint
f_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
        C:\Users\Hynek Schlawack\AppData\Local\Programs\Common\Microsoft\Visual C++ for Python\9.0\VC\Include\stdio.h(36
6) : see declaration of 'sprintf'
libargon2/src/encoding.c(409) : warning C4996: 'sprintf': This function or variable may be unsafe. Consider using sprint
f_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
        C:\Users\Hynek Schlawack\AppData\Local\Programs\Common\Microsoft\Visual C++ for Python\9.0\VC\Include\stdio.h(36
6) : see declaration of 'sprintf'
libargon2/src/encoding.c(411) : warning C4996: 'sprintf': This function or variable may be unsafe. Consider using sprint
f_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
        C:\Users\Hynek Schlawack\AppData\Local\Programs\Common\Microsoft\Visual C++ for Python\9.0\VC\Include\stdio.h(36
6) : see declaration of 'sprintf'
C:\Users\Hynek Schlawack\AppData\Local\Programs\Common\Microsoft\Visual C++ for Python\9.0\VC\Bin\cl.exe /c /nologo /Ox
/MD /W3 /GS- /DNDEBUG -Ilibargon2/src -Ilibargon2/src/blake2 /Tclibargon2/src/opt.c /Fobuild\temp.win32-2.7\libargon2/sr
c/opt.obj
opt.c
libargon2/src/opt.c(18) : fatal error C1083: Cannot open include file: 'immintrin.h': No such file or directory
error: command 'C:\\Users\\Hynek Schlawack\\AppData\\Local\\Programs\\Common\\Microsoft\\Visual C++ for Python\\9.0\\VC\
\Bin\\cl.exe' failed with exit status 2

And I really don’t know how to fix that one…

To be clear: this means it’s currently impossible to build Python 2 (still 90+% of the landscape) packages on Windows.

Steps to reproduce (tested on Windows 10):

Install Microsoft Visual C++ Compiler for Python 2.7
Install Python 2.7.11
git clone https://github.com/hynek/argon2_cffi and cd into it.
git submodules update to pull in your library.
Install virtualenv: C:\Python27\Scripts\pip.exe install virtualenv
create a virtualenv: C:\Python27\Scripts\virtualenv.exe venv
try to build a wheel using that virtualenv: .\venv\Scripts\python.exe .\setup.py bdist_wheel

Behold the fail.

I’m sorry. :(

I really hope we can get this working on all platforms as I’d like to establish Argon2 in the Python community. But that impossible if it doesn’t work on 2.7/Windows…

And tomorrow I’ll try to get it working on Python 3. :-/

Confusing Constants, core.h, Word vs QWord

Excerpted from core.h, line 34
/* Memory block size in bytes */
ARGON2_BLOCK_SIZE = 1024,
ARGON2_WORDS_IN_BLOCK = ARGON2_BLOCK_SIZE / 8,
ARGON2_QWORDS_IN_BLOCK = 64,

According to the definitions here:
http://edwin-wang.com/2012/02/bit-nybble-byte-word-dword-qword/
and here:
https://msdn.microsoft.com/en-us/library/2s70e2x4.aspx

If we have 1024 bytes per block (8192 bits), and a QWORD is 8 bytes (64 bits), then by definition we should have 128 QWORDS, not 64.

Off-by-one in blake2b_long?

Reported on freenode/##crypto:

21:38 < doomrobo> in blake2b_long, it appears to be calculating V_{r+1} = H_{tau - 32r}(V_r) instead of V_{r+1} = H_{tau-32r}(V_{r-1}). The relevant code is here

phc-winner-argon2/src/blake2/blake2b.c

Line 363 in ea8545a

TRY(blake2b(out_buffer, toproduce, in_buffer, BLAKE2B_OUTBYTES, NULL,

21:39 < doomrobo> and relevant part of the spec: https://imgur.com/ko7IoXA

(credit to Michael Rosenberg)

Typo in spec?

On page 5, on the final sentence, shouldn't B_m be replaced with B_{m'} to match terminology used on the previous line?

Since B is already used as the matrix B[i][j] it might be cleaner to use another letter here instead of using both terminology B[i][j] and B_m. C?

autotools build framework

Please take a look at my fork, which contains a basic autotools framework for argon2.
kats/test.sh needs to be converted to work with this.
And it's currently a configure flag (--enable-optimization) to decide if opt.c or ref.c is used.

Use CMake

In reference to #22, and other questions requesting support for one IDE or the other, why don't we just use CMake?

Started converting your Makefile line-by-line [pretty much] to a CMakeLists.txt. Here's the gist of it.

It's not fully functional yet, which explains the lack of PR. Creating an issue to start the discussion.

Version number in the hash string

The encoded hash string should contain the version number (when it is omitted it should be v.1.2). The code should be able to parse the version number and run the relevant version of the hash function to ensure backward compatibility.

exit(-1) on thread creation/join failures

Before anything - thanks for publishing this!

In reading through argon2's source, I noticed three occurences of exit(-1) in core.c:

https://github.com/P-H-C/phc-winner-argon2/blob/master/src/core.c#L289
https://github.com/P-H-C/phc-winner-argon2/blob/master/src/core.c#L308
https://github.com/P-H-C/phc-winner-argon2/blob/master/src/core.c#L322

...which means programs that link against argon2 might terminate unexpectedly.
Consider, for example, the following Python program that uses argon2_cffi:

import resource
import sys

from argon2 import PasswordHasher

if sys.argv[1:]:
    resource.setrlimit(resource.RLIMIT_NPROC, (1, 1))


ph = PasswordHasher()
print ph.hash("s3kr3tp4ssw0rd")
print "More code runs."

When run on a Linux system with no arguments it runs in its entirety. However, with additional arguments, the program reduces the allowed number of processes/threads below what argon2 requires, and so argon2 causes an unexpected termination:

$ python example.py
$argon2i$m=512,t=2,p=2$DOoJURupbQWaLfR2ye12tQ$kiBvcn+l+6RBRTaUVB7UiQ
More code runs.
$ python example.py 1
ERROR; return code from argon2_thread_create() is 11

An API that reserves the right to terminate your program seems troubling, especially as it might enable an attack. A web server under resource pressure, for example, could be pushed into a cascading failure.

At the very least this behavior should be documented. I'll be happy to submit a PR either for an API change or for a documentation change.

Thanks again for argon2!

-fsanitize=undefined unsupported by clang on OS X

Noticed this while doing quick tests of test functions, haven't investigated the best solution:

✗ make testci
cc -std=c89 -pthread -O3 -Wall -g -Iinclude -Isrc  -Werror=declaration-after-statement -D_FORTIFY_SOURCE=2 -Wextra -Wno-type-limits -Werror -fsanitize=address -fsanitize=undefined src/argon2.c src/core.c src/blake2/blake2b.c src/thread.c src/encoding.c src/ref.c src/test.c -o testcase
clang: error: unsupported argument 'undefined' to option 'fsanitize='
make: *** [testci] Error 1
✗ clang -v
Apple LLVM version 7.0.2 (clang-700.1.81)
Target: x86_64-apple-darwin15.3.0
Thread model: posix

Incorrect default

Hi,

README states:

-p N            Sets parallelism to N threads (default 4)

However run.c contains:

#define LANES_DEF 1
#define THREADS_DEF 1

Much like my previous issue, I'd have been happy to submit a PR but I'm unsure the actual intent.

main()

Hi,

Can someone clarify what the intention with main() is? Following 6887dae, it no longer behaves anything like the README and there's a whole main2() that seems like dead code?

Expose `argon2_core` or add `argon2_verify_i`

argon2_core would be handy to officially have in the argon2 API. (That is: move from core.h to argon2.h.)

Alternatively, please add the missing verify_i.

Digest sizes < 12 fail to verify

Hi,

a user of argon2_cffi found an edge case where argon2 will create a hash but verification will fail with a decoding error: hynek/argon2-cffi#4

I could narrow it down to digest lengths that are less than 12 bytes (I used your run.c for that, not my bindings).

Some public methods missing namespacing (too generic naming)

Most of the library interface sits in the argon2* namespace. Some methods however are generically named:

verify_d()
verify_i()
error_message()

Those could conflict with other library or app-specific functions. I suggest to rename them to prepend the argon2 namespace prefix. The verify functions may perhaps follow the argon2(d|i)_verify scheme for compact-ness?

This change will of course break the public interface for existing apps and bindings.

Internal symbols exported in shared library

libargon2.so is built without any visibility control options. By default, clang/gcc export all non-local symbols. The result is the library currently exposing all these symbols. This means:

internal details are part of the ABI
some blake2_* symbols are available, but not really defined in headers

On posix platforms, I suggest to implement visibility control by explicitely marking exported function as explained in the doc.

Continuous Integration

Given the number of supported platforms and that it is hard to test each code change on all supported platforms, I think it might be useful to have a CI system to automatically detect and eventually avoid the compilation errors.

It would be nice to build at least on the following systems:

Debian/Ubuntu
Mac OS X
Windows

Any volunteer?

Out-of-bounds read in error_message()

Currently in master:

const char *error_message(int error_code) {
[...]
    if (error_code < ARGON2_ERROR_CODES_LENGTH) {
        return Argon2_ErrorMessage[(argon2_error_codes)error_code];
    }

This doesn't check for negative values, resulting in an improper cast and an out-of-bounds access to the Argon2_ErrorMessage array when an index <0 is supplied.

Valgrind diagnostic:

==3270== Invalid read of size 8
==3270==    at 0x4E36DC5: error_message (argon2.c:395)
==3270==    by 0x400683: main (in a.out)
==3270==  Address 0x80503baf8 is not stack'd, malloc'd or (recently) free'd

What to do about bad salting?

I think there were some issues with salting in the node bindings (ranisalt/node-argon2#11). What are the consequences of using a low-entropy salt, and do you guys have any suggestions on fixing things after the fact?

[FEATURE REQUEST] release static builds of each version

i'd like to use this in an AWS lambda and i'd prefer not to have to make every time. you could publish each static build in the github release.

spec vs reference implementation

In section 3.2 Operation, the spec defines that the first two blocks should be set like this:
B[i][0] = H'(H0||i||0), B[i][1] = H'(H0||i||1).
However, the reference implementation initializes them like this:
B[i][0] = H'(H0||0||i), B[i][1] = H'(H0||1||i).
I can't match the description of H' function (in the same section) to the implementation. The description of H' function states that r=tao/32-1, and V[r+1] is absent if 64 divides tao. However, that can't be true because this would give us 992-byte hash when we request 1024-byte output (Tag = A1||A2||...||Ar, with V[r+1] absent, where r = 1024/32 - 1 = 31, and each A is 32 bytes). Also, when tao is less than 32, the definition results in a negative value of r.

enum argon2_error_codes should not be part of the public interface

argon2.h currently exposes a enum Argon2_ErrorCodes and the related argon2_error_codes typedef. However, this enum is not used by any public library method, as errors are signaled by returning non-zero integers.

In order to improve privacy (stop apps abusing internal error codes), compatibility (guard code changing across versions) and simplifying versioning, I would suggest to move this enum declaration in a private place and to update the doc not to mention ARGON2_OK.

argon2_compare - export

Hi,
I had been using argon2_compare as an exported function, but fcabf6f broke this.

The function is properly namespaced and I was wondering if this decision could be reviewed. I don't believe it's inappropriate for an external application to decide to use the low level argon2i(), which would followed by encode_string() (both of which are exported) and then argon2_compare().

Usage

I'm lost at the moment. I don't know how to produce a hash.

$ ./argon2-plain/argon2 lalala lalala -y 4
Error: unknown argument
$ ./argon2-plain/argon2 lalala lalala -y 4
Error: unknown argument
$ ./argon2-plain/argon2 lalala lalala -y 7
Error: unknown argument
$ ./argon2-plain/argon2 lalala lalala -t 3
Error: unknown argument
$ ./argon2-plain/argon2 lalala lalala     
Usage:  ./argon2-plain/argon2 pwd salt [-y version] [-t t_cost] [-m m_cost] [-l #lanes] [-p #threads]
Options:
        -y version      Argon2 version, either d or i (default)
        -t t_cost       Number of rounds to t_cost between 1 and 2^24, default 3
        -m m_cost       Memory usage of 2^t_cost kibibytes, default 12]
        -p N            Parallelism, default 4
$ ./argon2-plain/argon2 lalala lalala adsf
Error: unknown argument
$ ./argon2-plain/argon2 lalala lalala -m 44
Error: unknown argument
$ ./argon2-plain/argon2 lalala lalala -m 44 -l 213
Error: unknown argument
$ ./argon2-plain/argon2 lalala lalala -m 44 -l 21 
Error: unknown argument
$ ./argon2-plain/argon2 lalala lalala -m 44 -l 2 
Error: unknown argument
$ ./argon2-plain/argon2 lalala lalala -m 44 -l 2 -p 123
Error: unknown argument
$ ./argon2-plain/argon2 lalala lalala -m 44 -l 2 -p 12 -t32
Error: unknown argument
$ ./argon2-plain/argon2 lalala salt_len? -m 44 -l 2 -p 12 -t32
Error: unknown argument
$ ./argon2-plain/argon2 lalala 2323 -m 44 -l 2 -p 12 -t32
Error: unknown argument
$ ./argon2-plain/argon2 asdfasdfasdfasdfasdfasdf adsfasdfasdfasdfasdfasdfs -m 44 -l 2 -p 12 -t32
Error: unknown argument
$ ./argon2-plain/argon2 asdfasdfasdfasdfasdfasdf adsfasdfasdfasdfasdfasdfs -m 44 -l 2 -p 12 -t 32
Error: unknown argument
$ ./argon2-plain/argon2 lalala 2323 -m 5                 
Error: unknown argument
$ ./argon2-plain/argon2 lalala 2323     
Usage:  ./argon2-plain/argon2 pwd salt [-y version] [-t t_cost] [-m m_cost] [-l #lanes] [-p #threads]
Options:
        -y version      Argon2 version, either d or i (default)
        -t t_cost       Number of rounds to t_cost between 1 and 2^24, default 3
        -m m_cost       Memory usage of 2^t_cost kibibytes, default 12]
        -p N            Parallelism, default 4
$ ./argon2-plain/argon2 lalala     
Usage:  ./argon2-plain/argon2 pwd salt [-y version] [-t t_cost] [-m m_cost] [-l #lanes] [-p #threads]
Options:
        -y version      Argon2 version, either d or i (default)
        -t t_cost       Number of rounds to t_cost between 1 and 2^24, default 3
        -m m_cost       Memory usage of 2^t_cost kibibytes, default 12]
        -p N            Parallelism, default 4
$ ./argon2-plain/argon2       
Usage:  ./argon2-plain/argon2 pwd salt [-y version] [-t t_cost] [-m m_cost] [-l #lanes] [-p #threads]
Options:
        -y version      Argon2 version, either d or i (default)
        -t t_cost       Number of rounds to t_cost between 1 and 2^24, default 3
        -m m_cost       Memory usage of 2^t_cost kibibytes, default 12]
        -p N            Parallelism, default 4
$ ./argon2-plain/argon2 abcdef abcdefg
Usage:  ./argon2-plain/argon2 pwd salt [-y version] [-t t_cost] [-m m_cost] [-l #lanes] [-p #threads]
Options:
        -y version      Argon2 version, either d or i (default)
        -t t_cost       Number of rounds to t_cost between 1 and 2^24, default 3
        -m m_cost       Memory usage of 2^t_cost kibibytes, default 12]
        -p N            Parallelism, default 4

wishlist: compile test before publishing

commit 1e68573 introduced a new function argon2_compare()
to avoid memcmp().
If such a substitution is reasonable and good may be arguable, but it should be at least compilable.
As a system security related project there should be at least compile tests before publishing.

make test failed with clang

clang: error: unsupported argument 'undefined' to option 'fsanitize='

i just remove "-fsanitize=address -fsanitize=undefined" on Makefile test: and its ok.

Improper initialization of ctx in argon2_verify?

Hi,

I’ve run into a very weird test failure that sadly only happens in CI: https://travis-ci.org/hynek/argon2_cffi/jobs/104569433 : Secret pointer is NULL, but secret length is not 0

(please ignore and forgive the super-confusing naming; hash_secret is simply the generic hashing function in my bindings. When I decided on the name I didn’t realize that what you call key in the paper is called secret in the bindings. And just hash is a built-in function in Python which I didn’t want to shadow.)

Squinting at the code, it seems like verify relies on ctx being 0-initialized which you usually can’t for regular lokal variables?

The hash function on the other hand does it properly and initializes all ctx fields: https://github.com/P-H-C/phc-winner-argon2/blob/master/src/argon2.c#L203-L204

So my guess is I’ve accidentally triggered an incomplete initialization bug? A memset(0) should be enough I guess.

Implications of http://eprint.iacr.org/2016/027

What are the implications of http://eprint.iacr.org/2016/027? Should we wait for Argon3?

Insecure defaults

I (and most practical security people) very much dislike the idea of insecure defaults. A developer who doesn't know what a salt is, is going to use zero byte salts all the way. If you provide this as a default, developers will use it. If you say zero bytes are default, a developer thinks "well, if argon2 says that's default it can't be bad, right?". If you don't believe me, here's a blog post about something similar that we often enough in the wild: http://www.modzero.ch/modlog/archives/2011/11/04/the_apple_idioten_vektor_iv/index.html

Now you still have the chance to change this interface. Later on you might have all this backward-compatibility stuff to handle.

I propose two options:

Random salt generation and showing it to the user. I see that this might lead to the question of secure random entropy source for different plattforms etc., so might not be the best option
Make -s a mandatory option and exit with non zero exit code

Same for password. Can you imagine what happens if a developer blindly compares two outputs of argon2 to check if a password is correct and forgets to specify the -p parameter for both invocations? Every password will work (as argon2 will use "password" for every run).

Compiling in VS 2015 as C++

Microsoft seems to have two specific beefs with the code as it exists now. Everything else compiles without warning or issue:

1 encoding.c, the definition for EQ(x, y), throws C4146 which prevents compilation
https://msdn.microsoft.com/query/dev14.query?appId=Dev14IDEF1&l=EN-US&k=k(C4146)&rd=true
In order to compile the code I suppress the warning each time it comes up, as I don't know a way around this.

#pragma warning(suppress: 4146)

2 encoding.c, the definition for SX(x) uses sprintf which Microsoft deems unsafe (and prevents compilation), so they recommend using sprintf_s which includes a buffer length (4 parameters instead of 3) to allow for safety checks inside the function itself. Easy fix.

#define SX(x) \ do { \ char tmp[30]; \ sprintf_s(tmp, 30, "%lu", (unsigned long)(x)); \ SS(tmp); \ } while (0)

Doesn't compile on ARM

gcc -std=c99 -pthread -O3 -Wall src/argon2.c src/argon2-core.c src/kat.c src/blake2/blake2b-ref.c src/argon2-ref-core.c src/argon2-test.c -Isrc  -o argon2
src/argon2-test.c: In function 'run':
src/argon2-test.c:189:9: warning: implicit declaration of function 'strdup' [-Wimplicit-function-declaration]
         in = ( uint8_t * )strdup( pwd );
         ^
src/argon2-test.c: In function 'benchmark':
src/argon2-test.c:40:5: error: impossible constraint in 'asm'
     __asm__ __volatile__ ( "rdtsc" : "=a" ( rax ), "=d" ( rdx ) : : );
     ^
src/argon2-test.c:40:5: error: impossible constraint in 'asm'
     __asm__ __volatile__ ( "rdtsc" : "=a" ( rax ), "=d" ( rdx ) : : );
     ^
src/argon2-test.c:40:5: error: impossible constraint in 'asm'
     __asm__ __volatile__ ( "rdtsc" : "=a" ( rax ), "=d" ( rdx ) : : );
     ^

System:

$ uname -a
Linux odroid-003 3.8.13.23 #1 SMP PREEMPT Tue Jun 10 14:54:36 UTC 2014 armv7l armv7l armv7l GNU/Linux

A configure script would be nice. The code doesn't honor $CC.

Compilation Errors on VS 2010

Hi,

it’s I, from the computer museum. :)

This time it’s about Python 3.3 and 3.4 that require VS 2010 for their extensions.

I have set up appveyor to test that (might be worth considering for you too, it seems impossible to keep up with all the versions?) and apart of requiring msinttypes, I’m getting this error: https://ci.appveyor.com/project/hynek/argon2-cffi/build/job/dd4l714s6u6g1b9w

For posterity:

c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\BIN\cl.exe /c /nologo /Ox /MD /W3 /GS- /DNDEBUG -Iextras/libargon2/src -Iextras/libargon2/src/blake2 -Iextras/msinttypes /Tcextras/libargon2/src/argon2.c /Fobuild\temp.win32-3.3\extras/libargon2/src/argon2.obj
argon2.c
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(138) : error C2143: syntax error : missing ')' before '*' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(138) : error C2143: syntax error : missing '{' before '*'
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(138) : warning C4142: benign redefinition of type 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(138) : error C2370: 'size_t' : redefinition; different storage class 
        c:\program files (x86)\microsoft visual studio 10.0\vc\include\codeanalysis\sourceannotations.h(29) : see declaration of 'size_t' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(138) : error C2146: syntax error : missing ';' before identifier 'bytes_to_allocate' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(138) : error C2059: syntax error : ')' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(139) : error C2143: syntax error : missing ')' before '*'
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(139) : error C2143: syntax error : missing '{' before '*'
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(139) : error C2040: 'memory' : 'int *' differs in levels of indirection from 'int **' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(139) : warning C4142: benign redefinition of type 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(139) : error C2370: 'size_t' : redefinition; different storage class
        c:\program files (x86)\microsoft visual studio 10.0\vc\include\codeanalysis\sourceannotations.h(29) : see declaration of 'size_t'
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(139) : error C2146: syntax error : missing ';' before identifier 'bytes_to_allocate'
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(139) : error C2059: syntax error : ')'
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(168) : error C2016: C requires that a struct or union has at least one member 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(168) : error C2061: syntax error : identifier 'uint8_t'
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(169) : error C2061: syntax error : identifier 'outlen' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(169) : error C2059: syntax error : ';'
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(171) : error C2143: syntax error : missing '{' before '*' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(172) : error C2061: syntax error : identifier 'pwdlen' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(172) : error C2059: syntax error : ';' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(174) : error C2143: syntax error : missing '{' before '*' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(175) : error C2061: syntax error : identifier 'saltlen' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(175) : error C2059: syntax error : ';' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(177) : error C2143: syntax error : missing '{' before '*' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(178) : error C2061: syntax error : identifier 'secretlen' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(178) : error C2059: syntax error : ';' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(180) : error C2143: syntax error : missing '{' before '*' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(181) : error C2061: syntax error : identifier 'adlen' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(181) : error C2059: syntax error : ';' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(183) : error C2061: syntax error : identifier 't_cost'
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(183) : error C2059: syntax error : ';' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(184) : error C2061: syntax error : identifier 'm_cost'
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(184) : error C2059: syntax error : ';'
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(185) : error C2061: syntax error : identifier 'lanes' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(185) : error C2059: syntax error : ';'
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(186) : error C2061: syntax error : identifier 'threads' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(186) : error C2059: syntax error : ';' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(188) : error C2061: syntax error : identifier 'allocate_cbk' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(188) : error C2059: syntax error : ';' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(189) : error C2061: syntax error : identifier 'free_cbk' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(189) : error C2059: syntax error : ';' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(191) : error C2061: syntax error : identifier 'flags' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(191) : error C2059: syntax error : ';'
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(192) : error C2059: syntax error : '}' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(212) : error C2146: syntax error : missing ')' before identifier 't_cost' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(212) : error C2061: syntax error : identifier 't_cost' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(212) : error C2059: syntax error : ';' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(212) : error C2059: syntax error : ',' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(216) : error C2059: syntax error : ')' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(232) : error C2146: syntax error : missing ')' before identifier 't_cost' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(232) : error C2061: syntax error : identifier 't_cost' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(232) : error C2059: syntax error : ';' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(232) : error C2059: syntax error : ',' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(235) : error C2059: syntax error : ')' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(237) : error C2146: syntax error : missing ')' before identifier 't_cost' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(237) : error C2061: syntax error : identifier 't_cost' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(237) : error C2059: syntax error : ';' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(237) : error C2059: syntax error : ',' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(241) : error C2059: syntax error : ')' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(243) : error C2146: syntax error : missing ')' before identifier 't_cost'
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(243) : error C2061: syntax error : identifier 't_cost' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(243) : error C2059: syntax error : ';' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(243) : error C2059: syntax error : ',' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(246) : error C2059: syntax error : ')' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(249) : error C2146: syntax error : missing ')' before identifier 't_cost' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(249) : error C2061: syntax error : identifier 't_cost' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(249) : error C2059: syntax error : ';' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(249) : error C2059: syntax error : ',' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(253) : error C2059: syntax error : ')' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(276) : error C2143: syntax error : missing ')' before '*'
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(276) : error C2143: syntax error : missing '{' before '*'
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(276) : error C2059: syntax error : ')'
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(286) : error C2143: syntax error : missing ')' before '*'
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(286) : error C2143: syntax error : missing '{' before '*' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(286) : error C2059: syntax error : ')' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(293) : error C2143: syntax error : missing ')' before '*' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(293) : error C2143: syntax error : missing '{' before '*'
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(293) : error C2059: syntax error : ')' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(301) : error C2143: syntax error : missing ')' before '*' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(301) : error C2143: syntax error : missing '{' before '*' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(301) : error C2059: syntax error : ')'
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(311) : error C2143: syntax error : missing ')' before '*' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(311) : error C2143: syntax error : missing '{' before '*'
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(311) : error C2059: syntax error : ')' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(320) : error C2143: syntax error : missing ')' before '*' 
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(320) : error C2143: syntax error : missing '{' before '*'
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(320) : error C2059: syntax error : 'type'
c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(320) : error C2059: syntax error : ')'
c:\projects\argon2-cffi\extras\libargon2\src\encoding.h(5) : error C2143: syntax error : missing ')' before '*' 
c:\projects\argon2-cffi\extras\libargon2\src\encoding.h(5) : error C2081: 'argon2_context' : name in formal parameter list illegal
c:\projects\argon2-cffi\extras\libargon2\src\encoding.h(5) : error C2143: syntax error : missing '{' before '*'
c:\projects\argon2-cffi\extras\libargon2\src\encoding.h(6) : error C2370: 'argon2_type' : redefinition; different storage class
        c:\projects\argon2-cffi\extras\libargon2\src\argon2.h(195) : see declaration of 'argon2_type'
c:\projects\argon2-cffi\extras\libargon2\src\encoding.h(6) : error C2146: syntax error : missing ';' before identifier 'type'
c:\projects\argon2-cffi\extras\libargon2\src\encoding.h(6) : error C2059: syntax error : ')'
c:\projects\argon2-cffi\extras\libargon2\src\encoding.h(8) : error C2143: syntax error : missing ')' before '*'
c:\projects\argon2-cffi\extras\libargon2\src\encoding.h(8) : error C2143: syntax error : missing '{' before '*'
c:\projects\argon2-cffi\extras\libargon2\src\encoding.h(8) : error C2059: syntax error : 'type'
c:\projects\argon2-cffi\extras\libargon2\src\encoding.h(8) : error C2059: syntax error : ')'
c:\projects\argon2-cffi\extras\libargon2\src\core.h(57) : error C2016: C requires that a struct or union has at least one member
c:\projects\argon2-cffi\extras\libargon2\src\core.h(57) : error C2061: syntax error : identifier 'uint64_t'
c:\projects\argon2-cffi\extras\libargon2\src\core.h(57) : error C2059: syntax error : '}'
c:\projects\argon2-cffi\extras\libargon2\src\core.h(62) : error C2143: syntax error : missing ')' before '*'
c:\projects\argon2-cffi\extras\libargon2\src\core.h(62) : error C2143: syntax error : missing '{' before '*'
c:\projects\argon2-cffi\extras\libargon2\src\core.h(62) : fatal error C1003: error count exceeds 100; stopping compilation
error: command '"c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\BIN\cl.exe"' failed with exit status 2

I’m sorry once again. :(

switch from CC0 license to something more common?

Currently, the repository is licensed under CC0. As per https://github.com/blog/1964-open-source-license-usage-on-github-com (specifically https://cloud.githubusercontent.com/assets/282759/6517300/9dc14536-c367-11e4-9a63-b23a3d75af78.png), this is a very unusual license to use for code.

You can also search through the Debian archive and see that not many packages have code (!) (as opposed to artwork, documentation, etc.) that’s licensed under CC0: https://codesearch.debian.net/perpackage-results/file%3Adebian%2Fcopyright%20CC0/2/page_0

I know of at least one big company where the internal guidelines require special approval for making use of CC0. One of the issues apparently seems to be section 2 of the CC0 license, where contributors waive all rights.

I think it’d be good to license the code under a more common license, so that it can be more easily adopted by distributions, enterprises and individuals alike.

What do you think?

Thank you for considering.

Output differs from README

Hi,

Documentation contains this line:

$ ./argon2 password somesalt -t 2 -m 16 -p 4
Type: Argon2i
Iterations: 2
Memory: 65536 KiB
Parallelism: 4
$argon2i$m=65536,t=2,p=4$c29tZXNhbHQAAAAAAAAAAA$QWLzI4TY9HkL2ZTLc8g6SinwdhZewYrzz9zxCo0bkGY
0.274 seconds

However, I'm seeing this:
$ ./argon2 password somesalt -t 2 -m 16 -p 4
Type: Argon2i
Iterations: 2
Memory: 65536 KiB
Parallelism: 4
Hash: 4162f32384d8f4790bd994cb73c83a4a29f076165ec18af3cfdcf10a8d1b9066
0.269 seconds

Can you confirm the expected output?

More importantly, can you confirm if "out" from hash_argon2i is supposed to be an encoded string, or if developers still need to manage this?

Edit: I note the existence of the commented encode_string function, however, its prototype suggests it can only be accessed if a user calls the low level API. But a user of the high level API would stand more to gain from an automatically encoded string.

Optimisations fail to build on powerpc64le

Hi,

I've tried to build argon2 with optimisations on powerpc64le, and I am hitting a compile failure:

dja@dja-builder ~/f/phc-winner-argon2> uname -a
Linux dja-builder 4.2.0-30-generic #35-Ubuntu SMP Fri Feb 19 13:50:54 UTC 2016 ppc64le ppc64le ppc64le GNU/Linux
dja@dja-builder ~/f/phc-winner-argon2> env OPT=TRUE make
rm -f argon2 bench genkat
rm -f libargon2.so libargon2.a kat-argon2* 
rm -f testcase
rm -rf *.dSYM
cd src/ && rm -f *.o
cd src/blake2/ && rm -f *.o
cd kats/ &&  rm -f kat-* diff* run_* make_*
cc -std=c89 -pthread -O3 -Wall -g -Iinclude -Isrc -march=native  src/argon2.c src/core.c src/blake2/blake2b.c src/thread.c src/encoding.c src/opt.c src/run.c -o argon2
cc: error: unrecognized command line option ‘-march=native’
Makefile:75: recipe for target 'argon2' failed
make: *** [argon2] Error 1

This is due to powerpc gcc not supporting -march. We do have -mcpu and -mtune, which could be used instead. However, if I change -march to -mcpu, I get other problems:

In file included from src/opt.c:19:0:
src/opt.h:18:23: fatal error: emmintrin.h: No such file or directory
compilation terminated.

It looks like you're using Intel intrinsics, meaning that your optimised code would only ever compile on Intel. Is that right?

If so, would it be possible to make OPT=TRUE behave differently on platforms other than x86? For example:

x86: -march and intrinsics
other platforms supporting -march: -march and reference code
other platforms supporting -mcpu: -mcpu and reference code
other platforms supporting neither: reference code only

I'm happy to help with compiler flag detection macros or anything else if that would help.

m_cost >= #lanes breaking tests

make test fails after fc21985, apparently because test cases include invalid combinations of parameters.

Small values for memory cost allow to create hashes that can’t be verified

While playing with the parameters (mainly to get fast hashes for unit tests), I’ve run into a problem where argon2 will happily create a hash but fail to verify it:

$ echo -n "password" | ./argon2 somesalt -t 1 -m 3 -p 2
Type:       Argon2i
Iterations: 1
Memory:     8 KiB
Parallelism:    2
Hash:       b53b9d234b12abfe90ad7866cb8f494dd1b07d48022f17fa8c6029c68a1805a1
Encoded:    $argon2i$m=8,t=1,p=2$c29tZXNhbHQAAAAAAAAAAA$tTudI0sSq/6QrXhmy49JTdGwfUgCLxf6jGApxooYBaE
0.001 seconds
Error: Decoding failed

Setting parallelism down to 1 fixes it FWIW.

I’m not smart enough to deduce from your paper why that is, but maybe it should be documented and/or the hash shouldn’t be created in the first place.

No src/encoding.h

Greetings!

README mentions src/encoding.h file, but phc-winner-argon2 lacks it.

Stable libargon2.so interface?

I'm in the process of packaging libargon2 for Debian, and it looks like libargon2.so doesn't declare any soname.

I'm currently adding a local soname to the library, but for compatibility reasons it would be better if proper soname versioning is introduced directly here (upstream).

Do you consider the libargon2 library API/ABI stable enough to start adding a soname and tracking compatibility, so that it can be safely installed and provided system-wide?

Crashing clang?

It's late and this makes me feel like I should seriously go to bed. Anyway, of course you can just close it as "clang bug", but could someone try to reproduce? It happens on my Xubuntu VM when I run a "normal" make where gcc was replaced with clang

$ /usr/bin/clang -cc1 -triple i386-pc-linux-gnu -emit-obj -disable-free -disable-llvm-verifier -main-file-name main.c -mrelocation-model static -fmath-errno -masm-verbose -mconstructor-aliases -fuse-init-array -target-cpu pentium4 -target-linker-version 2.24 -momit-leaf-frame-pointer -g -resource-dir /usr/bin/../lib/clang/3.4 -I src -internal-isystem /usr/local/include -internal-isystem /usr/bin/../lib/clang/3.4/include -internal-externc-isystem /usr/bin/../lib/gcc/i686-linux-gnu/4.8/include -internal-externc-isystem /usr/include/i386-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -O3 -Wall -std=c99 -fdebug-compilation-dir /opt/argon2/argon2-plain -ferror-limit 19 -fmessage-length 270 -pthread -mstackrealign -fobjc-runtime=gcc -fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize-slp -o /tmp/main-a05e76.o -x c src/main.c 
src/main.c:204:27: warning: implicit declaration of function 'strdup' is invalid in C99 [-Wimplicit-function-declaration]
        in = ( uint8_t * )strdup( pwd );
                          ^
0  libLLVM-3.4.so.1 0xb6d1150f llvm::sys::PrintStackTrace(_IO_FILE*) + 47
1  libLLVM-3.4.so.1 0xb6d1177f
2  libLLVM-3.4.so.1 0xb6d112ec
3                   0xb77a5400 __kernel_sigreturn + 0
4  libLLVM-3.4.so.1 0xb6bcfa83
5  libLLVM-3.4.so.1 0xbf8238cc
6  libLLVM-3.4.so.1 0xb6bdeb63
7  libLLVM-3.4.so.1 0xb6bdf19f llvm::SelectionDAG::LegalizeTypes() + 943
8  libLLVM-3.4.so.1 0x0a3f348c llvm::SelectionDAG::LegalizeTypes() + 1400981148
Stack dump:
0.  Program arguments: /usr/bin/clang -cc1 -triple i386-pc-linux-gnu -emit-obj -disable-free -disable-llvm-verifier -main-file-name main.c -mrelocation-model static -fmath-errno -masm-verbose -mconstructor-aliases -fuse-init-array -target-cpu pentium4 -target-linker-version 2.24 -momit-leaf-frame-pointer -g -resource-dir /usr/bin/../lib/clang/3.4 -I src -internal-isystem /usr/local/include -internal-isystem /usr/bin/../lib/clang/3.4/include -internal-externc-isystem /usr/bin/../lib/gcc/i686-linux-gnu/4.8/include -internal-externc-isystem /usr/include/i386-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -O3 -Wall -std=c99 -fdebug-compilation-dir /opt/argon2/argon2-plain -ferror-limit 19 -fmessage-length 270 -pthread -mstackrealign -fobjc-runtime=gcc -fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize-slp -o /tmp/main-a05e76.o -x c src/main.c 
1.  <eof> parser at end of file
2.  Code generation
3.  Running pass 'Function Pass Manager' on module 'src/main.c'.
4.  Running pass 'X86 DAG->DAG Instruction Selection' on function '@benchmark'
Segmentation fault (core dumped)

$ clang --version
Ubuntu clang version 3.4-1ubuntu3 (tags/RELEASE_34/final) (based on LLVM 3.4)
Target: i386-pc-linux-gnu
Thread model: posix

$ cat /etc/*release*
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=14.04
DISTRIB_CODENAME=trusty
DISTRIB_DESCRIPTION="Ubuntu 14.04.3 LTS"
NAME="Ubuntu"
VERSION="14.04.3 LTS, Trusty Tahr"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 14.04.3 LTS"
VERSION_ID="14.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"

AppVeyor needs a Visual Studio project or solution file

self-explanatory

Functions declared but not defined

The following functions are declared in argon2.h, but they are not defined in argon2.c:
int argon2di_ctx(argon2_context *context); int argon2ds_ctx(argon2_context *context); int argon2id_ctx(argon2_context *context);

I see 2 options:

we remove them from argon2.h
we add implementations for them in argon2.c that return an error code ARGON2_TYPE_NOT_SUPPORTED

Opinions?

Elaborate a bit on when to use Argon2i vs. Argon2d

This thread on Hacker News calls out an enlightening part of the IETF draft to explain when to use Argon2i vs. Argon2d:

Argon2d is faster and
uses data-depending memory access, which makes it suitable for
cryptocurrencies and applications with no threats from side-channel
timing attacks. Argon2i uses data-independent memory access, which
is preferred for password hashing and password-based key derivation.
Argon2i is slower as it makes more passes over the memory to protect
from tradeoff attacks.

Does it make sense to add this to the README? The README currently reads:

Argon2i is the safest against side-channel attacks, while Argon2d provides the highest resistance against GPU cracking attacks.

I don't know if the intended audience for this library is expected to understand the different use cases from this description, but I found the extra explanation from the IETF draft on password hashing vs. cryptocurrencies helpful.

hash_encoded produces encodings that can't be verified

hash_encoded is validating input against #DEFINEs in argon2.h. However, decode_string is using its own validation which is different from these defines. For example, I can generate this hash: $argon2i$m=20000,t=1,p=475$QW4gKOKIniwx... - but I can't decode it because p=475, but decode_string checks:

    /*
     * The parallelism p must be between 1 and 255. The memory cost
     * parameter, expressed in kilobytes, must be at least 8 times
     * the value of p.
     */
    if (ctx->lanes < 1 || ctx->lanes > 255) {
        return 0;
    }

I imagine there are more problems in decode_string that just the p parameter.