[ANN][BURST] Burst | Efficient HDD Mining | New 1.2.3 Fork block 92000

My password is a random string of numbers and letters, caps and no caps, 30 symbols long. So weak password is not an issue.

It's unlikely that the password was bruteforced, but I think 30 symbols doesn't provide maximum security.
Please correct me if I'm wrong: 256 bits are used in the hash, that's 32 bytes. But we aren't using the full 0-255 character range in passwords, so they should be much much longer. 26 (a-z) + 26 (A-Z) + 10 (numbers) = only 62 chars subset is used for passwords. Using words instead of random letters raises bruteforcing chances even more. The passwords need to be 4.2 times longer: at least 134 symbols!

You're on the right track, but your math is not quite right. If you choose a password from a set of 62 characters, then each character is providing 5.95 bits of entropy (ln(62) / ln(2)). So, if you want to achieve 256 bits of entropy, your password should be at least 43 characters long.

i have'nt looked into the code on how the pk is used to sign transactions but i think it is ecdh based.
doing a google search for the included java code from nxt to do the signing brought up a site stating the sign function is not as secure as the original code where it was ported from to java. this is because java uses different size integers and a c big int variable has only the maximum size of an unsigned int in java (https://gist.github.com/doctorevil/9521116).
someone with java knowledge maybe can verify that the described flaw applies or hopefully does'nt apply to the code in src/java/nxt/crypto/Curve25519.java file or finds out this whole function is only included due to forking reasons.

this in combination with the wallet which offers 12 words OUT OF 1626 by default (html/ui/js/crypto/passphrasegenerator.js) makes it in my opinion attackable.
within an bruteforce attack this is less than 11 bit for each word which sums up to about 105 bits of combinations.
if the ecdh implementation shows the mentioned flaw it cuts internal 256 bit variables at 64 bit.
without further analysis this provides a option to bruteforce wallet generated keys by software designed to utilize this flaw by testing less than 32 bit of combinations. i am no crypto specialist and if someone with knowledge about all this could take a look into it would be great. i think as long as someone uses custom generated private keys even if the flaw exists in the code the required energy to break 105 bits is much more than what you get for the coins in the wallets. on the other hand it may be possible to bruteforce all known wallet addresses in one run without much more costs...

i currently do not understand why someone did'nt empty the whole account and only took 40k.
i dont want to make people panic sell and drive the price down but if you hold a certain amount of coins within one wallet think about all this if you used the wallet to generate your private key.

The signing issue isn't due to integer size differences, but due to java's lack of unsigned integer types. The proposed patch on the page you linked has been applied to the Curve25519.java file, so this hasn't been an issue for quite a while.

Regarding the passphrase generator, I don't know where the cut-off would be for considering it bruteforceable, however 105 bits does seem very low compared to what you would get from the recommended 35+ characters alphanumeric with symbols.

I think you're looking at the wrong account. Stacy's account had all 9.8k transfered, however they didn't continue to transfer new coins that came in from mining.

+1

nice to read this answer who clear up any possible doubt!!!