Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve key stretching (KDF) with new algorithms #214

Closed
jaromil opened this issue Aug 12, 2015 · 6 comments
Closed

Improve key stretching (KDF) with new algorithms #214

jaromil opened this issue Aug 12, 2015 · 6 comments
Assignees
Labels
feat wish feature we wish someone would refine and implement
Milestone

Comments

@jaromil
Copy link
Member

jaromil commented Aug 12, 2015

Lets take the good work done at PHC for a start

https://password-hashing.net

The winner is Argon2 with a reference implementation in C and a SSE optimized one
https://github.com/khovratovich/Argon2

also the rest of the applicants are very interesting.

I think it would be really nice to open up the choice for anyone using Tomb to pick an algorithm for KDF, this will protect us from one of the biggest vulnerabilities at the moment, that of key theft and bruteforcing which even in absence of the actual tomb could help attackers to discover a memorized password.

@jaromil jaromil added feat wish feature we wish someone would refine and implement labels Aug 12, 2015
@boyska
Copy link
Member

boyska commented Sep 15, 2015

several of them are interesting. From a quick read, I see that "Catena" claims to be resistant to cache timing attacks and other side channels, which is certainly a con. I think that the correct thing here is to write/extend/package simple programs that implement those algorithms outside of tomb. (Yes, I partly regret creating a only-for-tomb pbkdf-sha1 wrapper, I should have worked on a pbkdf2 tool on its own)

@Narrat
Copy link
Contributor

Narrat commented Jan 7, 2018

Just informal. Argon2 development seems to happen in the PHC repo. At least repo packages of Argon2 set this as upstream and active development happens there

@jaromil
Copy link
Member Author

jaromil commented Jan 8, 2018

Yep. I am ready to move into extras the implementation from monocypher, which I like very much since its very minimal and of course uses no dynamic memory allocation. I'm already familiar with it, using it in another project https://github.com/philanc/luazen/blob/9ce4c96cffa1f3b5ed2d2603f71d3699474de5cd/src/mono.c

@jaromil jaromil added this to the 3.0 milestone Sep 23, 2018
@jaromil jaromil self-assigned this Sep 23, 2018
@D-Nice
Copy link

D-Nice commented Dec 4, 2019

would love to see argon2 as an option or default going forward

@nerun
Copy link
Contributor

nerun commented Jan 13, 2024

Close it?

It's 2024, Tomb v2.10, --kdftype argon2 and --kdfmem 18 (default value) are a reality. I imagine that argon2i is the default (just RAM usage).

Alternatives?

Maybe add Argon2d or Argon2id as alternatives? Just thinking, argon2i is very fast compared to --kdftype pbkdf2 --kdf 15.

Tomb argon2 really works?

I am ok with --kdftype argon2 --kdfmem 24, which in thesis uses 2^24 = 16 GB RAM. I don't know if it really works, but it's so fast even with --kdfmem 25 (32 GB).

When i use argon2 direct in terminal:

$ echo "password" | argon2 'stupidsalt' -m 18
0.511 seconds

But with 24 it takes an eternity:

$ echo "password" | argon2 'stupidsalt' -m 24
37.384 seconds

That's why i think is something wrong with --kdftype argon2 --kdfmem 24: it's too much fast.

@nerun
Copy link
Contributor

nerun commented Jan 13, 2024

Tomb argon2 really works? - Part 2

Sorry my fault, argon2 do works, but MUST provide --kdf too:

$ time sudo tomb -f --kdftype argon2 --kdfmem 24 forge teste.tomb.key
0,01s user 0,00s system 0% cpu 2,597 total

$ time sudo tomb -f --kdf 3 --kdftype argon2 --kdfmem 24 forge teste.tomb.key
0,00s user 0,01s system 0% cpu 38,647 total

kdf 3 is the default for argon2 (where iterations -t defaults to 3).

What Tomb need is to defaults --kdf to 3 if user forget to provide kdf iterations number.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feat wish feature we wish someone would refine and implement
Projects
None yet
Development

No branches or pull requests

5 participants