Topic: [ANN] bitaddress.org Safe JavaScript Bitcoin address/private key - page 24. (Read 153371 times)

Cool. Will BIP38 be added to bulk?  Does wallet details section decrypt encrypted keys?

Serial Number: ‎14 b3 cb e0 a1 af 8c d6 5b 87 e2 13 a9 38 6b ec
Fingerprint: ‎4c 99 b0 fb c5 42 5d d7 1c 53 81 ec 49 0c 5e cc 76 e2 4a f9
Issuer: PositiveSSL CA 2

v2.5.1

https://www.bitaddress.org/bitaddress.org-v2.5.1-SHA1-b7bda19c2327cc44a81b68a44926a9f8057ed681.html
 - BIP38 passphrase protected paper wallets. Thanks to casascius, scintill, Zeilap.
   Paper Wallet tab and Wallet Details tab support BIP38.
 - Compressed address support on Bulk Wallet tab.
 - Greek translations thanks to ifaist0s

BIP38 sort of hard codes some fairly expensive parameters where on today's computers, a native implementation does one in under a second, and a typical javascript implementation on a desktop might take ten seconds.  Allowing crazy high values in BIP38 is not really feasible because if they can be set too high, then it discourages developers from supporting it, because their services can be subjected to denial of service attacks by any user who sends a BIP38 code that asks for hours of CPU time just to decrypt.


Sweet, the paranoid side of me is very happy.


Simply use the audit code as though it were a SHA256 brain wallet and it should yield the same private key and address.

I agree and consider this a high priority item on the TODO.

What is the formula to take the audit code and reproduce the private key after you have the printed paper wallet?

Will you allow crazy high values for BIP38 encrypted keys? If I'm only making one key I don't mind having the browser calculate all night long if that means brute forcing will be extremely hard. Or is that something that can't change according to BIP38?

@pointbiz: is it possible to download v2.4 master from github? Can't seem to find it. Only v2.5. Thanks.

hi pointbiz! Don't forget to use compressed keys by default for everything.

v2.4 is a solid release use that until v2.5 is on the website, however there are no known issue with v2.5. I'm thinking about changing the versioning to X.Y.Z and incrementing with each checkin to github.

v2.5 is a major release with BIP38 encrypted private keys on the Paper Wallets tab, it's almost done. I've been checking in along the way to make forking/merging with other developers easier. It also gives people time to audit the code as there are updated versions of the CryptoJS libraries.

Interesting, i have exactly the same question as you kwukduck : )

v2.4 is online but master download on github is v2.5. Can anyone elaborate why is it this way?

I noticed the current version on the website (v2.4) is quite old (2013-02-17) compared to the one at github (v2.5)(2013-08-29) a lot of changes seem to have been made.

Why isn't the code on the website updated? Has the code on github been reviewed anywhere? is it usable and secure to begin with? Should i use the 'old' one or the new one?

Thanks again for this great tool!

Here is a feature request that I think would help assuage people's fears about random number generation, which have become more valid the more we hear about NSA-rigged RNG.

Right now, the script collects entropy by way of mouse movements.

I propose that the script also collect some additional entropy by way of the keyboard.

When the script generates new private keys, the private key should be SHA256(user-entered-string | prng-generated-string) (where | is concatenation).  Further, the string provided to SHA256 should be optionally printed somewhere on the note as an "audit code" (it could be invisible unless the user decides to click something to make it visible).

The purpose of the audit code is to allow anybody to reproduce the private key by hashing the string.  If it can be proven that the user-entered-string is part of the entropy that went into the private keys, then any user sophisticated enough to actually provide enough entropy via the keyboard can be reasonably assured that even if the prng is defective (whether by design or accident), that his keys are secure.

A side benefit is it also allows for easier practical auditing of forks.  Someone who is rightfully paranoid that a fork created to add feature X could also contain a weakened PRNG can satisfy his fear by making up for it in the form of extra entropy typed into the box.

A while back, I did a Bitgem fork.  It's on my pool site:

https://bitgem.dyndns.org/bitgemaddress.html

It's also at GitHub:

https://github.com/salfter/bitaddress.org

I removed the bitaddress.org logo at the top (since it doesn't really apply here), replaced the paper-wallet artwork with my hastily cobbled-together Bitgem note design, edited some of the text on the bulk-wallet tab, and changed a few constants here and there to produce Bitgem addresses.  Copyright and donation-address messages were left alone, but I figured it'd be appropriate to remove the PGP-key and version-history links and redirect the GitHub link to my fork.  My donation addresses (BTC & BTG) are included at the bottom as an add-on.

sorry couldn't find a namecoinia thread...

any chance you could make this value known in the popup box that comes up:


saying it's "too short" without actually telling the user how short, is a bit

How do I save a page from android stock browser, then verify the sha256?

Just verify the SHA256 hash: 1d5951f6a04dd5a287ac925da4e626870ee58d60

Android complains about non-trusted CA for bitaddress. Pointbiz, would you please state here who issued the certificate, and provide the serial number and the fingerprint? Thanks!

You can save the bitcoinaddress.org.html file locally and load it in the browser to use it offline.

Glad to see that you forked and did it (namecoinia) by yourself!

"If you want it well done, do it yourself!"

By the way, what about adding a zip version (github) in order to use it as an offline address generator?