Quote from: otila on October 07, 2014, 10:06:28 PM

Quote from: jl777 on October 07, 2014, 09:50:52 PM

i am just offering a choice
i notice that people tend to feel quite strongly about which cipher is better and i prefer to avoid getting involved in such debates
my method allows people to choose their cipher (or cipher sequence)
the code is still not debugged yet, I just wrote the MofNfs calls yesterday, really as a good way to test the DHT calls I coded over the weekend.

is there a C library for the key derivation?

If you let users pick from ten options, they pick the best one in 10% of the cases Grin

https://password-hashing.net/candidates.html
Source code in C and specs in pdf.
Candidates support same kind of calling convention, but this competition is still a work-in-progress.
PHS(K, kLen, pwd, pwdLen, salt, saltLen, t_cost, m_cost))

These things are being discussed on Usenet group comp.security.phc
http://dir.gmane.org/gmane.comp.security.phc

EDIT: related a bit, maybe gives you ideas https://minilock.io/

i doubt many users will be invoking the SuperNET API from command line. So the GUI designer can choose which cipher to use, etc. Let us hope the GUI designers have a better chance than 10%

that minilock looks really cool! No reason it cant be done in the GUI and then the save/restore calls would be with already encrypted data, so no need to use the built in encryption.

I already have the libtom and nacl libs integrated so just allowing API access to it, nothing forces people to use any of these 18 ciphers if they dont want to.

Anyway, thanks for the URLs

James