Topic: Check out my awesome site for generating secure OfflineAddress.com (Read 12186 times)

Running this locally from a USB drive doesn't seem to work.  Can anybody verify?  Site loads, but generating the addresses, doesnt happen.

This type of subject is why bitcoin is not mainstream and won't be for a while. I would love to store my coins securely and feel I am not going to wake up with them gone. However, the farther I chase the secure-my-coins issue down the rabbit hole the more I am lost in wonderland.

I understand your concern, but this is how "standards" works on the Internet: someone propose one (BIP38), some others implement it (for example Mycelium, that is great), and it becomes used by many users.

And voilà, we have walked the path from a simple proposition to wide usage, now it becomes a standard

Paper wallet without encryption are very insecure, so I strongly advise against its use.

I've been looking into this recently.

The conclusion I've came up with is not to implement BIP38 because in the long run it will hurt users more then it will help them.

Here's why:
BIP38 is still just a proposal (BIP = Bitcoin Improvement Proposal), and it's been a draft for more than a year now. Until it's not accepted as standard there is no guaranty that this proposal won't changes, and it probably will to some extent after it's fully reviewed. Until that time, if I were to implement this, users would be tied to that (non-standardized-now) implementation even when standard changes later. That's why I won't implement it and I advise not to use BIP38 from any other site because it will just bring problems in the long run.

I can think of scenario in future where we have one piece of encrypted date that can be decrypted to different private key using old non-standardized and new standardized BIP38, and which can be then used to create compressed and uncompressed public key. Resulting with 4 addresses. (Compressed key is madness on its own which doesn't bring any benefit to bitcoin community at all, but that's not the topic here...)

Still it might be good idea to implement some other standardized secure way of encrypting important date (private key in this case). AES probably makes seance (which is also proposed to be used inside BIP38) because it's broadly used, secure and standardized. Although data encrypted using AES will be a bit longer then it would be with BIP38, but not much.

I like it. Thank you.

Hello,
is it possible to protect the keys with BIP38 encryption?

I'm glad it's fixed now.


Not much, as I've explained here, dedicated hacker will always succeed.

For power-users the easiest and obvious way is to open terminal and type:
After that you'll have the whole site locally ready to run, you don't even need to unzip it.

This.

Same question for downloading offline address from github. There should be a way for power users to increase their confidence level in this software.

Hmm. I can't replicate this. If I try to access the site via HTTP the connection is always redirected to HTTPS. If you can provide steps to reproduce accessing via HTTP I'd like to see them, thanks!

Regarding mitigating SSLstrip attacks, I haven't found a good solution yet (not with my hosting provider anyway.) Thanks for the tip.

Regarding offlineaddress, once I've loaded the site over SSL, what do I do to make sure the code hasn't been tampered with by a hacker?

I've added HTTPS to my site.

I've also made extra effort so that my site can't be accessed from HTTP anymore, all requests will be redirected to HTTPS.  

@canton: I've noticed that your site is still accessible from HTTP. What's the point of having HTTPS and letting the users access the site over HTTP?

+ and hope current connection is safe, and hope his pgp key is never compromised, and trust the author 

The only protection is to store his pgp key now and use it forever

@canton
@Patel
@IAS

The difference between my 'laziness' and 'expertise' lies in being very well familiar with MitM attacks...

It seems to me that you guys think HTTPS is some kind of 'excellent security', while I'm well aware it's hard to even call it 'good security'.
HTTPS it there to 'make people feel secure', it won't prevent any experience hacker, and that's why I wasn't rushing to add it to my site.

Let me explain how ridiculous is it to think that having HTTPS and signed code will make users safe:

For example caton's site (I hope he doesn't mind discussing vulnerabilities in his site publicly) is open to SSLstrip attack making HTTPS useless in the first place:
1) Site isn't using HSTS (there are no STS headers served).
2) Even if it was using HSTS first-time user could still be attacked. Unless all users are using 'HTTPS everywhere' and caton's site was on their list (which is not the case).
3) Even if all measures above ware implemented (and all users had HTTPS everywhere installed), this would only protect site from active MitM attack that do not compromise the certificate trust model - there are multiple parties that can issue fake SSL certificates that will be accepted by the client.
4) Only solution is to use the public key fingerprint as the server address (anonymous networks such as Tor and I2P), but their DNS is pretty much nonexistent, so the connection will depending on SSL security to obtain the address/public_key. So, it's still not secure!

5) Also signing won't help because:
GitHub link is served from the site (which can be SSLstrip-ed) - attacker can provide link to his repository that has his version of software signed with his key.
GitHub serves STS, and even if we assume user is on correct GitHub page, and has HTTPS everywhere - still, private key to check signature isn't in GitHub, it's served from private site, which is served over HTTP , even worse, it's linked from HTTP site to other site also served over HTTP (so you can chose where to do MitM, and you don't even have to strip HTTPS).
Now, how could that be even remotely secure?

