Topic: 2^256 Deep Space Vagabond (Read 38737 times)

Download link don't work.

They should include compressed keys. Because every Bitcoin Core client uses it since version 0.6.

Also, we released the first part of many pieces of software to the public tonight for balance fishing on a local machine. ( https://bitcointalksearch.org/topic/hashbasher-10-by-hashhyena-826097 ) for those who are here with legit reasons other than to troll or prove how narrow minded you are. Feel free to grab a copy and try your hand at it. We will be releasing the blockchain parsing application soon that first exports all addresses with positive balances, then groups them so you know which ones to fish for when your generating addresses. We anticipate it will be about 3 weeks before we get that launched fully as we want to test it heavily in house before anyone else tries it on their PC.

I dont know if they ever will, they already support Hex, Base58, and mini keys. Compressed keys are not used too often and i dont believe they are main stream enough.

BTW, i dont know if you have ever heard of Turbid, but since you are looking for solid Entropy, their project is pretty good and open source. you could make one for a decent price.

Here is the paper, you can find more on google by searching Turbid RNG

http://www.av8n.com/turbid/paper/turbid.htm

Its an open source style of the more expensive RNG's that use audio that i mentioned earlier.

I'm waiting for them to include support for compressed keys.

Read the release notes, They dont hide what they do, and when they have errors. Believe that when the armory team finds a problem with their client that involves security, it gets patched IMMEDIATELY before anything else is done. Armory may not have always been the safest, but they are the best from a business standpoint at taking care of their problems, and they are very quickly becoming the most secure wallet client a person can have, although they are not quite there yet.

If you want to tip me, you can send me one them cute USB devices.

Good info. Now you alluded to armory having something in its source code that was recently fixed. What was it?

DABS,

THANK YOU. Seriously !!!!!!!!!!!!!!!

Yes, i can comment.

The avalanche effect in a semiconductor junction is probably one of the better known sources of Entropy in terms of hardware. I myself and a few of the team own TrueRNG's.

Not all HWRNG's are created equally, and some are more faulty that PSRNG's when you look at the bitmap analysis. (part of the reason why the bad ones dont show it openly)

In my opinion of course, i would say the TrueRNG is worth the money if you intend on storing any real money in something protected by cryptography.

Some of the better HWRNG's that are more secure use ambient noise at the time of reading to generate entropy as well. Go sit in a crowded coffee shop and generate your keys with it and you are for sure secure. I use to have one myself (super expensive) until i spilled coffee on it.

Care to comment on the following hardware RNGs?

http://www.entropykey.co.uk/
https://www.tindie.com/products/ubldit/truerng-hardware-random-number-generator/
http://ubld.it/products/truerng-hardware-random-number-generator/

I might buy the last one.

You're kidding right?

We already did. But let me summarize it for you.

There are a lot of wallet clients in existence that use faulty PSRNG's. The easiest way to find and "prove" this is to parse the blockchain for a list of all addresses ever used. Then group them by the first X characters, (we use X=6 as that is still quite easy to generate using most brute force tools including vanitygen)

Then turn your list into a bar graph, you will find that LARGE amounts of addresses fall in a very small portion of address space.

Because of this, you are cutting out a HUGE portion of the space if you are trying to brute force an address for 1. but most importantly you are opening yourself up to a "birthday attack" of sorts as it is not difficult by any means to compile massive lists of address/private key when your target is only address that start with 1xxxx,1xxxxx,1xxxxx, etc.......

On second thought, we already covered this, i dont feel i need to write it all out again.

The processes is simple, check the address before you database it for a positive balance, then monitor the database in real time for any incoming transactions. (there is a reason satoshi dice is keeping all of its coins in vanity addresses)

Stop beating around the Bush, disclose your findings

^^ AWWWWW you hurt our feelings 

This is worthless, you never give reasonable answers.

Thank you chris, that is much better

1: With vanitygen you add your own entropy by selecting an address with a 1XXXXXXX prefix, there is nothing random about it short of what comes after 1XXXXXX by selecting XXXXXXX you move yourself out of the over used "random" space

2: I wont argue this, instead i issue a challange, 1, Get drunk, i mean tipsy drunk. 2, attach 5 note cards (3X5) to the wall. 3, stand back 20-25 feet from them. 4, try and hit one, then try and hit the same one again.     (in short, its fun, and more random than you will get from most other sources)

3: I really dont want to get too much into this one, If your making this claim, i assume you have looked through the entire source code for armory before (prior to their latest 2 releases) so there really is no need for discussion here.

4: Right, and wrong at the same time. We are not making claims nor trying to convince anyone of anything, that would be futile around here to say the least, this is a community filled with sheeple, trolls, and the under educated with a few bright minds mixed in to try and balance it out. We knew this coming in. Instead, we are releasing some of the software we have developed to allow others to do it themselves. As more participate, the "thefts" (hopefully will be returned to their rightful owners upon proving a point) will begin to happen more often, and sooner or later someone will hit something BIG or nail someone of importance and when they speak up, then there will be nothing left to discuss.

 

5.  You had said using hardware RNG's would only solve part of the problem.  Why?

Cryptography is a complex subject, and cannot always be discussed in 5-word sentences (I even bolded the parts that actually needed addressing). I will try, but you may not like the results.

1. You claim nearly all CSPRNG is flawed. Then, as a workaround, you recommend vanitygen, which uses a.... CSPRNG (a fairly common one, OpenSSL). Can you explain the difference?

2. Your dartboard scheme for creating entropy is slow and biased, the sort of thing no cryptographer would ever come up with. Why did you?

3. You claim that "paperwallets" are superior because they use entropy from a mouse. You cite a bunch of wallet clients you claim to have found "through heavy testing" to be faulty, and yet every one that you cited also uses real-world entropy, just like "paperwallets". Armory, in particular, uses mouse input plus several other sources of real-world entropy. How could a cryptography expert miss this fact?

4. You've made extraordinary claims. If you are unwilling or unable to provide extraordinary proof (which is understandable for a work-in-progress), you will likely be ridiculed unless you can at least provide extraordinary professional credentials for your "few dozen mathematicians, statisticians, and even a half dozen cryptographers with over 45 years combined education." Why have you done neither?

Is that better?

TL/DR

If you can clean it up into a short list of direct questions i can reply, but i am not reading through that entire mess to find the questions.

Thank you.

Hash Hyena, I have a couple of questions / points which I hope you can address. The first is related to your interim key generation recommendations.


Given that vanitygen is just another CSPRNG, and therefore flawed by your reasoning, why would you recommend it over any of the others you mention above (all of which use, exclusively or at least in part, the same OS-provided source of entropy)? In fact, vanitygen intentionally decreases entropy when it throws out generated keys which do not match the predetermined pattern, which would (slightly) decrease the security of the generated keys.


First of all... how did you generate the random pattern of digits on your dartboard to begin with?

Regardless, any single set of random data is of course itself randomly biased, including your dartboard, and re-using it naively like this (I assume you don't create a new dartboard for each throw) combined with human bias will introduce that bias into its output. For example, it's very likely that there exists a hex digit on your dartboard which occurs less frequently on the periphery than it does towards the middle. Since I presume you'd avoid aiming your darts such that they might miss the dartboard, this hex digit is more likely to occur in your generated output.

In fact, a much better approach which would lead to less biased random numbers (assuming that the individual target boxes are small enough) would be to use a regular repeating pattern for the dartboard, where each 4x4 section contains exactly all 16 hex digits. How is it that nobody on your team caught this?

(This is to say nothing of the fact that throwing 64 darts at a dart board is silly-inefficient compared to just shuffling (well) a deck of cards...)


Next, moving back to your assessment of alternative clients:


First it should be noted that all of the clients you mention above (including BitAddress.org, which is I assume the paper wallet to which you refer) begin with the same source of OS-provided entropy (/dev/random on Linux/BSD or CryptGenRandom on Windows). Even though these two sources of entropy are in part provided by deterministic processes, they also use external human-influenced sources to maintain their internal state, e.g. the starting of programs, the initiating of or receiving of network traffic, the timings of writing to or reading from disks, etc. It is inaccurate to claim that the wallet clients you mentioned do not use significant amounts of human-source entropy.

Next, let's move on more specifically to your assertion that "through heavy testing that Armory ... has the same problems." Given that Armory gathers entropy from some of the same sources [github.com] as "paperwallet" (in fact it gathers entropy from many more human-influenced sources than "paperwallet"), can you explain why Armory has a flawed CSPRNG, whereas "paperwallet" does not?


Given that you've said
I find it extremely discouraging that you can make such basic errors as those outlined above. The net effect is to make me exceedingly skeptical of not only your overly-broad claims (which cannot be proven nor refuted due to their vague nature), but also of your abilities as mathematicians and cryptographers and even your intentions. Posting your team's professional qualifications (names, degrees, and peer-reviewed publications) would go a long way toward alleviating some of these concerns, even if you choose not to be more specific regarding these alleged vulnerabilities still under investigation.

I also hope that you can specifically address the questions above.

We are a little confused  as to your questions. Are you asking do we get paid to play around with brute forcing and birthday attacking the bitcoin address key space? Or is someone paying us to exploit the PSRNG faults in most wallet clients?

As for budget, we dont have nor need one. The whole project is nothing more than a now large and ever growing collection of people from various aspects that relate to the project in some fashion either writing code, improving methods, researching and calculating various stuff or just dedicating a little computing resources to the project. The core team funds our own hardware ( hard drives, electricity, servers, and massive raw computing power) It is all play money, dedicated to being wasted on having fun with exploiting anything bitcoin we can. Any exploits, faults, issues we find with any wallet client, web service, etc. usually results in a report being sent to the service provider notifying them of the issue. One of the biggest wallet clients in use today had one of the biggest problems that was easy to exploit. within 2 weeks of reporting it with a demonstration to show exactly what was happening they had released the next version which fixed the problems.

^ they wished not to be named to avoid false panic as everyone that downloads the latest release will no longer have the issue.