Is an application like armory or bitcoin-qt more secure/ trustable in generating the public and private keys than a locally installed version of bitaddress.org ?

  • Welcome to StackExchange, we're always happy to see new users, especially ones who ask good questions we can actually read! That said, we do prefer that you only ask one question per... question. If you can find a way to edit this to fit that requirement that's awesome. If not, would you mind terribly editing out some of those bullet points and asking them separately? – David Perry Nov 27 '13 at 8:48
  • Oh, and don't forget to search before asking - nothing ruins the new user experience like having your first question closed :P – David Perry Nov 27 '13 at 8:48
  • Awesome, it looks great. Feel free to ask the remainder as separate questions. Welcome to StackExchange, we're glad to have you! – David Perry Nov 27 '13 at 17:57

There are different issues with generating cryptographic keys in general (including private keys for bitcoin) on a downloaded client versus a client served online, as bitaddress.org does. However, I think you yourself should be the judge of what is "more trustable." Here are the issues:

  1. Code integrity

    The problem in both cases is if your client is trustworthy, or possibly compromised. There are many aspects to this question, including if you trust the original programmer to get everything right, and not actually put in some bitcoin-stealing spyware. Possibly more interesting is the question if you would detect it if somebody (maybe a cybercriminal?) were to alter the code before you execute it. For downloadable clients, the question is basically if you check its integrity by comparing its checksum with what is published by a reputable source. This gives some security if you do, and if you trust whatever source you may get the checksum from, but in the end, even if you do, it essentially boils down to, at best, trusting whatever entity compiled the client for you. For the web-served javascript program from bitaddress.org, you do not even get a chance to check it yourself---meaning you absolutely have to trust its operator (and possibly the NSA) to serve an uncompromised program.

  2. Quality of random number generator

    Any private key is generated from randomness. If too much of it were predictable, that would defeat its ability to remain a secret. And that's the weak spot, because many computers in actual use are not too good at generating random numbers, either because they do not have a dedicated source of randomness built-in, or because the software used does not have access to it. With a computer you use interactively, you should be mostly fine, because timing jitter in your key presses, mouse motion, etc., is typically used to harvest strongly random numbers. A well-written downloadable client should have access to such facilities via your operating system and, typically, the SSL libraries---and yet, in practice, a lot of weak implementations have been found, including in a mainstream Linux distribution years back and, recently, in the Android operating system, actually affecting Bitcoin key generation. See the Guardian's article about Google confirming the problem. Any javascript implementation, like bitaddress.org, may be both worse and better off by having less direct access to such random number facilities.

  3. Execution environment

    Could any malware you might unwittingly have on your computer interfere, either spying on your keys or by weakening the keys your generate? For the downloadable client, we are essentially talking about vulnerabilities of your OS (plus your usage of your computer). For the javascript-based bitaddress.org, some vulnerabilities of your web browser that "only" allow interfering with something inside the browser might pose additional risk.

  4. Opportunity and effort vs. reward trade-off for an adversary

    Sometimes it is more dangerous to go the same route as everybody else by presenting, collectively, a larger incentive to exploit this route. Sometimes it could be more dangerous to do the opposite and possibly ending up using a solution that has received less public scrutiny and might, without one's knowledge, contain critical vulnerabilities.


My first instinct is to answer "No". As long as an application is installed locally and cannot send information over the internet to a third party, it's pretty much as secure as can be. There's no good reason to think that either would be more secure.

But there is a slightly bad one... (maybe not bad, but possibly a bit paranoid)...

Consider this: even if a program is open source, it's compiled, which means it not feasible to see the actual code and what it's doing. The software could be sending data when says it's not. Or it could be saving data in a hidden part of your operating system to be retrieved later by another malicious program. It could be doing a number of things that it shouldn't be and it would be very difficult for the end user to know.

A locally installed website, on the other hand, contains uncompiled code which is, at least somewhat, human readable. So, if you really wanted to, you could make sure that a locally installed website such as bitaddress.org isn't doing anything that it shouldn't. Although, this is infeisable for most, I once spent a while looking at brainwallet.org's source code to at least get a partial understand of how it works.

  • It occurs to me that if you're suspicious of the compiler you should also be suspicious of the browser and/or javascript engine, no? – David Perry Nov 27 '13 at 17:59
  • I think I will go for a local copy of bitaddress as github clone brought to an offline machine with an usb stick. And i'm going to do a bip0038 encryption on the private key. bitaddress can revert to the public key by using the password, are there other tools which do this? – hubertusanton Nov 27 '13 at 18:47
  • @DavidPerry Yup! You can't really be 100% sure that your computer isn't doing something that you don't want to do unless you build the computer from scratch and you've taken a look at the source code for everything that you run on it, including the operating system, the compilers, etc. But as I mentioned, this is a somewhat paranoid way to think and terribly infeasible to actually do. – John Henry Nov 28 '13 at 2:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.