And what about compromising GitHub account (or email) - git history can be rewritten. What about compromising server?

...


There are too many problems to address and dedicated attacker will always succeed!

That attack on randomness can be done on addresses created in the past(!), while MitM attack has to be done on live connection - which makes randomness problem more important (instead of pretending to serve secure site).

Anyway, I'll add HTTPS this week. Peace.  

Usually the server gets hacked, the probability of spoofing the site is lower than that unless at a public Wi-Fi

With my limited security background (really worked with DB's) I understand the HUGE security risks of not having HTTPS on the server. This means, at any time between now and when "the code stops growing too fast", a site wide hack can occur. And only having an "online" version is, has been said, a validation problem. Again, I'm no security expert but this just jumps out at me.

Is it worth risking the money of others here? What is the benefit? To whom? Honestly, does the user taking a risk benefit them or a potential hacker? Why take the chance?
There are sites that have the security and measures that has been brought up here. The world is looking at BTC now. There are extremely skilled hackers out there where money is involved, not to mention governments, agencies, etc. This thread is in part an advertisement for them to get ideas; A bit worrisome. We are talking about an open exploit I would say. I am giving you a website that can deal in millions of dollars and there is no HTTPS there. There is no offline validation.

It doesn't add up to me, how can a person like yourself that clearly is an expert in the area, be making some huge mistakes here? I see it and I'm no expert; I see the vulnerabilities and they scare me. I was brought to this thread because I'm always looking to see what is new in the offline wallet area and while just doing some basic checks, I noticed you had just opened your account both here and on GitHub as well. No guilt by association there, but when dealing with huge amounts of money, I'd say it is fair to look closer. If I'm off here and time bears this out, then apology in advance.

To continue, Would I use the private key I got from a website while it was online a moment before, with no means of validation and on top of that, there is no HTTPS. I can't imagine sending value there (even with the brilliant features regarding RNG's mentioned before). The RNG side may be better, but if there are some basic vulnerabilities at essentially the safe door it really doesn't matter what is below that level.

BTW, some of your ideas sound great, this isn't all criticism. I'm just trying to share what my perspective is. Just being concerned, nothing personal here.

Its about sharing

Mike, this is the crux of the misunderstanding as I see it. If the HTML is compromised because of a MITM attack or because the hosting space is hacked, then the user-provided input will simply be ignored, or fed into a predictive number generator. Users will not be secure.


There is every reason for saying that you shouldn't use HTML loaded from a live website. Telling users they will be safe if they turn off their Internet connection after loading the HTML is misleading, because it discounts the possibility of the HTML being tampered with -- which is a helluvalot more likely than the operating system RNG being flawed or someone finding a predictive pattern to the output from crypto.getRandomValues().

I appreciate your concerns.

Recommendation for downloading zip from GitHub will be added once code base isn't growing too fast. 

If RNG is compromised users will still be secure because all random date is user-provided.

Instructing users to primary check hashes is not appealing to broad audience (you know how hard it is to check hashes or signatures on Windows machines  ).
Discouraging users from using loaded HTML doesn't make sense to me - there is no purpose in having website saying you shouldn't use it.

1) I'm working on this, HTTPS will be added within a week or so.

2) I provide GitHub commit ID, and hashes will be added soon.

In short: yes, there are few things that should be added (like HTTPS and hash validation), and I'm working on it.
I'm concerned about both web security and RNGs. 

Hi Mike,

I'm increasingly concerned with this security approach you're recommending. Can I persuade you to change your recommendation to downloading a ZIP file from github and validating the hash? And actively *discourage* visitors from trusting HTML loaded from a live website? Yours is the only paper wallet site recommending this approach, and I can't figure out why.

There's no reason for a visitor to believe that they derive much additional security from disconnecting from the Internet after loading the offlineaddress.com code live. As you well understand, if the RNG is compromised in the HTML they receive, it doesn't matter whether or not the visitor is still online when they generate wallets.

Your recommendation seems doubly problematic when:

1) You don't force HTTPS on your server, meaning someone with permissions to the router on any network used to visit your site can inject different code as a "man in the middle". Your site is vulnerable to this attack right now, it's extremely difficult to detect, and it can be fairly easily executed by the sysadmin for any company, internet cafe, educational institution, etc.

2) You don't provide a mechanism for a visitor to validate the integrity of the HTML they're receiving from your website against some signed codebase of your own.

