Add support for argon2i

[mankyd]

As #1 suggests, this code currently implements argon2d. Per the argon2 website:

https://www.cryptolux.org/index.php/Argon2

Argon2 has two variants: Argon2d and Argon2i. 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.

It would be great to have an argon2i implementation.

[tuxxy]

Any status on this? I'd like to use this for my password locker app, but if I can't get a pure golang implementation, then I'll stick with bcrypt for the time being.

[magical]

Hi! Thanks for your interest in this project. I'm definitely interested in adding Argon2i. I actually played with an argon2i implementation a while ago, but i never pushed it because i wasn't sure about the API. While it would make a lot of sense implementation-wise to have argon2d and argon2i share a package, i think that doing so would lead to an ugly interface. What would you call the functions? Would you have argon2.Key_i and argon2.Key_d? Make argon2.Key take a type parameter? Most applications probably want one or the other, not both. It would be a lot cleaner to have two separate packages imo, so you'd have argon2d.Key and argon2i.Key. Nevertheless! I'm not totally sure, and would love to hear other opinions.

Also, as an aside, i've been busy with school for the past few months so i haven't really had time to work on this. Since it appears there's still interest, i'll try to devote some time to it this summer.

[tuxxy]

Thanks for the response!

In my opinion, I feel that two separate packages might be best for the time being. I can see a point in the future when you might want to combine them in the latter manner you described. Perhaps when Argon2 as a whole matures a bit more and this implementation is more stable.
That’s just my two cents. Keep up the good work, though!

On May 26, 2016, at 01:21, Andrew Ekstedt notifications@github.com wrote:

Hi! Thanks for your interest in this project. I'm definitely interested in adding Argon2i. I actually played with an argon2i implementation a while ago, but i never pushed it because i wasn't sure about the API. While it would make a lot of sense implementation-wise to have argon2d and argon2i share a package, i think that doing so would lead to an ugly interface. What would you call the functions? Would you have argon2.Key_i and argon2.Key_d? Make argon2.Key take a type parameter? Most applications probably want one or the other, not both. It would be a lot cleaner to have two separate packages imo, so you'd have argon2d.Key and argon2i.Key. Nevertheless! I'm not totally sure, and would love to hear other opinions.

Also, as an aside, i've been busy with school for the past few months so i haven't really had time to work on this. Since it appears there's still interest, i'll try to devote some time to it this summer.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub #2 (comment)