First of all, thank you for taking the time to respond. It's good that the community has people activity discussing these topics. Also, btw, I found a similar thread (while looking for something else at :
https://nxtforum.org/nxt-improvement-proposals/password-derivation-option/ )
Quick summary of this post: There is nothing alarming here, but I think it could be improved slightly.
Still here?
Details:
As for the 128bit strength of the crypto that was news to me, after reading more about ed25519, it seems as though 2^128 is the target strength but actually it has about 2^140 to the best of our knowledge. (Curious if i'm reading that correctly or still missing something)
_http://ed25519.cr.yp.to/
High security level. This system has a 2^128 security target; breaking it has similar difficulty to breaking NIST P-256, RSA with ~3000-bit keys, strong 128-bit block ciphers, etc. The best attacks known actually cost more than 2^140 bit operations on average, and degrade quadratically in success probability as the number of bit operations drops.
Also, for the browsers who support windows.crypto.getRandomValues, we just read that data in directly... people with their tin foil hats on may be uncomfortable with that.
I think the best approach would be to utilize the SJCL library at: _https://github.com/bitwiseshiftleft/sjcl/blob/master/core/random.js
This library already has coded in the collection of entropy from:
1. Mouse movement
2. Keypress
3. Page Load Stats
4. Date
5. Window.crypto.getRandomValues as entropy source (if available)
Additionally it keeps track of how much entropy it has and will only provide values that are safe. So, this takes care of all of my concerns in the original post about collecting enough entropy properly. Also, it takes care of the tin foil hat guys around using getRandomValues directly as well as my concern that in any given browser it could have some kind of weakness.
Finally, targeting 160, or even better 256 bits of entropy in the passphrase is just extra insurance that if for some reason a weakness was found in the sjcl prng that takes it from 2^n -> 2^n/2 we would still be okay because our implementation targeted a much higher than needed entropy.
The implementation on the NXT client side would simply be:
<pseudo code>
var prng = new sjcl.random(256 bits)
prng.startCollection()
... Wait until prng.isReady
var random = prng.getRandomValues(256 bits)
generatePhraseFromRandom(random) // just a straight translation from bits to words.
All that being said I'm not sure if any of these reasons are enough to go back and makes changes at this point in time as there is so much to do. But maybe at some point these changes can be made.
As far as the current implementation, I'd be willing to go in and add comments to the existing code that incorporates much of what we have talked about here so future reviewers can have this information inline. Not sure how to go about doing that though.
================ Sending to (non verified?) NXT Account =====================
Auto registering of an account is a great idea. However, that still doesn't stop someone from sending money to an account id that hasn't been verified. If not a warning, just flat out don't allow it. People who want to go around that can use the API directly.