In short, you're advocating blind faith in the security of your web server. The only argument I've heard you make in support of this is that it's unrealistic to expect visitors to download a ZIP file from github and run the HTML locally. I'm really alarmed by this. I like your concern about RNGs, but I'm wary of your lack of concern about website security. You've got a nice site, good software, and strong promotion -- but you're advocating a standard of security that's much more relaxed than anyone else doing this. Why is this?

That's great news! I'm very happy to be able to help!

I like how it works now - users will be motivated to try to get that number to 0. 

I've released a new version of bitaddress.org with improvements to the entropy collection:
https://www.bitaddress.org/bitaddress.org-v2.8.0-SHA1-87dcf19f02ee9fb9dd3a8c787bcf52eef944aa82.html
 - more entropy from browser fingerprinting for PRNG seed
 - user can add entropy through URL hash tag
 - seed mouse movement as 16-bit number
 - whole seed pool initially filled by window.crypto.getRandomValues
 - added textbox as an alternative input source for entropy
 - address will not generate without a minimum amount of human added entropy from mouse or keyboard
 - discard mouse movements less than 40ms apart
 - visualize points of entropy collection from the mouse

@mikewoods, thank you for the ideas about discarding mouse movements less than 40ms apart and about visualizing the mouse collection points to encourage people to move the mouse more randomly.

I made this notice on your thread because naturally these two JavaScript solutions are being compared.

I believe where the scripts differ now:

offlineaddress.com) Is not seeding a PRNG it is bypassing the PRNG and using the mouse points as the byte source for the private keys. It requires 32 bytes from mouse movements for each private key.

bitaddress.org) Uses a PRNG that is seeded with a 256 byte array. That initial seed is used by the PRNG to generate 32 bytes for each address on the page based on the same 256 byte seed pool. To inject entropy into the PRNG's seed pool browser fingerprinting, time, key presses, mouse movements and hardware randomness from the OS are all xor'd together. As well the output of the PRNG is xor'd with the hardware randomness.

Thanks for starting the topic, having third-party service check the checksum sounds like a great idea.

Great news, thanks for info!

Mike, the instructions I quoted were under the heading "If you're looking for the ultimate approach." In my opinion, downloading a ZIP from github is ultimately more secure than using a live web page, even if it is hosted by Google.

As for ways of validating the integrity / checksum of a live webpage, I've been very interested in this as well but haven't found a solution myself yet. bitaddress.org inserts the SHA checksum into the URL bar itself, but if the server or pointbiz's FTP credentials were compromised, this could easily be spoofed, so my feeling is that this provides a false sense of security.

The "live webpage validation" systems I've considered mostly fall along two lines:

1) A manual checksum process with instructions like, "copy and paste the source code into such and such website, and make sure the checksum matches such-and-such publish checksum." Bleah.

2) A distributed / buddy "check the checksums" network. Something like a github project that deploys as a service that each of us (you, me, pointbiz, brainwallet.org, etc.) runs on our own servers that checks the live HTML checksums of our buddy sites every hour. Users of bitaddress.org would check bitcoinpaperwallet.com to see if bitaddress.org's live checksum matches the github-published checksum, and visa-versa. This way a hacker would have to compromise several services simultaneously to avoid detection. There's a lot that I like about this, but to be effective it would be a little complicated as the user agents and IP addresses of the "checker" websites would have to be unpredictable. Otherwise the compromised site would just serve up the unadulterated web page to the buddy network checksum requests.

But until there's some effective "validate this live webpage" function that a grandma can use, I have to yell loud and clear that it is NOT safe to trust something as vulnerable as paper wallets generation off a live website. The "go offline" instruction isn't significant because a hacked website will produce predictable random numbers just as well.

All websites can get hacked, and it's such a soft juicy target that we must assume that some of our wallet-related sites (bitaddress.org, bitcoinpaperwallet.com, offlineaddress.com, brainwallet.org) WILL be hacked. And we should plan accordingly. That's my $.02.

PS: I've put up a proposal for comments regarding the idea of a third party site that would help validate live bitcoin web services:
https://bitcointalksearch.org/topic/auto-validating-bitaddressorg-bitcoinpaperwalletcom-brainwalletorg-etc-413882

Thanks for the hint 

I started out with one big file so I know what you mean about making it harder to develop. On the advice of others I now use nodeJS and GruntJS to automate the build process.

Check out the wallet details tab on bitaddress.org there are instructions for doing this at the bottom. It's not that user friendly but it works. It looks for 99 dice rolls.

Your consideration are very correct.
As for as HTTPS goes - yes, there is no reason not to implement it, and I'll add that as soon as site budget allows.

As for as server security goes - I'm hosting the site from Google's hardware and software, in order to be able to resist any attack Google itself can resist.

