i feel that once this scaling debate is somehow resolved, which ever way it goes, even worst case scenario, we'll end up WAY higher than this...
Two years ago I was pissed when it went below $250, now I'm pissed when it goes below $1000. In another two years I'm hoping to get pissed when it goes below $10000 after a rally to $30000 or more. |
|
|
|
this is the titanic nothing can sink this ship
FULL SPEED AHEAD!
Adam the space jew  i need sub 950 ... Try Bitstamp, it's over $30 below btc-e and really low volume today. It's just dipped 50 cents below 950, but that probably won't last long. Bitfinex is $15 higher and the arbitrage traders will soon pump the price on stamp to match finex's. |
|
|
|
Try downloading the latest wallet version from here. https://multibit.org/releases/multibit-classic/multibit-classic-0.5.19/multibit-classic-windows-x64-0.5.19.exePut it in a new folder called MultiBitClassicPortable0519 in your C: drive, then make it a portable app by creating an empty file called multibit.properties with notepad, and placing that into the same folder as multibit-classic-windows-x64-0.5.19.exe When creating multibit.properties make sure you select "all files" for its type, not txt. This screenshot shows how.  Afterwards run multibit-classic-windows-x64-0.5.19.exe and install multibit into your MultiBitClassicPortable0519 folder like in the screenshot.  Put your backed up wallet file into that folder. Double click multibit-classic.exe inside the new folder to start multibit. When it's running select file, then open wallet, then browse to your backed up wallet file. Hopefully your new portable multibit should be able to open it without errors.
Did you also make a backup of a file with a .key extension? If you did and it's not password protected you can open it in notepad and get your private key. In the example file below the private key is the bit in red. # KEEP YOUR PRIVATE KEYS SAFE !
# Anyone who can read this file can spend your bitcoin.
#
# Format:
# <Base58 encoded private key>[<whitespace>[<key createdAt>]]
#
# The Base58 encoded private keys are the same format as
# produced by the Satoshi client/ sipa dumpprivkey utility.
#
# Key createdAt is in UTC format as specified by ISO 8601
# e.g: 2011-12-31T16:42:00Z . The century, 'T' and 'Z' are mandatory
#
KwUVsx4nd4UTHUtNTPnLEEqapCFvNiBrVASBZPa1ZvStQbUD87VK 2017-03-26T01:36:45Z
# End of private keys If it's encrypted you can still get the private key, but it's more complicated. These instructions should work. Download this and extract it. https://indy.fulgan.com/SSL/openssl-1.0.2k-x64_86-win64.zipPut the extracted folder in your C: drive root folder. Put your encrypted wallet file in the same folder. Open the windows command prompt by selecting run as administrator. Type the line below into it and press your enter key/ cd /openssl-1.0.2k-x64_86-win64 Type the line below into it, but replace Untitled.key with your encrypted key file's name and password with your password, then press enter. openssl enc -d -p -aes-256-cbc -a -in Untitled.key -out Unencrypted.txt -pass pass:password Open the newly created Unencrypted.txt file in notepad to get your private key. In the example file below the private key is the bit in red. L128BoWxZoAixtYTRRvm7BF686Jxmsf7W3LAiKY5Gu43o94LRNbw 2017-03-26T01:53:30Z |
|
|
|
Well, I don't mind about moving to another software.
Just tell me if that's possible to use a raspberry and some kind of software (Other than bittaddress) safely, please.
By the way, did you check my other post? It talks about using a playstation 2 and a linux redistribution to make the wallet.
A staff member here called Dabs suggests rolling dice to generate a truly random private key, then using that in the bitaddress webpage on a live CD to get the associated Bitcoin address. Using that technique on a raspberry should also work, and you never have to worry about a bug in a random number generator endangering your Bitcoins. Most experts agree that using dice is truly random. You roll a dice 99 times, record the results following these rules: 1=1, 2=2, 3=3, 4=4, 5=5, 6=0 Then you click bitaddress's wallet details button, put that long 99 digit number into the text box, and click the view details button. The bounty has been claimed, but I propose using an unbiased dice generation method.
Use base 6 for the 6 sided dice. Roll it about 100 times (really.) Write it down. Then convert that to hexadecimal and you have your private key with no bias. (Okay, maybe you need another dice roll?)
For example:
1001112400000533003453522130540400324355321453252515013101100231113332152441500 105310450123404240000
becomes
F213DA1F48C5B538B67BB9E25379B1CE0A8C8D8E205B03E3E68BDB35CDECA3A2
Then you plug that in to an offline copy of bitaddress.org on a computer that is never used for any other purpose (or uses a Live CD), and we get this:
Bitcoin Address (compressed): 1A2nR6q3aUQPJKpA2YFXjqRdh6XN8WAxKQ
Private Key WIF (compressed, 52 characters base58, starts with a 'K' or 'L'): L5LH5Sg1reynj5pKbVcUo6uvbQTnxnqQs1W1ghACrgdU5A1WJm3J
If that looks better, you can also send me a coin. If not, uh, I tried. hehe. (coin address in my signature.)
For the dice roll, subtract by 1 to get the base 6 digit.
1 = 0
2 = 1
3 = 2
4 = 3
5 = 4
6 = 5
Bitaddress also suggests using dice to ensure a private key is truly random, then using it in the webpage to get its associated Bitcoin address. There is a link that opens these instructions at the bottom of its webpage. https://www.bitaddress.org/How do I make a wallet using dice? What is B6?
An important part of creating a Bitcoin wallet is ensuring the random numbers used to create the wallet are truly random. Physical randomness is better than computer generated pseudo-randomness. The easiest way to generate physical randomness is with dice. To create a Bitcoin private key you only need one six sided die which you roll 99 times. Stopping each time to record the value of the die. When recording the values follow these rules: 1=1, 2=2, 3=3, 4=4, 5=5, 6=0. By doing this you are recording the big random number, your private key, in B6 or base 6 format. You can then enter the 99 character base 6 private key into the text field above and click View Details. You will then see the Bitcoin address associated with your private key. You should also make note of your private key in WIF format since it is more widely used. The only situation where I wouldn't consider using that technique is one where the rolls obviously don't look random, like in the Dilbert cartoon. If I rolled ninety nine fives I wouldn't use them even if the sequence is "technically" random. https://www.random.org/analysis/If you flip enough coins, you will get sequences of coin flips that seen in isolation from the rest of the sequence don't look random at all. Scott Adams has drawn this as a Dilbert strip, which is funny exactly because it is true:  What Dilbert is told is correct: It is impossible to prove definitively whether a given sequence of numbers (and the generator that produced it) is random. It could happen that the creature in the comic strip has been generating perfectly random numbers for many years and that Dilbert simply happens to walk in at the moment when there's six nines in a row. It's not very likely, but if the creature sits there for long enough (and Dilbert visits enough times), then it will eventually happen. Here's an example of one key I wouldn't use even if it was "technically" random. Private Key Base6 Format (99 characters [0-5]):
1111111111111111111111111111111111111111111111111111111111111111111111111111111 11111111111111111111  |
|
|
|
The future of Bitcoin is bright either way, BUcoin HF or not. I'm using every possibility to increase my Bitcoin stash, the cheaper the better!
Something strange is happening. Btc-e moved up to second place for USD volume, and it's price is $10 higher than bitfinex's, which is itself $10 higher than bitstamp's. Somebody's increasing their Bitcoin stash on btc-e. |
|
|
|
Main thing for me is, in the end I want only one coin. This talk of 2 chains is ridiculous.
2 coins would at least put an end for good to this endless drama. The market will sort out the good coins from the bad ones. I don't think there will ever be enough consensus for a fork. However, if there is one then doesn't it mean all Bitcoin holders can double their money, provided the price stays the same? Price will not stay the same! BUcoin price will crash immediately as a result of oversupply, everybody will sell it. The price of Bitcoin will shoot up to the moon firstly, because everybody will convert BUcoins into Bitcoins and secondly, because there will be no obstacles anymore to implement segwit, LN and sidechains. So we get to keep all our coins, sell the fork's coins for a fair amount of cash, and the coins we hold shoot up to the moon in value? That sounds like the kind of sweet deal that will entice speculators to buy in advance. |
|
|
|
Main thing for me is, in the end I want only one coin. This talk of 2 chains is ridiculous.
2 coins would at least put an end for good to this endless drama. The market will sort out the good coins from the bad ones. I don't think there will ever be enough consensus for a fork. However, if there is one then doesn't it mean all Bitcoin holders can double their money, provided the price stays the same? If we keep coins on one chain we can choose to sell the coins on the other forked chain. That way we get to keep our stash and get a shitload of cash too. Except of course the price won't stay the same. But it would have to crash to half its current value before we lose out, and for all we know people might start buying in anticipation of getting double coins. |
|
|
|
Main thing for me is, in the end I want only one coin. This talk of 2 chains is ridiculous.
2 coins would at least put an end for good to this endless drama. The market will sort out the good coins from the bad ones. I don't think there will ever be enough consensus for a fork. However, if there is one then doesn't it mean all Bitcoin holders can double their money, provided the price stays the same? If we keep coins on one chain we can choose to sell the coins on the other forked chain. That way we get to keep our stash and get a shitload of cash too. |
|
|
|
You guys are not considering the fact that a raspberry can run other operational systems, such as: Android (RTAndroid) actively updated, and here is a video tutorial
Angstrom Linux
Arch Linux ARM SD Images are no longer maintained for Raspberry. Installation is done from tarballs now with manual setup of partitions and file systems, see here.
Chromium OS
Debian ARM
Fedora ARM Pi 2/3 only.
Fedberry SD, a Fedora Remix for Pi 2 and 3
FreeBSD
Gentoo
IPFire
Kali Linux SD
LibreELEC
Meego MER + XBMC
Nard SDK SD (Embedded systems)
NetBSD
OpenELEC + XBMC SD
OpenWrt SD
OSMC SD, Open source media center
PiBang
Pidora SD, a Fedora Remix for Pi 1 [No longer maintained]
PwnPi SD, a Raspbian clone for penetration testing. Does not seem to be actively maintained. Last version from 2012 works on Pi 1. Replace the files on the /boot partition with those of latest Raspbian to make it work on Pi 2.
QtonPi
Plan 9 SD
Raspbian SD, a Debian derivative
Raspbmc SD is now OSMC
RaspBSD SD
RetroPie SD
Risc OS SD
Slackware ARM
SliTaz
Ubuntu Mate SD
Void Linux
Windows 10 IoT Core SDReferences This is a comprehensive list of OS available for the Raspberry Pi. The official site links to this eLinux wiki, so I presume this might be the most complete list at the moment. Distribution List on eLinux Wiki Official Downloads Raspberry Pi on Wikipedia - includes an extensive list The OS distributions that are available as an SD card image are marked with SD. Beware not everything on that list will work on all models of Pi; non pi-specific GNU/Linux distros are usually for ARMv7+ and therefore only viable on the Pi 2/3. Some pi-specific images are also model 2/3 only, but this should be clearly indicated on the homepage if not here. There are also (non pi-specific) ARMv8 64-bit ("aarch64") GNU/Linux distros that should be viable on the Pi 3 but this is largely untested. Non pi-specific images (not having a dedicated SD card image is a clue to this) will probably at a minimum require you install the Raspberry Pi kernel; a generic ARM kernel will not work. See here for an example methodology regarding this. Source: http://raspberrypi.stackexchange.com/questions/534/definitive-list-of-operating-systemsSo what do you have to say about the randomizing part now?  The randomizing part relies on whatever choice of random number generation bitaddress uses, not the operating system. In fact the raspberry has its own built in hardware random number generator discussed here. I'm sure most of the operating systems you listed are capable of using that random number generator, using suitable software. https://security.stackexchange.com/questions/47475/testing-a-hardware-random-number-generatorHowever, for random number generation bitaddress uses the Arcfour algorithm (officially called RC4) in which multiple vulnerabilities have been discovered. https://en.wikipedia.org/wiki/RC4multiple vulnerabilities have been discovered in RC4, rendering it insecure. It is especially vulnerable when the beginning of the output keystream is not discarded, or when nonrandom or related keys are used. Particularly problematic uses of RC4 have led to very insecure protocols such as WEP.
As of 2015, there is speculation that some state cryptologic agencies may possess the capability to break RC4 when used in the TLS protocol. IETF has published RFC 7465 to prohibit the use of RC4 in TLS; Mozilla and Microsoft have issued similar recommendations I had a quick look at the bitaddress source code and it appears to use the list of sources below (in combination with Arcfour) for random number generation in addition to mouse movements. However I only had a quick look and might be mistaken. https://github.com/pointbiz/bitaddress.org/blob/master/src/securerandom.js#L125-L128- Math.random()
- the current time (w/milliseconds)
- webcrypto if available
- screen size and color depth
- time zone offset
- user agent
- browser plugin details
- cookies and storage
- language
- history
- location
According to this stackoverflow post using Math.random() is problematic because it's weak. A weaknes was discovered in an early version, but apparently today's version is still weak. http://stackoverflow.com/a/18507748Math.random() was weak in most browsers in 2008 - Amit Klein's paper goes into excellent detail - and sadly is almost as weak today. This is a link to Amit Klein's paper exposing the Math.random vulnerability in Google Chrome 6.0 and 7.0 http://www.securitygalore.com/files/Google_Chrome_6.0_and_7.0_Math.random_vulnerability.pdfThis is the mozilla discussion about replacing Math.random with something more secure. https://bugzilla.mozilla.org/show_bug.cgi?id=322529Disclaimer: I'm no expert so do your own research and draw your own conclusions. |
|
|
|
Actually I think the slider should go to higher than 200 satoshi/byte, in case the recommended fees go through the roof at any point or if the user really needs to get the transaction confirmed quickly. Maybe 400 satoshi/byte or so would be good (after that it gets ridiculous, not a lot of people would use Bitcoin if the fees were higher than that).
I think the recommended fees have been >220 satoshi/byte recently and for all we know it could get a lot higher.
Electrum automatically adjusts the maximum fee allowed on its fee slider. Recently its maximum has been >330 satoshi/byte. If the fees keep needing increasing multibit could easily need >500 satoshi/byte on its slider. It sounds stupid now, but a year ago paying >330 satoshi/byte sounded stupid. |
|
|
|
Informative thread thanks.
But doesnt Electrum have its own encrytion service? Why need pgp?
It's for verifying the electrum wallet software you downloaded really was written by the electrum devs, and hasn't been tampered with by hackers. All the devs put their pgp keys on github, and other users in a web of trust verify those really are the dev's pgp keys. https://github.com/spesmilo/electrum/tree/master/pubkeysAny pgp software can check in various databases that all the users in the web of trust agree those dev's keys on github really belong to the electrum devs. Verifying a downloaded electrum wallet has been signed with a pgp key proves it hasn't been tampered with. If a hacker switched the dev's pgp keys on github for his own your pgp software would tell you those keys don't match the keys certified by the users in the various web of trust databases. |
|
|
|
The problem is the total inability for Bitcoin to reach any sort of consensus.
What matters is that it is resolved one way or another. The lack of governance is the real problem, only compounded by the refusal of so many to even acknowledge that there is a problem at all.
As others have said here before me, what makes this crash so difficult to stomach isn't the falling price. We've all seen bitcoin win all sorts of challenges before. What makes this one so disturbing is that the threat is on the inside, bitcoin's lack of governance, lack of ability to say "this is a problem and this is how we're going to fix it" is actually tearing it apart from the inside. I'd rather see bitcoin drop to $200 because of China or the US government than to $900 because of infighting. At least then I'd have some confidence that it would come through, but Bitcoin can only win through if it's in good fighting form and right now it isn't.
Exactly. By the way, I also find it disturbing that some people claim everything is peachy. Cognitive dissonance much? Bitcoin's back up to $943 so everything is peachy. There is speculation Huobi might start allowing withdrawals again, so China might be unbanning Bitcoin again, which makes everything even more peachy. https://cointelegraph.com/news/bitcoin-exchange-funds-reporting-not-for-all-users-huobiTo cap it all a number of top devs say there will be no fork and everything is just peachy. Get those cheap coins while you can. http://www.coindesk.com/bitcoin-on-developers-arent-worried-about-fork/ |
|
|
|
Thing is, it really isn't about to fork any time soon, not without consensus. I'd be willing to wager that too. Does not matter though, too much uncertainty for new money to bare. The downside to the influx we witnessed these past couple months. Question is, when will the fog lift?
Yeah, $750 could be tested, but I would not be shocked to see one more push up the the 1025 range first.
Zooming out on the charts you can see what looks like a cup and handle. This dump could be necessary before the handle forms. In the long run I'm not worried, I don't think there will be a fork, and sooner or later that handle will form. The best time to buy is when there's blood on the streets, and that's probably now. As in December 2013 size cup? That's what I'm hoping for. The price has been held back by so many events for so long that I'm beginning to wonder if the market's stopped caring and just wants to go up regardless of what happens. There's a giant cup in the charts that's just waiting for a 2013 style handle. Any respectable handle is going to have to cut to $800. That's not what investopedia says, although trading advice sites vary in their analysis. It says the handle can retrace one third of the gains made by the cup's right hand side. If the gains were $1350 - $150 then they were Ģ1200. One third of that is $400, and subtracting that from $1350 gives $950 as the bottom of the handle. If that works out then Bitcoin's oversold already. http://www.investopedia.com/university/charts/charts3.aspthe general rule is that the handle's downward movement can retrace one-third of the gain made in the right side of the cup. On the other hand using chicken bones is often more reliable than technical analysis. |
|
|
|
There are similar complaints in this thread. This one reply says jaxx switches address automatically at certain time intervals, and often has problems syncing, so balances don't get displayed correctly. If that's true there's a chance your coins might still be accessible. https://forum.z.cash/t/restore-t-adress-jaxx-wallet-warning/8225/34Donīt worry about the changed address. The address changes automatically at certain time intervals. Nevertheless, any previous address is still valid and can still be used.
I have just looked in my wallet: I am also missing some coins. But thatīs not because the change of your adress. Jaxx currently must have a problem when retrieving the blockchain, so not all coins will be displayed. You can simply enter your t-address at Zchain11 and then you can see that all your coins are still there. Hopefully, Jaxx fixes the problem quickly! Try importing your jaxx wallet's seed into mycelium's android wallet and see if your coins show up in it. According to this post the two wallets can use each others seed. https://www.reddit.com/r/BitcoinBeginners/comments/5xt8m6/my_12_word_seed_from_jaxx_isnt_showing_my_balance/Jaxx follows BIP 32/39/44, so Copay (mobile and desktop) and Mycelium (Android, probably iOS) can restore the Bitcoin wallet from Jaxx. |
|
|
|
Converting your private key will result in a completely different address. Electrum should be able to import any WIF private key.
Well I have a paper wallet with a private key beginning with a 5 (WIF format) but Electrum 2.6.4 seems only to allow to sweep private key beginning with K or L. When I try to enter my privkey beginning with a 5, I cannot click on the "Sweep" button whereas I can click on that button when I put a privkey beginning with K or L. Doesn't 5 at the beginning mean it's encrypted? I guess you've already figured it out, but next time you could always see different values by inputting them on https://www.bitaddress.org if you have any troubles. I'd suggest downloading the website and doing everything offline for added security. no, the uncompressed private keys start with 5 like the following ( https://en.bitcoin.it/wiki/Private_key): 5Kb8kLf9zgWQnogidDA76MzPL6TsZZY36hWXMssSzNydYXYB9KF
Bitaddress clearly shows that. Here's a screenshot of a test key I generated using it. The WIF key starts with a 5 and the compressed WIF key starts with a K or an L. Counter intuitively the compressed WIF key is one character longer than the other.  |
|
|
|
Thing is, it really isn't about to fork any time soon, not without consensus. I'd be willing to wager that too. Does not matter though, too much uncertainty for new money to bare. The downside to the influx we witnessed these past couple months. Question is, when will the fog lift?
Yeah, $750 could be tested, but I would not be shocked to see one more push up the the 1025 range first.
Zooming out on the charts you can see what looks like a cup and handle. This dump could be necessary before the handle forms. In the long run I'm not worried, I don't think there will be a fork, and sooner or later that handle will form. The best time to buy is when there's blood on the streets, and that's probably now. As in December 2013 size cup? That's what I'm hoping for. The price has been held back by so many events for so long that I'm beginning to wonder if the market's stopped caring and just wants to go up regardless of what happens. There's a giant cup in the charts that's just waiting for a 2013 style handle. |
|
|
|
Thing is, it really isn't about to fork any time soon, not without consensus. I'd be willing to wager that too. Does not matter though, too much uncertainty for new money to bare. The downside to the influx we witnessed these past couple months. Question is, when will the fog lift?
Yeah, $750 could be tested, but I would not be shocked to see one more push up the the 1025 range first.
Zooming out on the charts you can see what looks like a cup and handle. This dump could be necessary before the handle forms. In the long run I'm not worried, I don't think there will be a fork, and sooner or later that handle will form. The best time to buy is when there's blood on the streets, and that's probably now. |
|
|
|
The bottom may be in but if $900 does not hold $750-$775 is possible.
There's speculation the Chinese exchanges are close to opening withdrawals. Huobi now says the new stringent KYC rules won't apply to most customers. I don't know what effect opening withdrawals will have, but it could alter the sentiment. https://cointelegraph.com/news/bitcoin-exchange-funds-reporting-not-for-all-users-huobiChinese Bitcoin exchange Huobi has clarified that requests for proof of origin and destination of funds is just for users with potential money laundering risks.
In an update to its original circular, which was translated by cnLedger last week, the exchange stressed that other customers would not be affected by the requirements.
Publication of the message sparked speculation that China was about to re-allow Bitcoin withdrawals from exchanges in line with new regulatory moves by the central bank and others. |
|
|
|
Try selecting tools in the menu bar, then clicking network. When the network settings windows opens uncheck "select server automatically" and keep trying different servers in the list. Sometimes a particular server is out of sync with the blockchain, and switching to another fixes that.  Also your firewall might be blocking electrum from accessing the internet. Search for your address in this website to find out if its already been sent coins. If that site shows your address was sent the coins then there's some sort of problem with your electrum wallet. https://blockchain.info/ |
|
|
|
Anyone here has any experience using raspberry and sites like bittaddress.org for creating a paper wallet?
I mean, Instead of using a PC, we use a raspberry to access the website, load the page, disconnect, create the wallet, print the wallet, then format the whole raspberry SD card.
Is it safe to do that?
As far as I know that should be safe to do. You may want to run a test on it first with a small amount just to check it works. The only concern I have about it is how effective a raspberry is at generating random data. Normal PCs employ random events such as interrupts and hard drive reads. A raspberry has no hard drive, it lacks one of the biggest sources of random data available to PCs. I'm not sure if it matters, but I'd consider the risk of a raspberry generating weak private keys. https://seifried.org/lasg/encryption/In order for encryption to be effective, especially on a large scale such as IPSec across many hosts, good sources of random, cryptographically secure data are needed. In Linux we have /dev/random and /dev/urandom which are good but not always great. Part of the equation is measuring 'random' events, manipulating that data and then making it available (via (u)random). These random events include: keyboard and mouse input, interrupts, drive reads, etc.
However, as many servers have no keyboard/mouse, and onsider the risk of it cnew "blackbox" products often contain no harddrive, sources of random data become harder to find. Some sources, like network activity, are not entirely appropriate because the attacks may be able to measure it as well (granted this would be a very exotic attack, but enough to worry people nonetheless). A raspberry should be able to use an SD card in the same way a computer uses a hard drive. In this instance, it seems there may be a problem with how random the operating system can actually be at generating addresses. I don't know exactly how bitaddress.org generates its random. There's a discussion about it here, but I haven't looked into it further or reviewed the source code. Maybe it only uses human based mouse random input, but if it also collects random data from hard drives it's worth considering any risks. That particular issue discussed on github was that without mouse movement during the seeding the seed value was just the current time. It was fixed in 2013, but I don't know what additional sources of random they added since then, or if it only relies on mouse movements and the current time. https://github.com/pointbiz/bitaddress.org/issues/35
You could always try producing 100 addresses and private keys to start with, wiping the pi and doing the same thing again.
If there are any anomalies this could be determined here (also check if the address has already been used might be a good idea as you know then that it isn't random).
I don't think producing 100 addresses is enough to test for anomalies. How would you test them? NIST produced some software for conducting statistical testing on data produced by random number generators. However it requires compiling, and needs huge data sets to work with. http://csrc.nist.gov/groups/ST/toolkit/rng/documents/SP800-22rev1a.pdfThis paper discusses some aspects of selecting and testing random and pseudorandom number generators.The outputs of such generators may be used in many cryptographic applications, such as the generation of key material. Generators suitable for use in cryptographic applications may need to meet stronger requirements than for other applications. In particular, their outputs must be unpredictable in the absence of knowledge of the inputs. Some criteria for characterizing and selecting appropriate generators are discussed in this document. The subject of statistical testing and its relation to cryptanalysis is also discussed, and some recommended statistical tests are provided. These tests may be useful as a first step in determining whether or not a generator is suitable for a particular cryptographic application. However,no set of statistical tests can absolutely certify a generator as appropriate for usage in a particular application, i.e., statistical testing cannot serve as a substitute for cryptanalysis This is the download link for the the NIST Statistical Test Suite software. http://csrc.nist.gov/groups/ST/toolkit/rng/documentation_software.htmlTesting if a sequence of numbers is random is incredibly difficult, as random.org points out. https://www.random.org/analysis/If you flip enough coins, you will get sequences of coin flips that seen in isolation from the rest of the sequence don't look random at all. Scott Adams has drawn this as a Dilbert strip, which is funny exactly because it is true: What Dilbert is told is correct: It is impossible to prove definitively whether a given sequence of numbers (and the generator that produced it) is random. It could happen that the creature in the comic strip has been generating perfectly random numbers for many years and that Dilbert simply happens to walk in at the moment when there's six nines in a row. It's not very likely, but if the creature sits there for long enough (and Dilbert visits enough times), then it will eventually happen. There is more software for testing randomness called dieharder. It doesn't run all the NIST tests yet, but earlier software it's based on (called diehard) required a default input to work on of ten million random numbers in a file. Dieharder requires much more data than that to run sensitive tests. http://www.phy.duke.edu/~rgb/General/dieharder.phpDieharder differs significantly from diehard in many ways. For example, diehard uses file based sources of random numbers exclusively and by default works with only roughly ten million random numbers in such a file. However, modern random number generators in a typical simulation application can easily need to generate 10^18 or more random numbers, generated from hundreds, thousands, millions of different seeds in independent (parallelized) simulation threads, as the application runs over a period of months to years. Those applications can easily be sensitive to rng weaknesses that might not be revealed by sequences as short as 10^7 uints in length even with excellent and sensitive tests. One of dieharder's primary design goals was to permit tests to be run on very long sequences.
*snip*
In addition to implementing all of the diehard tests it is expected that dieharder will eventually contain all of the NIST STS and a variety of tests contributed by users |
|
|
|
|
Show Posts
