I think it is unlikely that people working for NSA would have discovered an exploitable bug, before people who don't work for NSA.
Personally I don't find the kind of people that work for intelligence agencies as particularly intelligent - if they were intelligent, they would have had an honest job.
So IMO, NSA employees have much lower chance to find security holes in open source code than the rest of the world.
I disagree completely with this assessment. So much so that it makes me wonder about bitcointalk PsyOps  You might be right. As they say; everyone perceives others through who they are themselves. From my perspective, I consider myself smart enough to not need being any spy agency whore. But others - they might find it as a noble occupation, especially if it pays well... I must say that I personally don't know any people who would admit working for a secret service, so I have no statistical data whatsoever to support my thesis that they are all stupid. But at the other hand I know a few people who are definitely smart and would never agree to work for a secret service nor a military industry. |
|
|
|
Did the NSA plant the flaw? Seems unlikely.
Were they aware of the flaw, and could have included it in their suite of tools? Absolutely. NSA most certainly reviews software -- open and closed source -- to find bugs they may exploit at a later date. I think it is unlikely that people working for NSA would have discovered an exploitable bug, before people who don't work for NSA. Personally I don't find the kind of people that work for intelligence agencies as particularly intelligent - if they were intelligent, they would have had an honest job. So IMO, NSA employees have much lower chance to find security holes in open source code than the rest of the world. Therefore, I still think that a more likely theory would be that they planted a backdoor there, just making it look like a bug - such a thing does not requite a lot of skills. Though it is quite possible, as gmaxwell suggested, that they would do it through a planted employees, and not necessarily by pushing on Google from the top, or bribing it. Not because Google is so honest that it would not let them, but rather because hiding it would have been much harder then. Either way, as the bitcoin users, it taught us a good lesson - I think what we've learned from it was totally worth it. It will make us much more careful in a future with trusting third party software, especially such that comes from US based corporations. And yet I am still using CryptGenRandom in my bitcoin wallet software...  |
|
|
|
|
But I am, not accusing Mike of anything.
I am accusing Google of collaboration with NSA.
Considering today's headlines, shouting about NSA being able to break all kind of cyphers, thanks to exploits planted in all kind of software - why would we not assume that Android is on their list?
Just think about all the circumstances around this specific problem and its alleged fix that introduced "even worse set of bugs"...
Is Mike's explanation plausible - yes, it is.
But is it more plausible then an NSA designed backdoor theory - IMO, no!
|
|
|
|
|
I think we all understand your explanation, but some of us just don't quite believe that the alleged broken fix has not been an NSA approved "solution".
I don't know how you guys work there in Google, but all the companies I have worked in, when they fix a bug, they also create test cases, to make sure that the problem has actually been fixed.
And you are saying that they fixed such a critical security issue, basically a backdoor, though without realizing that they didn't actually fix it...
Well, it would mean that either Google is lamer than a drunk teenage girl, or somebody is just trying to sell us some fairy tales.
|
|
|
|
Perhaps they don't want to take action unless there is a risk of them losing users/money.
Obviously. The question is: why they don't want to take action? I mean, they cannot be so stupid to not understand that not taking the action is basically leaving an open backdoor in their encryption libraries. So why do they willingly keep the backdoor open? |
|
|
|
BTW hiding RNG faults in an open source OS is a really bad idea. Bad idea that obviously worked - all the Android systems had been exposed to crypto attacks for years. And they would probably still have been exposed, if not for the bitcoins users alerting the whole world. Let me remind you that this weakness was publicly reported at least few months before Google fixied it. And they fixed it only after some people lost their money, so Google was facing lawsuits. Are we supposed to believe that Google just did not know about the RNG problem, before bitcoin users reported it? Yeah, right.. Well, I don't believe it. |
|
|
|
Yeah. But then you need to assume that they are stupid and so when you say them "buy 1264 shares of ABC and 1734 of DEF" (where ABC and DEF are a rarely traded assets), they are actually buying the exact amount of both of them... which they should not, if they are smart and don't want to get busted.
It is tough to do real-time trading and avoid that problem. Well if you have 1% commission in + 1% out, you have about 2% of "space" to modify the order volumes, while statistically you should break even anyway, despite of the provision, just by choosing the direction up/down randomly. And the more the service gets popular, the more the volumes add up, the harder it is for anyone to match them with a single account requests. But that is also why I don't think they will ever switch to an actual real-time trading - it must always be somehow delayed, in order to combine requests from different accounts. Another trick you could use is to spread the requests among different brokerage accounts. These are just ideas from the top of my head, but I'm sure if I had built such a service, I'd probably have more security related countermeasures in my head. |
|
|
|
I'm sure it would be trivial to discover the owner by making signature investments on certain scales and identifying the pattern on an exchange.
Yeah. But then you need to assume that they are stupid and so when you say them "buy 1264 shares of ABC and 1734 of DEF" (where ABC and DEF are a rarely traded assets), they are actually buying the exact amount of both of them... which they should not, if they are smart and don't want to get busted. |
|
|
|
Problem #2: US capital gains tax liability, which the operators presumably must pay I asked this question before, but it stayed unanswered. Maybe they are just located in one of the countries that does not have capital gain taxes - in such case they would not say and I can understand it somehow. But as for the service itself, assuming it isn't a scam, IMHO it is the second best bitcoin-only service in the existence. Just don't ask me to mention the first one |
|
|
|
when it isn't beta anymore gavin will no longer be entitled to say "do not invest more in bitcoins than you can afford to lose"  |
|
|
|
However, I wonder if this is a valid transaction (if someone put it in a block, is the block still valid?)
I think it is not, though ATM I cannot point out the exact satoshi's code that discards it. But I am pretty sure it is there... |
|
|
|
There will be spam for as long as stupid pool owners and solo miners allow transactions smaller than 5430 Satoshis. Luckily, I think it happened already. Number of UTXO records was growing very quickly, yet like 3 months ago. But after the change that blocks the dust, after people upgraded their clients, it stopped below 7 millions and have been quite steady ever since then. The idea to treat transactions with outputs below 0.00005430 as non-standard really helped a lot - one of a few realized ideas, of the dev team, that I really and honestly appreciate Still there are the 141462 unspent horse outputs that anyone can use to spam the net - the best solution I see to get rid of them is asking miners to slowly claim them for themselves. |
|
|
|
I've been receiving "tx" messages across the wire with 0 inputs and 0 outputs. Literally the payload is 10 bytes { 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }. (Version = 1, 0 inputs, 0 outputs, LockTime = 0)
Any idea what those are all about? It's just occasionally. Do they have special purposes or are they just a misbehaving client?
Misbehaving client - I immediately ban nodes sending me a tx with no inputs, though still received 52 of such in the last 40 hours. It's not a big problem for the network - much bigger problem are big txs with "correct horse battery staple" inputs, since these are technically valid (thus no reason to ban a peer), but they take so much more of our b/w (and CPU, if your node gets to verify them). |
|
|
|
Your type-3 appears to inferior to type-1: with type-1 there's one master secret, and in case that master secret leaks then all the other privkeys in your wallet also leak, but in the case that certain privkeys themselves leak the all the other privkeys don't leak. With your type-3, for efficiency the user's client may opt to store many seed[n] values, and if any of those seed[n] leak, then all the subsequent privkeys leak too. And just like with type-1, with your type-3 wallet if the master secret leaks then the entire wallet leaks. You haven't explicitly tried to claim what's the supposed advantage of type-3 over type-1, but maybe what you had in mind is that in order to generate the next privkey the user wouldn't need to access the most sensitive piece of data which is the master secret, and will only need to access the seed[n-1] data instead, We have discussed similar properties here before. If you think that your type-3 has any advantage over type-1, please describe with precise details how the client software is supposed to retrieve an arbitrary privkey[k] without access to the master secret. Do you propose to have multiple layers of encryption every time that a new seed is derived? Thanks, you are so right. When I read it again now, it is actually doing quite the same, as my "just invented" type-3 The wallet stores a large random seed S (which can be encrypted if the user uses wallet encryption)
Privatekey(type,n) is then simply set to H(n|S|type). So honestly, I don't know where I got this idea from, when I was thinking that the type-1 was about: Privatekey[0] = H(S)
Privatekey[n] = H(Privatekey[n-1]) But now I see it was a stupid idea, and it existed only in my head - so never mind... Sometimes it is worth to make an idiot of yourself, just to learn something Cheers, guys. |
|
|
|
There I generate the public addresses in my offline wallet and them move them online, for balance tracing.
Ahh ok. You would get the same thing by having the chaincode. However, if the chaincode is not on the public server then it doesn't matter either way. You are just generating a set of public keys one way or another. I sort of mixed up two different issues here. One was my request for an audit of my deterministic wallet solution, which does generate public keys in the wallet, but is supposed to be "resistant" when one on the private keys gets compromised. I did not get much feedback here, but since nobody has stolen my coins yet, I'm guessing it's somehow secured enough The second issue was the privacy of the deterministic wallets, as they are being implemented now, by other parties; the kind of solution where you can generate further public addresses without having an access to the actual wallet. My concern was: how easy it will be for the attacker to figure out the secret/chaincode, while already having a couple of public keys from such a deterministic solution... From what you said, it won't be possible to figure out the chaincode, even having millions of consecutive public keys, or in other words: as long as you keep the chaincode secret, nobody can just calculate it from your public addresses. That's good to know - thanks. |
|
|
|
Initially I had thought that keeping "B_secret" secret does prevent others from guessing further public keys... but then it came to my mind (though, please correct me if I'm wrong) that just by having two consecutive public keys that came from the same type-2 deterministic wallet, it should be rather simple to calculate the B_secret - shouldn't it? I mean, if B_public_key = A_public_key + B_secret * G Then: B_secret = ( B_public_key - A_public_key ) / G Right? Or isn't it possible to do the second math? Most system use hashing. The Armory system is that you work out a multiplier based on the chaincode and the current public key. Multiplier(n) = ChainCode XOR Hash256(PubKey(n)) Public Key(n+1) = multiplier(n) * public key(n) Private Key(n+1) = multiplier(n) * private key(n) So, if you have the nth private key, you can work out the nth multiplier and then compute the (n+1)th key pair and by iterating, you get all the later pairs. It doesn't let you work out the keys from before n (since that would require reversing the hash function). You need the chain code, which isn't suppose to be public info. Oh, I see. Thanks for explaining. Under your scheme, the private keys are directly generated by the server, so that is the worse than just having the chain code and root public key on the server.
An attacker with public key(0) and the chain-code can obtain all private keys after the first private key they obtain.
If someone hacks a server using your system, they get all the private keys.
It's not really my scheme, it comes from the OP, but I do not quite get your logic that under this scheme "the private keys are directly generated by the server". From what I understand, the whole idea of Type-2 scheme ( from OP) is about generating the private keys outside the server. And I even checked it - it surely works. EDIT: unless here you were talking about the scheme I described in this post? There I generate the public addresses in my offline wallet and them move them online, for balance tracing. |
|
|
|
So if someone gives me an extended public key, I can generate public keys to addresses that the other person can unlock (by generating the appropriate private key on their side). Is this correct?
Not quite. You need to give him your public key and the secret. From these two, one can "guess" further private keys. The bolded part is incorrect. It might be a typo. You can never derive private keys from public keys. If you could do that it would shake the very foundation of bitcoin and public key cryptography. piotr_n must have meant public key. Yeah, sorry guys - I indeed meant public keys. Thanks for correcting BTW, I also had second thoughts about the anonymity issue, with the type-2 wallets. Initially I had thought that keeping "B_secret" secret does prevent others from guessing further public keys... but then it came to my mind (though, please correct me if I'm wrong) that just by having two consecutive public keys that came from the same type-2 deterministic wallet, it should be rather simple to calculate the B_secret - shouldn't it? I mean, if B_public_key = A_public_key + B_secret * G Then: B_secret = ( B_public_key - A_public_key ) / G Right? Or isn't it possible to do the second math? |
|
|
|
What do you mean by || ? If that is the OR operator, then you are going to set the least significant byte to all 1's, since after 256 values n will have 1 in every possible bit position.
By || I mean appending one byte at the end of the seed_key, that gets hashed later to get the next private key. So next time you calc a private key, you are hashing what you had hashed before, plus one byte more... I was worried that maybe this could be somehow exploited, especially when the attacker knows that I append the bytes always with the same sequence (0,1,2,3,...)? One of the big benefits of deterministic wallets is that a public server can generate the public keys without compromising the private keys. Yeah. That's type-2. I have it implemented in my app, but I personally don't use it, because it allows the "public server" to predict my further public keys and I see more cons than pros with this. It might make a lot of sense for e-commerce apps, but I don't really need such a feature for a private use. |
|
|
|
Thanks. I've actually made a huge progress ever since I published this topic - lots to talk about, most things I don't remember, though I try to keep the changelog up to date. From the know issues part, it still uses lots of system memory, which I could probably address by moving the UTXO db to leveldb, but since I have 12GB of RAM on my PC, I just don't care about these 4GB. And knowing that the leveldb would make fetching a balance of a random address extremely slow (comparing to what I have now), it discourages me even more from optimizing the mem usage. And there is still this EC_Verify that works very slowly while using the standard go libs, so one of the cgo wrappers should be used, but building it, especially on windows, is a bit of a hassle. Besides that, I'm quite satisfied with this project - these days Gocoin is the only bitcoin client I use and whoever has not tried it can only regret |
|
|
|
|
Show Posts