The instructions are created for broader audience than the one you're thinking about.
This site was created with security in mind as well as usability, so there are some compromises that have to be made. The security experts will download GitHub code anyway, but some old lady in China probably wouldn't know how to use the site if I make it a bit more complicated. Bitcoins shouldn't be elitistic currency accessible only to those with technical education, we have to think about those that don't know what we know. That's why I've also added "Other important considerations", those things might be very obvious to us, but they aren't obvious to everyone.
There is nothing we disagree about canton, it's just different users we're having in our minds.

Please share any other thought you have about security issues, here or on GitHub (for example, I'm thinking about ways to implement protection from SSL strip attach beside HSTS).

Hi Mike,

These security instructions on your site are problematic. Nobody should generate addresses directly from HTML loaded directly from offlineaddress.com -- or any other website for that matter.

* you aren't running your site over https (yet) so visitors are exposed to man-in-the-middle attacks

* even if you were running this over https, this places too much reliance on the security of your website and/or your webhosting provider. an obvious vector for attack is for someone to get access to your website and edit the live site. Visitors should *assume* that sites like bitaddress.org are compromised.

Your instructions should specify that the only safe way to print wallets is to download your github code and verify signatures/checksums before running the code. Github may be hacked some day, but at least it's fairly easy to verify checksums/signatures on downloaded files, unlike HTML loaded directly from a live website.

Nice website, I like the idea.

Thanks

That's not yet possible with offlineaddress.com. Once all the code is packed-up as one downloadable file it's harder to continue developing it. So since I'm still adding code to this project on almost daily basis I'm postponing that feature.

I'd like to see this tool and bitaddress allow input of dice rolls as the entropy source for the ultra-paranoid. 100 rolls at 2.58 bits of entropy per dice makes more than the 256 maximum bits of entropy required to get the best protection. Of course users could choose to stop after say 60 rolls if they were willing to give up some protection. With multiple dice in a shoebox this doesn't have to take very long.

I can download bitaddress file and unzip it and run it for the fist time in a freshly booted system using WinPE or Ubuntu on CD or USB.

Downloading offline all the content is one thing, but is this possible (what i described above) with your software?

Actually I implemented offline functionality in the meantime.
Check it out, it should be working without any problems. Just load the site once and your browser will keep the site stored locally, so you'll be able to use it even when you're offline.

Yes please. This is a priority for me. I use bitaddress.org (thank you ninja for your incredible work) online ONLY for didactic purposes.

I always do everything serious on a live distro that never sees the internet. bitaddress.org and brain wallet.org work perfectly offline.

Awesome site BTW. Thank you!

I've just added more description about the site here: http://www.offlineaddress.com/?site=about

I just added Print button  , and it's working great. Check it out.

_{(if fonts go wild on first 2 notes just upgrade your browser or try it on chrome - some browsers don't yet support @font-face in print mode)}

The 40ms was manually defined limit (after a lot of testing). Initially I was using longer interval, but I just ended up being frustrated (it takes to long to fill in for 1000 addresses  )

I didn't know about that online test you pasted.  Does it work in all major browser?
I chose ajax test, because that way I'm also aware if user disconnects some cable or turnes off some router - user's machine will probably still think that it's online, but html requests won't go through (and request will timeout after 2sec).


That initial ajax call is optional, nothing is lost if user is offline and the request doesn't goes through.
However, if user is already online that call provides him with initialization of array in which mouse-provided randomness will be stored (all mouse coordinates are XORed over initialized array). That way even if users is lazy and doesn't move his mouse much - his mouse coordinates will be evenly distributed over coordinate space. (Otherwise I'd probably increase those 40ms you've mentioned, which would be frustrated for user). And by providing those from server, user's browser is protected even if it's random generator is compromised or old (basically user doesn't have to trust his machine).

Cheers 

@mikewoods,

Can you explain the ajax call to get an initial random number to fill the byte array?

https://github.com/mikewoods/OfflineAddress.com/blob/4af67c35effa95b54dda75e054a5631186b59ea7/index.html#L691-L701
https://github.com/mikewoods/OfflineAddress.com/blob/4af67c35effa95b54dda75e054a5631186b59ea7/index.html#L662-L668

How does this impact the entropy when you are offline? What is the benefit of providing an initial seed from the server? Are these seeds logged?

Thank you for the offer of beer :-) 

The visual feedback on mouse movement collection is very nice graphically.
You are waiting 40ms between collecting mouse points, correct? Do you have an article/white paper I can read on that technique?

I have avoided any use of ajax calls and it appears you make two ajax calls.
Canton Becker appears to have a good solution for warning the user about being online without using an ajax call:

I think I will implement that technique on bitaddress. Have you considered it for your site?

Don't get discouraged.

It's just we have had bitaddress from the beginning almost. We've grown to trust it. You need to stick around and age as well.

Bitaddress was also around when bitcoins were worthless so it wasn't risky to test.

I registered to tell you all about this site. I'm not kind of person to brag about something without first having something to show.

Bad seeds can't effect the security of the site because all users mouse movements are used to create exact number of bits needed for generating all the addresses - which are then XORed over pseudorandom sequence, making is unnecessary from theoretical perspective.
If user shakes his mouse well, there is absolutely no benefit of using seeded number at all.
In other words - even if seed is bad, total provided entropy will still be enough to generate all address with perfect (maximum theoretically possible) entropy - providing perfect security. 

In code, there is 'randomnessContainer' in https://github.com/mikewoods/OfflineAddress.com/blob/master/index.html which is the only thing used for providing randomness for generating addresses, and it's this.array contain the truly random data - which you can inspect using your favorite debug tool.

mike, why did you register to Bitcointalk the day before you released this? I'm a skeptic because it could be easy for this software to generate bad seeds, which lead to bad private keys.

Its hard for anyone to use this kind of software, even if it does provide excellent security as you claim. But your a new user, who suddenly releases a software to generate private keys.

I want to use it because of added security compared to bitaddress, but its a risk..

Solved 

Now site supports html5 caching!
This means that once you load the site, everything will work perfect even if you try reloading it when you offline, or after you restart your browser. 
This mechanism only stores static files, no other data like cookies or anything else is stored.

Could you try it out and let me know if everything works fine for you now?

Let's just be glad this isn't a straight up scam (or not yet)

Unlike this site a newbie is using http://flexcoin.com/

Hi 1ninja, I'm very glad you commented on this tread.
Let me first say that my site owes a lot to you marvelous work! Thank you a lot, having your site to look at helped me with my work!

As for the text I've quoted:
My software is notifying user if he's online, so that he can get offline and generate addresses. Your site can be used offline as well, the only difference is that I'm warning people about that.
Also, I must say I'm a bit envious of that all-in-one packaging you've done by embedding all your media into the site. I'll try to do the same thing once code base growth slows down.

We both have a lot to learn from each other, and I'll be happy to listen to any advice you have.

If we ever meet, beers are on me.  Cheers!

Who's going to pay for that? I think the responses Mike has given us are not those of a scammer, completely the opposite in fact ....

If you want to audit, please go ahead, I'm sure Mike would be delighted

The issue of entropy for a pseudorandom number generator is serious and important. It's true that bitaddress will generate an address for you if you do not move the mouse at all. That feature was requested by users of my site and in hindsight text input from the keyboard should replace mouse movements on devices without a mouse. I am discussing the issue here with other coders, I welcome any comments:
https://github.com/pointbiz/bitaddress.org/issues/35

You can visualize the seed pool of bitaddress.org by using the following query string at the end of the url:
https://www.bitaddress.org/bitaddress.org-v2.7.2-SHA1-364542f1ccc5777c79aebb1692a6265cf3e42e7e.html?showseedpool=true

If you move the mouse then bitaddress takes more than 1 mouse position, here is where it's determined how many mouse movements it will look for:
https://github.com/pointbiz/bitaddress.org/blob/master/bitaddress.org.html#L6638-L6669
https://github.com/pointbiz/bitaddress.org/blob/master/bitaddress.org.html#L5952

I would like to add that in all versions of bitaddress.org the time as well as mouse movements have been used to gather entropy.

Versions >= 2.7 have extra entropy from browser fingerprinting added to the seed pool. Additionally window.crypto.getRandomValues is used to initialize the seed. window.crypto.getRandomValues is also used to XOR the results of the ArcFour PRNG.

With the newest version of bitaddress.org the lowest entropy without mouse movements should be about 64 bits (assuming your browser does not support window.crypto.getRandomValues). If you add mouse movements to that you should be ok depending on your adversary.


I don't follow your logic here ?!? How does your software allow someone to generate offline addresses but bitaddress does not ?
I've specifically packaged my software as an all-in-one HTML document that is hashed then signed by my PGP key. The hash is available on bitaddress.org and bitcointalk.org. The HTML can be downloaded from either bitaddress.org or github.com and verified that you received the document that I authored.

Has anyone audited this code yet?

Idk whether to trust it or not.

If Chrome makes problems, try Firefox, it should be doable. But anyways, I'll try to implement HTML5 offline version as soon as possible - which should solve this.


Thank Canton, it was very fun to work on those dots  
As for as window.crypto.getRandomValues() goes - there are a few problems:
1) not all browsers support it correct (and I'm trying to support a bit older browser (not really old once) as well, for example I've implemented address computation using both html5 workers, as well as doing it using UI tread with delayed recursives.
2) It's still pseudorandom which makes it conceptually unacceptable because it has limited entropy.
3) (less important then 1) and 2) ) Browser could be compromised (and it's very obvious thing to attack).

Mouse movement are used as primary source of randomness and it has a lot higher entropy then any pseudorandom source. Still, to protect the user a bit more it's xor-ed over pseudorandom sequence.

Anyways, I'd be more happy if this kind of very technical questions are discussed on GitHub, because they can be useful for people that decide to join later.


Those are valid consideration for possible attack - that's why my site doesn't store (and won't) a single cookie, doesn't include outside .js (no ads, and no analytic software), and that's also the reason why I'll have to support the site using only the donations.

Luckily the ecdsa can not be compromised because the randomness source is from human (bad randomness is what enabled the exploit on android).

Bitpop, I'd be very thankful if you open discussion about possible attack on GitHub, this information is very valuable.


Thanks devthedev!

Wow, very nice site!

Great job.

Yes watch out for html5 offline storage to. I would use on unnetworked vm that is then destroyed.

Its just cold keys are perfect, you can steal them later and they have large amounts. Be careful people. This looks legit. I didnt see any http requests after load. But someone can clone this site, etc.

Even then, initial ecdsa can be compromised. Like the android hack.

I also don't believe bitaddress takes only one reading

Hi mikewoods,

I quite like the visual display for your entropy gathering. From a psychological perspective, I think it makes it more likely that a user will do the work it takes to make good mouse movements.

I notice you're not taking advantage of window.crypto.getRandomValues(). Do you believe your random number generator is more secure? If so I'd like an explanation. It seems to me that mouse movement and such should either be a fallback or an enhancement to using window.crypto.getRandomValues. Not leveraging getRandomValues at all seems an oversight to me since it's supported by almost every browser now. (IE9 being the notable exception.)

Canton

I was looking out for the community when I said what I said and I think Mike knows that.
Of course someone could write something in the Java to do what they want. A program does what you tell it. It doesn't have to send things back, it could create Private Keys that it is told to.

I'm not accusing him though (I'm saying to be careful and have someone look at the code), perhaps he is bringing up a VERY important issue regarding those initial seeds not having the required entropy for truly random private keys and that is worrisome.
That needs to be looked at.

But, so does the code here.

It's certainly beautiful... I sure hope you are what you say you are Mike.

I downloaded the chrome "web page complete" and while running it locally, it let me do the mouse movements just fine but wouldn't let me go to the next screen upon generation. Oh well.

The more I think about it, the more I really think you need to make the site into a downloadable package that we can use as a portable app... It still seems too easy for the browser to report the priv key back to you after an offline generation. A cookie could store that and be told to report it at next page load, couldn't it?

Yeah I noticed the dots flying over the screen. Nice touch. Thanks for all the advice. Looks like I need to use your service

Thank you Its_About_Sharing - your post is correct.

I did push project on GitHub a few days ago (however it's 4 months old now), I didn't want to share any half-baked or untested product with others before I can call it version 1.0.
(If I were in other people's shoes I'd probably be skeptic at the beginning as well.)
You don't have to worry about math - it's working perfectly.
I didn't want to risk anyone's money with buggy software, so I finished it before sharing.

All the code is clean and as simple as possible (and not compressed for now, so that everyone can read it easily).
It's available here: https://github.com/mikewoods/OfflineAddress.com

I'm looking for all the help I can get to make this site even better.

Cheers!

Hey guys, with all due respect to Mike, he registered here Yesterday.
His code needs to be thoroughly looked through by the community before you go using it.
Most of us are not coders and open source is nice, once you know it is safe.

And I just checked - Mike opened his Git Hub account yesterday as well!
DO NOT USE this software until it is checked!!!

IAS

Thank you minimalB!

For now you could use browser's printing mechanism to print or export to pdf, but I'm planning to improve printing experience as soon as I get some time to do it (or if someone sends me a pull request on GitHub in the meantime  ).

Very nice site!

It would be nice if we could also include keystrokes into randomness.

Is there a elegant way to print or export to PDF?

That's a great thing, especially if they use smartphone sensors (unfortunately, on desktop clients there isn't much to collect beside mouse movements and keystrokes).

Regarding "industry-standard OpenSSL random number generator" - I'm a bit skeptic because it's know that some 'standards' have been forced by NSA and have a backdoor, for example:
https://en.wikipedia.org/wiki/Dual_EC_DRBG
http://www.researchgate.net/publication/250025759_Chapter_10_An_Elliptic_Curve_Asymmetric_Backdoor_in_OpenSSL_RSA_Key_Generation
, so it's hard to tell if there is more of those 'paid standards' that actually work against us.



I personally don't use any wallets to generate my BTC addresses, I always generate secure addresses and import them.
However, if software you're using does use mouse movements, camera snapshots or other input sensors to provide randomness than you don't have to worry (if they have it, and it's well implemented, they'll probably brag about it).

ah good to know! I had just asked that question

Thank you, it is a very useful tool. I also found very interesting the technical explanation.

Now I'm a little worried, I've put most of my little stash of bitcoins on some paperwallets generated offline with bitaddress (I downloaded it from github and used it offline on a Ubuntu live cd).
Is it advisable to retrieve these paperwallets, import the keys and make new ones with your method?

Also how does this random numbers thing apply to computer wallets? I mean Bitcoin-Qt, Multibit, Electrum, etc... I've never been asked to move my mouse in order to generate random seeds. Do they use a different method?

FWIW, Electrum and Bitcoin-Qt use the industry-standard OpenSSL random number generator, which does collect several types of user input (not just mouse coordinates).

It's possible to never be online as well - all you have to do is load the site and store it on you local machine (some browsers are capable of doing that, while some other might fail - so try out a few browsers), copy the site to other machine that was never connected to internet, and use it from there (this is for most skeptic users who are afraid that their machine is infected).

I've created a site so that it preloads all the resources it might need in the future right after it loads (this feature will also be enhanced in future when I switch to using HTML5 offline mechanism).

After you store the site locally, you can just use site from your machine without ever being online (and get the new version again when you see some new cool feature that I've added in the meantime).

Not just disconnect, never have connected

I liked the idea of using mouse movements to generate addresses, and is fun too 
The "Printable Notes" section is great, I can now give out nice looking bitcoin gift vouchers.

(Thanks for the "disconnect from internet warning")

BitAddress.org isn't all that bad (it's just that it could be better, check this message: https://bitcointalksearch.org/topic/m.4315842)
BitAddress.org does use one mouse position, which is better then nothing, but still far from enough to make private keys as secure as possible.

Attacker has to brute force the start of pseudorandom sequence from which keys ware created, and doesn't have to brute force all numbers in sequence - which makes the brute-force attack easier.
Attacker doesn't attack directly the site (but it has to simulate it's behavioral), or the user. It just needs to brute force the set of addresses that could have been generated using pseudorandom sequences - because the set of addresses created using pseudorandom numbers is much smaller that number of all possible addresses. So it wouldn't be the hacker who attacks you, but instead entity with enough processing power to go through that limited set of addresses that could have been generated using random source with small entropy.
In other words - soon (if not already) it makes sense to start mining addresses that are not random enough, instead of mining bitcoins directly.



I was shocked myself how everyone ignored this problem (except some exceptional cryptographic programs like TrueCrypt that actually use mouse to generate better randomness) although it's well known problem and written all over wikipedia.
That's why I was motivated to do this in the first place.
I guess it's just the laziness of programmers, and that nobody would care until someone gets hurt.

You got it all wrong:

This website runs in your browser, not on servers, the private key never leaves your computer - I can't know it even if i wanted to.

But in order not to need to trust me (or the community looking at the code, which is open-source) the site even suggest to disconnect from internet so that you can be sure that there is no way private key could ever be sent to the internet.

If the software doesn't use mouse movements at all to generate randomness then you are much safer by opening OfflineAddress.com, disconnecting, generating addresses and then importing them in whatever wallet program you prefer (or leave them unimportant and keep as cold storage - so that private key never touches internet).

Also, there is other problem with programs that use mouse movements but do it incorrectly.
The usage of mouse movements is art on its own and it's hard to implement it correctly:
 - It's easy to pick up mouse position every x milliseconds, but if user isn't moving his mouse in the meantime no useful random numbers can be extracted (mouse coordinates will just repeat).
 - The second problem is that some computers extract mouse position faster than others, so some changes in mouse positions must be ignored so that the program doesn't pick up coordinates that are generated too fast and are probably closer to each other (less random).

That's why most programs don't actually show the coordinates they extracted.

And that's why OfflineAddress.com shows those dots flying over the screen - they are not there just for fun, they are real mouse position coordinates extracted to be used for generating truly random addresses.

This is against everything I know.

RRandom numbers can not be generate inside a computer, and pseudorandom number can be easily predicted.
Keys that are not random enough can be guessed, and Bitcoins stolen.
Real randomness has to be human-provided.
Dots flying around are real random data used to generate truly random private keys and addresses.

Seriously? And a person should trust you with their private key, why?

Very cool that people are working together to find solutions for these types of issues Kudos!

I have a Q and I am not tech oriented so if anyone could reply in plain English it would be incredibly appreciated.

If someone used bit address.org to generate addresses offline from a computer that continues to be offline but might also be brought back online at some point, is there any way that the private keys can be brute forced by a hacker? If so, in layman's terms, what are the odds of success in each case (offline, online)?

In other words, would an attacker brute force the site bitaddress.org to come up with these addresses or would they brute force the computer? Or both?

thx much

Congratulations on your new website also i think the site looks appealing, i hope you achieve your goal with this site
and it goes to plan. All the best and good luck with i, it can be hard to maintain:)

