I have noticed the compile error for the "SSE2 instruction set" for some computers.
This seems to be related to the physical machine that is used.
Argon2 is optimized for the x86 architecture, and this is the cause of the compile error.
I have three Ubuntu 14.04 machines, and the two 64-bit machines compile the source without errors, one Intel and one AMD machine.
But the older 32 bit machine with an Intel Atom processor get the compile error.
I will fix this.
Yes, Bitgen is currently using Argon2d (and not Argon2i), but the choice was not an easy one.
The choice of the "d" version instead of "i" was motivated since a dedicated machine without any internet connection should not have any side-channels for timing attacks(?)
For example, on a shared Linux-machine were several persons are logged in at the same time there will be possible to use side-channels when someone is changing a password.
I also interpret "being faster" as positive regarding ASIC-resistance.
If it is faster on a normal PC, it will perform better compared to a dedicated ASIC hardware.
The parameters for the "hardness" of the Argon2 function have been choose so it will take about 10 seconds to perform the key derivation.
Here are the choosen parameters:
const unsigned t_cost = 5;
const unsigned m_cost = 100000;
const unsigned thr = 8;
However, it is not too late to change if there is enough reason to do so.
I have to update the documentation, will be done in the next release.
This seems to be related to the physical machine that is used.
Argon2 is optimized for the x86 architecture, and this is the cause of the compile error.
I have three Ubuntu 14.04 machines, and the two 64-bit machines compile the source without errors, one Intel and one AMD machine.
But the older 32 bit machine with an Intel Atom processor get the compile error.
I will fix this.
Yes, Bitgen is currently using Argon2d (and not Argon2i), but the choice was not an easy one.
The choice of the "d" version instead of "i" was motivated since a dedicated machine without any internet connection should not have any side-channels for timing attacks(?)
For example, on a shared Linux-machine were several persons are logged in at the same time there will be possible to use side-channels when someone is changing a password.
I also interpret "being faster" as positive regarding ASIC-resistance.
If it is faster on a normal PC, it will perform better compared to a dedicated ASIC hardware.
The parameters for the "hardness" of the Argon2 function have been choose so it will take about 10 seconds to perform the key derivation.
Here are the choosen parameters:
const unsigned t_cost = 5;
const unsigned m_cost = 100000;
const unsigned thr = 8;
However, it is not too late to change if there is enough reason to do so.
I have to update the documentation, will be done in the next release.
Hello there @bit22gen
How are you doing? Long time no talk...
You still around? Are you still coding for this project of yours sometimes?
Revisiting your project here made me think about what we discussed years ago about using different versions of Argon2 KDF algo.
I ended stepping on this project that also uses Argon2. It's a similar project that already did something like Warp Wallet (although they used the Argon2i version):
https://github.com/patcito/mindwallet
Just to clarify (from the famous Wikipedia):
Quote
Argon2 is a key derivation function that was selected as the winner of the Password Hashing Competition in July 2015. It was designed by Alex Biryukov, Daniel Dinu, and Dmitry Khovratovich from the University of Luxembourg. The reference implementation of Argon2 is released under a Creative Commons CC0 license (i.e. public domain) or the Apache License 2.0, and provides three related versions:
a) Argon2d maximizes resistance to GPU cracking attacks. It accesses the memory array in a password dependent order, which reduces the possibility of time–memory trade-off (TMTO) attacks, but introduces possible side-channel attacks.
b) Argon2i is optimized to resist side-channel attacks. It accesses the memory array in a password independent order.
c) Argon2id is a hybrid version. It follows the Argon2i approach for the first pass over memory and the Argon2d approach for subsequent passes. The Internet draft recommends using Argon2id except when there are reasons to prefer one of the other two modes.
a) Argon2d maximizes resistance to GPU cracking attacks. It accesses the memory array in a password dependent order, which reduces the possibility of time–memory trade-off (TMTO) attacks, but introduces possible side-channel attacks.
b) Argon2i is optimized to resist side-channel attacks. It accesses the memory array in a password independent order.
c) Argon2id is a hybrid version. It follows the Argon2i approach for the first pass over memory and the Argon2d approach for subsequent passes. The Internet draft recommends using Argon2id except when there are reasons to prefer one of the other two modes.
So maybe replacing the implemented Argon2d (used by bitgen) by Argon2id should be a reasonable decision in order to improve (even more) the security for brainwallets created by this tool.
What do you think about it?