wow - thanks for the generous explanation. I do the "mouse shaking" thing with my keyword manager, so I got that part of it. Just didn't realize how serious the issue could be.

So the wallet I use, electrum, is using a pseudo random number generator presumably to generate the keys. So the best way forward would be to use your tool to create new keys and import them into Electrum?

That's a good idea! Almost all sensors on phone could be used for generating fairly good randomness, and the more information the sensor can produce the better.
Accelerometer is a nice idea - but I don't know if native phone sensors can be used from a website (not native app).

Nice site..does look great (and pretty too) and going to use it in the future.  Thanks for contributing it to the community.

This looks good. Would it be possible to allow it to harvest randomness from the accelerometer in a phone or tablet? Not that those make the best choice for an offline machine but would be a fun way to generate randomness.

Yes, there is a serious security problem when generating bitcoin addresses using pseudorandom numbers.

For short (technical) answer: Pseudorandom numbers have very small entropy (equal to size of the seed) and can be easily guessed.

Longer elaborate answer:

To make sure your BTC are secure you have to store them on address created with strongly random private key.
The more random private key is - the harder it is to guess it.
To make it the most secure - it has to be generate from truly random sequence of bits.

Random numbers created inside a computer are not really random and shouldn't be used inside programs with critical security (see: https://en.wikipedia.org/wiki/Pseudorandomness#Cryptography).
Random numbers inside computer are created using simple mathematical equations that provide a sequence of numbers that looks random, but can be easily guessed by just looking at one or two number from a sequence (commonly used mechanism is: https://en.wikipedia.org/wiki/Linear_congruential_generator).

Let's make an simplified example of how this sequences of PSEUDOrandom numbers are created:
Let's try to make sequence of one-digit pseudorandom numbers (usually sequences have 13-digit numbers or more):

We'll start with x=5 and use formula next_x = (x*7 +3) %10. (%10 means: "take last digit")
The first number in sequence is choosen to be 5, the second is then:
(5*7+3)%10 = 8. The third is
(8*7+3)%10 = 9. The next digit is:
(9*7+3)%10 = 6, and so on (it starts to repeat).

The sequence 5, 8, 9, 6 look like it's 4 random digits, but if you know formula how they are created (and formulas are well known), all you need to know is that you started from 5, the rest can be calculated.

So, if you use numbers from sequence of pseudorandom numbers, even if sequence is milliion digits long, you just need to know one or two digits to be able to calculate all of them.

So if you create 1000 bitcoin addresses in one go on you computer, someone could guess a few numbers and be able to get bitcoins from all 1000 addresses.

That's why pseudorandom numbers should be replaced with random numbers when creating secure addresses, but normal computer don't have a way to roll a real dice inside - so the randomness has to be provided from humans (for example by randomly shaking your mouse).

Thanks jonanon.

BitAddress is a great site, but it's far from secure.
I don't want to spam by copying my own reply, so please just take a look at this post:
https://bitcointalksearch.org/topic/m.4315842

ur site does look very nice
alot more professional looking than heaps of large btc 'business'

Cool site nice job!

How does this differ from say bitaddress?

 

Beautiful looking site Mike and great domain name

Can you elaborate on the problem with randomness for us non-geeks? What is the issue with how other "address generators" generate addresses?

Is it a security risk?

Hi everyone  

I've created OfflineAddress.com - cool new open-source site for generating safe and truly random offline Bitcoin addresses.

Seems like the whole world ignores the problem with bad randomness when generating Bitcoin addresses, and thinks that anything created with PSEUDORANDOM numbers is secure.

I needed a secure way to generate Bitcoin addresses for myself - so being a programmer and open-source geek, I decide to do it myself (and make the world a better place, of course   ).

Check it out.
Please comment, commit (on GitHub), suggest what to add ...

Cheers!

UPDATE 01/11/2014: I've added more description about the site here: http://www.offlineaddress.com/?site=about

_{(p.s. I've mentioned this site in Newbies forum, but nobody reads that, so I'm writing a new topic. I hope that's fine. Peace. )}