Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Bitcoin Android Security

All Bitcoin Wallets On Android Vulnerable To Theft 137

Posted by samzenpus from the protect-ya-neck dept.
judgecorp writes "Bitcoin users have been warned that storing them in a wallet app on Android is insecure, A weakness in Android's random number generator means its random numbers may not be so random, giving attackers a chance of breaking into the wallet. those with Bitcoins have been advised to put them elsewhere, by bitcoin.org"
This discussion has been archived. No new comments can be posted.

All Bitcoin Wallets On Android Vulnerable To Theft More

All Bitcoin Wallets On Android Vulnerable To Theft

Comments Filter:

  • How can an OS have such a fundamental problem? (Score:5, Interesting)

    by Karganeth ( 1017580 ) on Monday August 12, 2013 @07:51AM (#44540749)
    It's ridiculous in this day and age that an OS can fail to make random numbers properly. That's one of the most basic operations. How lazy/incompetent are the Google programmers?

    • It's a pity. Bitcoin would be a powerful payment method on mobile devices, for small amenities (e.g. coffee).

      • Re: (Score:2)

        by _merlin ( 160982 )

        Not really - transaction processing takes far to long because the network has to agree on it.

        • Not really - transaction processing takes far to long because the network has to agree on it.

          How long does it take these days?

          If the store uses what they would pay as fees to credit card companies as Bitcoin safety, it would probably still pay off. Also, only few people will not pay, especially not returning customers.

          • Depends pm what you mean. Any time there are less than, I believe the number is 5400 blocks in two weeks, that the hardness adjusts to attempt to maintain, or about one block every 10 minutes. Technically, if someone can present a valid transaction, you could accept it instantly and say bitcoin has no delay.

            Technically the transaction isn't official till its in a block, but once its transmitted out to the network valid, its almost guaranteed to be in one within 10 minutes or so, and each block that buries it, solidifies it further.

            What is accepted? Last I looked, the default client didn't consider a transaction accepted until several blocks AFTER it was accepted, so we are talking 20-30 minutes or so.

            But.... you could accept bitcoins "instantly" (pretty quick anyway) if you have the most recent block chain, and are sure the transaction has been transmitted out to the public network. There are some small risks in terms of the possibility of accepting a transaction while the block chain is split and a competing transaction being inserted into the other chain, which then wins.... but.... if anyone really does make exploiting such a situation practical and profitable, countermeasures could be achieved pretty easily, it wouldn't be hard to use multiple nodes to watch for block chain splits and monitor what transactions are going out.

            Have a few nodes that are not peers of eachother, one transmits the transaction, all the rest watch for it, and watch for splits/competing transactions, etc. I am sure somebody can come up with a pretty safe way to fast accept bitcoins if they haven't already.

            • Just a few corrections. The targeted rate is 2016 blocks per 14 days. The default client allows you to spend incoming coins after one confirmation.

            • Re: (Score:1)

              by Anonymous Coward

              NO! You can not accept a transaction without it being in the blockchain, lest you enable the spender to double-spend. It doesn't take a split. The spender can just issue a different transaction on the same sources after you've accepted the transaction and before "your" transaction goes into the blockchain.

              • Re: (Score:2)

                by TheCarp ( 96830 )

                Meh, you are right of course, but, there is always some tradeoff between convinence and risk. Yes, theoretically the safe bet is to wait for it to enter the block chain, and even safer, to wait for a few confirmations. You know what though, many transactions that people do, are ones where this level of risk is acceptable because the barrier to cheating outweights the benefit for low value transactions.

                I mean seriously, how many vendors accept credit cards now? Do you really think the risk involved with deal

                • Meh, you are right of course, but, there is always some tradeoff between convinence and risk. Yes, theoretically the safe bet is to wait for it to enter the block chain, and even safer, to wait for a few confirmations. You know what though, many transactions that people do, are ones where this level of risk is acceptable because the barrier to cheating outweights the benefit for low value transactions.

                  I mean seriously, how many vendors accept credit cards now? Do you really think the risk involved with dealing with credit card processors is lower than that of accepting bitcoin transactions instantly? Some amount of risk is always acceptable; its just a matter of where you draw that line.

                  Frankly, I think it should be possible to reasonably mitigate most of those concerns without much change in the system.

                  Getting a credit card in multiple places at the same time (to make instant transaction fraud practical/profitable) is pretty tricky AND illegal. Getting a bitcoin wallet in the same place at the same time is trivial AND legal. There is also a healthy margin included in credit card fees, specifically to account for fraud. People will not want to switch to a system where fraud was hot-potatoed to the last one holding the invalid bitcoin transaction, no matter how many technical advancements are layered on

                  • Re: (Score:2)

                    by TheCarp ( 96830 )

                    > Getting a credit card in multiple places at the same time (to make instant transaction fraud
                    > practical/profitable) is pretty tricky AND illegal. Getting a bitcoin wallet in the same place at the
                    > same time is trivial AND legal.

                    Legal? Pretty sure its still fraud. Not only that but it leaves behind a signed transaction that only the fraudster could have produced. We have already seen someone lose in court after trying the "But bitcoins are not real money" excuse. They are, and a contract is a cont

              • No, he can't. He can try and race your broadcast, but miners do not accept double spends against the mempool. You can't just arbitrarily replace transactions like that. If you receive an unconfirmed transaction, unless your opponent has a ton of mining power and can choose the exact moment he purchases from you, and the good he's buying is immediately and irreversibly deliverable, it's not typically an issue.

        • There are workarounds to this already in use. Bitinstant is one that promises trusted "instant" transactions for bitcoin with specific vendors, although they're reworking their website right now. Others will follow. It'll be a matter of dealing with trusted big-name transaction clearinghouses that settle bitcoin transactions in real-time between their own customers while also transmitting to the network for inclusion in the chain later.

          • History suggests that you are using a very loose definition of "trusted".

            • "Trusted" to a cryptographer means "if this guy doesn't do what he claims to, the system breaks". It's nothing to do with being trustworthy.

          • Re: (Score:1)

            by SlashV ( 1069110 )
            I would say the main advantage of bitcoin is that you *don't need* "big-name transaction clearinghouses". If you use those, you might just as well just pay with your creditcard.

        • Not really - transaction processing takes far to long because the network has to agree on it.

          I dunno, in a cafe you usually pay after you've eaten. I'd assume the time it takes to drink a coffee would be ample time to have a bitcoin transaction approved.

        • The effort to create a double spend is not free. For most transaction in day to day life the effort cost and chance involved would be more than the transaction itself, so not worth trying. A transaction propagates through the network pretty much instantly and they can be on their way with a cup of coffee/groceries with less risk than a credit card being charged back. And of course, if you're not paying to Visas rates for the transaction you can afford a bit more risk even if it were present. For a car, inte
      • I imagine that some sort of store-credit type thing would work better for this type of scenario. For instance, while credit cards give you a real-time accepted/denied decision, it still takes days for the transaction to fully process on the back-end. I imagine that Starbucks is a lot more certain that transactions will go through when paid with one of their pre-paid store cards.

        It's a bit more inconvenient, I will admit. But it makes commonplace Bitcoin transactions a lot more realistic. And the conc

    • Re:How can an OS have such a fundamental problem? (Score:5, Insightful)

      by gweihir ( 88907 ) on Monday August 12, 2013 @07:59AM (#44540797)

      It is both a solved problem and an ignored problem. I find that I have to explain the risks of not using proper random numbers for anything cryptographic time and again even to customers with experience in using cryptography. I blame the CS and programmer education, which is still badly broken when it comes to security.

      • Question: would it be correct or incorrect to...

        suppose you take your best pseudo-random generated number, and xoror seed it with a word made by stringer together the second-lowest bit each from the temperature gauge, the gps-x the gps-y ,the compass, the ping time, and so on?

        Would that #increase# or #decrease# the entropy on the random number generator?

        • Re: (Score:2, Interesting)

          by Anonymous Coward

          Question: would it be correct or incorrect to...

          suppose you take your best pseudo-random generated number, and xoror seed it with a word made by stringer together the second-lowest bit each from the temperature gauge, the gps-x the gps-y ,the compass, the ping time, and so on?

          Would that #increase# or #decrease# the entropy on the random number generator?

          It would increase it only if you aren't showing a temp of 32F and a GPS of 00N/00W heading of 0, and a ping of 0 and so on. Seeding from things that arent *surely* good and random is not a smart idea. Why didn't you mention the accelerometers? A program with a little sense to turn on the accels, ask you to shake the phone up a bit, and validate that the results aren't all the same should yield enough to do a good unpredictable RNG seed.

          • Re: (Score:3)

            by gweihir ( 88907 )

            Indeed. You need to know that your entropy sources provide _more_ entropy than needed in the worst case.

            But the problem in this case seems to be that Java SecureRandom is broken, while the Linux kernel /dev/random is perfectly fine, yet unused. There seem to be BitCoin apps for Android that are not vulnerable, because the y use /dev/random. This basically means that the designers of Java SecureRandom on Android messed up badly. Which is a disgrace, as it means Google had nobody with actual security skills

        • Re:How can an OS have such a fundamental problem? (Score:5, Insightful)

          by Joce640k ( 829181 ) on Monday August 12, 2013 @08:39AM (#44541009) Homepage

          The problem isn't doing it, the problem is in getting the "random needs effort" message though thick developer's skulls.

          (Same as most other cryptographic problems, eg. correctly implementing AES isn't what makes your code secure, it's only the very first step...)

          • The problem isn't doing it, the problem is in getting the "random needs effort" message though thick developer's skulls.

            You think that, but you have no idea the depths of perversity developers will go to to avoid learning the simple facts that you have internalised.

            This developer clearly believed that random numbers do indeed need effort:

            http://thedailywtf.com/Articles/Random-Stupidity.aspx [thedailywtf.com]

          • The problem isn't doing it, the problem is in getting the "random needs effort" message though thick developer's skulls.

            I'm sorry this is unacceptable and dangerous. Expecting developers to get this right is inviting platform failure the same way expecting developers to get SQL and HTML escaping right has earned PHP a certain reputation or expecting Android users to understand the repercussions of allowing n00b0wnrz flashlight app to run on their device has doomed millions of end users to ownage.

            In 2013 random numbers should just work by default with no effort on the developers part either by an OS managed entropy pool (e.g

          • Re: (Score:2)

            by gweihir ( 88907 )

            Indeed. And add to that "secure crypto needs independent review". But I guess Google does not have enough money to pay for that. Oh, wait.

      • Re: (Score:2)

        by delt0r ( 999393 )
        It is not a solved problem. Generating truly random numbers is hard. Even with hardware, which should be part of every cpu, its not that easy either.

    • It's ridiculous in this day and age that an OS can fail to make random numbers properly. That's one of the most basic operations. How lazy/incompetent are the Google programmers?

      To be fair, aren't random numbers genuinely hard to produce with a computer?

      I'd have thought that a mobile phone would be a great source of genuinely random data though. Surely tapping into a compass, an accelerometer or a camera could produce genuinely random input?

    • Re: (Score:2)

      by tlhIngan ( 30335 )

      It's ridiculous in this day and age that an OS can fail to make random numbers properly. That's one of the most basic operations. How lazy/incompetent are the Google programmers?

      Especially since most SoCs used in Android actually have hardware cryptographic accellerators, and one feature of them was a hardware RNG.

      Granted, hardware RNGs vary in quality, but most do a very decent job. Even several generations old CPUs have RNG instructions (Intel CPUs, for example - they've had RNGs built in since Core2 days

    • Re: (Score:1)

      by SlashV ( 1069110 )
      Have you ever looked at the android source code? I have done some hacking on cyanogenmod and it's amazing what kind of crap can be found in a code base that is being used by several hundred million(!) people..

    • Re: (Score:3)

      by kasperd ( 592156 )
      It is build on top of Linux, which has /dev/urandom. I'd like to know if this is a generic kernel bug, or if Android doesn't use /dev/urandom.

      You could work around such issues in user code. You could for example have your own 20 byte random seed which you concatenate with 21 bytes from the system random number generator and 14 bytes from other sources (the later don't need to be high entropy, every extra bit helps). Now send the entire 55 bytes through SHA1 and store the output as seed for the next itera

      • You could for example have your own 20 byte random seed which you concatenate with 21 bytes from the system random number generator and 14 bytes from other sources (the later don't need to be high entropy, every extra bit helps). Now send the entire 55 bytes through SHA1 and store the output as seed for the next iteration.

        And since SHA1 has a fixed length, the 20 bytes with zero entropy you fed into it forced out some of whatever entropy the other 35 bytes contained. Luckily, in this case you only force ou

        • Re: (Score:3)

          by kasperd ( 592156 )

          And since SHA1 has a fixed length, the 20 bytes with zero entropy you fed into it forced out some of whatever entropy the other 35 bytes contained. Luckily, in this case you only force out some of SHA1's chunk padding

          Nothing is forced out. 55 bytes plus padding fits within a single block of SHA1 compression.

          but you still aren't accomplishing anything useful by adding compile-time constants either.

          I didn't propose usage of any constants.

          Cryptography is something that really, really, really should be left for

      • Comment removed based on user account deletion

        • Re: (Score:3)

          by kasperd ( 592156 )

          /dev/urandom is not a cryptographically secure source of random numbers.

          Maybe you should actually have taken a look at the source before trying to educate somebody who has. It is clearly stated in the source, that /dev/urandom produces cryptographically strong random numbers.

          /dev/random is (when correctly implemented). In fact, it's supposed to be better than the frivolous combining-bits-and-hashing scheme you propose.

          LOL. You probably don't even know the difference between what I proposed and what /dev/ran

      • The problem is that they're using /dev/urandom when they should be using /dev/random. /dev/urandom is a PRNG, and apparently (on Android, at least) not a very good one. Dalvik's SecureRandom should be using /dev/random instead - yes, it can block and cause loss of responsiveness (stop doing expensive operations on your UI thread, numbskulls...) - but they went for the less-secure option of using urandom for *everything*.

        • Re: (Score:2)

          by kasperd ( 592156 )

          The problem is that they're using /dev/urandom when they should be using /dev/random. /dev/urandom is a PRNG, and apparently (on Android, at least) not a very good one.

          A Google employee who is involved with bitcoin told me, that the way the problem got fixed was by using direct reads from /dev/urandom.

    • Re: (Score:2)

      by Hentes ( 2461350 )

      There's a tradeoff between security and speed. Android have chosen speed since most apps using a RNG are just games that don't care much about the quality. I guess the philosophy is that apps that rely on cryptographically strong random numbers will make their own RNG or use a third-party one.

      • That's why there's /dev/random and /dev/urandom. The problem is, they use /dev/urandom for everything, including their so-called SecureRandom implementation.

    • It's ridiculous in this day and age that an OS can fail to make random numbers properly. That's one of the most basic operations.

      But also one of the most difficult ones, since computers are by design deterministic and we would ideally have each bit be independent of anything else in existence. So you either need specialized hardware or rely on some kludgy workaround, such as timing system events. But of course if you do use specialized hardware, you not only get more costs but are now trusting a black box

    • Re: (Score:2)

      by mcrbids ( 148650 )

      I'd think that an Android device has a number of excellent sources of randomness: Wifi signal, cell signal, accellerometer inputs, and light sensor light levels in conjunction with the usual *nix generators based on system load variables (memory/cpu/io) should mean that mobile devices should have *excellent* randomness.

    • Every time RNG in Android crops up I can't but think of this discussion...
      http://code.google.com/p/android/issues/detail?id=42265 [google.com]

    • Re: (Score:2)

      by Pathwalker ( 103 )

      I believe the issue carried over from Apache Harmony, if this [scribd.com] is the issue at fault.

    • Re: (Score:2)

      by delt0r ( 999393 )
      Cryptographic randomness is not easy. Its not easy in hardware either and the hardware still doesn't support a random generator.

  • The bigger issue... (Score:5, Informative)

    by supersat ( 639745 ) on Monday August 12, 2013 @07:55AM (#44540769)

    ... is that supposedly Android's "secure" random number generation... isn't. This could potentially affect much more than Bitcoin wallets.

    Does anyone know what the issue is? This article [thegenesisblock.com] seems to suggest it's a vulnerability in the SecureRandom class, but no actual details.

    • Some details (Score:5, Informative)

      by grimJester ( 890090 ) on Monday August 12, 2013 @08:28AM (#44540931)
      Here [bitcoinmagazine.com]

      The problem is this: the elliptic curve digital signature algorithm, which Bitcoin transactions rely on for security, has three inputs: the transaction, the signerâ(TM)s private key and a random number. The algorithm then outputs two values, denoted r and s, where s is calculated with the formula k-1(z+rd), z being the hash of the message, k the random number and d the private key. r is dependent only on k. Thus, if the owner of an address signs two transactions with the same random number (and of course the same private key, as every address is linked to one private key), one can extract two s values from the two signatures, subtract them to make the rd terms cancel out, and extracting the private key from there becomes a simple division problem (a more detailed writeup can be found here [nilsschneider.net]). Normally, this is not a problem; given a true random number generator, the first âoecollisionâ should take place roughly at the same time as the heat death of the universe. As it turned out, however, java.security.SecureRandom proved to be not so random, generating the same âoerandomâ number twice on many occasions.

      I just noticed the "found here" link goes to an article from January. That makes me both unsure they've got the right bug and annoyed it hasn't been fixed already.

    • Comment removed based on user account deletion

      • The correct and highest voted answer on that page says to avoid seeding SecureRandom yourself. It's designed to be the most secure with its default constructor. The issue is that Android's implementation of SecureRandom is bad even when you use it correctly.

        • Hmmm. If true, this is *catastrophically* bad, because it clouds the security of EVERY implementation of client-side cryptography under Android.

          For years, java.util.SecureRandom has been the bedrock foundation of all encryption under Java (and by extension, Android, even if Android technically isn't Java). A vulnerability in SecureRandom doesn't just bork bitcoins... it screws up things like PBKDF2, DH key exchange (and by extension, SSL & RSA), and even AES (if you're using it client-side to generate a

          • It is really concerning. I'm hoping that existing SSL/TLS libraries rely on /dev/u?random instead of (in)SecureRandom, or else there might be a lot of stored ciphertext communications getting cracked about now.

            At least there's an easy way to patch it in Android apps. Here's the patch [google.com] that works around the issue in the Android Bitcoin client. It patches SecureRandom to just read from /dev/urandom instead.

            • Comment removed based on user account deletion

            • I would argue that reading /dev/random would be much better in this case - yeah, it might block, but you probably shouldn't be pulling large amounts of data out of the RNG. I mean, that's the whole reason we have crypto algorithms, rather than just using a ton of one-time pads; a nice short sequence of bits (128 of them, for typical AES usage) is enough. Yeah, you need IVs (or k-values for ECC) but those don't have to be *securely* random, only unique. In fact, by their very nature, they are public values.

  • Random numbers on a mobile device (Score:3)

    by Kinthelt ( 96845 ) on Monday August 12, 2013 @07:55AM (#44540771) Homepage

    Shouldn't the RNG tap into the device's accelerometer? That should provide random data if the user gives it a few successive shakes.

    • Re:Random numbers on a mobile device (Score:5, Insightful)

      by gweihir ( 88907 ) on Monday August 12, 2013 @08:00AM (#44540801)

      The problem is not doing it right once you understand the issue. The problem is understanding the issue.

      • The problem is not doing it right once you understand the issue. The problem is understanding the issue.

        In my experience, the problem is not understanding the issue but either acknowledging there is an issue or even making the effort to investigate whether there might be one.

    • Re:Random numbers on a mobile device (Score:5, Interesting)

      by c ( 8461 ) <beauregardcp@gmail.com> on Monday August 12, 2013 @08:44AM (#44541037)

      Shouldn't the RNG tap into the device's accelerometer?

      The Linux kernel has has the ability to push device input into the random number entropy pool for a long time (/dev/random and /dev/urandom). If the device drivers aren't pumping accelerometer events into the pool, someone really missed an opportunity.

      In this case, it sounds like something went wrong with the Java/Dalvik random number generator. It's not clear to me from glancing at the various write-ups whether it's a failure to RTFM on the part of the Bitcoin wallet writers (or maybe whoever wrote a common Bitcoin reference implementation) or if there's something broken in the Android implementation of the RNG class.

  • There aren't many details floating around but it looks like the issue is that the RNG can return the same number on two occasions. However the possibility of returning the same random number again in the future is a perfectly expected property of any RNG; presumably they mean that the probability is much higher than normal?

    • It's like random in a CD player, it will repeat songs before it even gets to another. I prefer 'shuffle', where the list is randomized and then played through before reshuffling.

      • Right. If Bitcoin mistakenly assumed that the RNG "shuffled" numbers and they would not be reused, I don't think that's an Android bug. However given that Bitcoin clients work fine on every other platform I assume that's not the problem and there genuinely is something up with the RNG.

    • Re:Number re-use? (Score:5, Informative)

      by Agent ME ( 1411269 ) <agentme49&gmail,com> on Monday August 12, 2013 @09:02AM (#44541185)

      The chance of getting the same number twice should be equal to the chance of an attacker brute-forcing it. Judging by the fact some keys were brute-forced in well under a billion years, I'm going to assume it's much more likely that Android's RNG is broken.

  • Since they are generated by algorithms that give repeatable results - this isn't news. The distribution is random (usually) but the sequence is not. You need to tap into some aspect of the hardware if you hope to get true randomness and even then, unless you're measuring some quantum effect the random aspect might not be quite so random as you at first think.

    • "Arbitrary number generator" might be a more useful name, where the numbers generated follow a given distribution and their selection is arbitrary. Calling them pseudo-random invites mistaken conclusions.

      • Calling them pseudo-random invites mistaken conclusions.

        Calling them just plain random would be to do that. Pseudo- covers it off nicely, I think. Looks like, but ain't. In fact if the sequence is repeatable (given the same seed), they're demonstrably not arbitrary.

    • Good random number generators exist elsewhere. Most modern encryption relies on them. The fact that someone spectacularly messed up an RNG with disastorous exploitable results is news.

    • Re: (Score:2)

      by TheCarp ( 96830 )

      Cell phones already have a great RNG, its called the "touch screen"....aka the same RNG thats used to dial random international numbers every time it decides to randomly unlock in your pocket.

      Could just have the touch screen polled randomly while the screen is off, if some random portion is being pressed, extract some entropy from it and toss it in the pool. I am pretty sure the interactions between my thigh, pants, and screen could produce every bit as much entropy as wiggling a mouse around.

  • If the problem is with Android's RNG, then any secure application on Android may be at risk.

  • Feature required by FISA court, gagged. NSA programmers did the work, in a joint venture with Google.

  • Comment removed based on user account deletion

    • Re:Description of vulnerability (Score:5, Informative)

      by Agent ME ( 1411269 ) <agentme49&gmail,com> on Monday August 12, 2013 @09:10AM (#44541263)

      By "implement" you mean "use"?

      From looking at the Android Bitcoin client's code, it appears it already used SecureRandom correctly (default empty constructor). The Android implementation of SecureRandom itself is broken.

      • Re: (Score:1)

        by alonz ( 21571 )

        From a brief trawl of the Android sources, it looks like Android's new-and-shiny OpenSSL-based SecureRandom only seeds the OpenSSL random generator if you open a TLS socket. If you don't - you will be using an unseeded OpenSSL RNG.

  • They're already so far beyond stupid for doing it anyway, this is beside the point. If your phone gets stolen or your phone has a hardware failure, your wallet is toast and there goes all your money permanently. Some apps have ways to move your wallet file from a PC to a phone but then it shouldn't have a problem with random number generation since the encrypted wallet came from a PC.

    • Re: (Score:1)

      by Anonymous Coward
      >If your phone gets stolen or your phone has a hardware failure, your wallet is toast and there goes all your money permanently.

      This is why bitcoin wallets allow backup to a file encrypted with a passphrase. If you lose your device, you simply restore your wallet to a new one.
  • No wonder my craps game always comes up snake eyes.

  • I have to wonder did someone sit around a table and brainstorm the most innocuous repercussion of RNG failure possible?

  • Nitpicky guy here. Wouldn't unsecure be the right word? The meaning of insecure is primarily "Not confident or assured; uncertain or anxious."

  • This certainly affects Bitcoin the most, but a random number generator that actually produces the same "random" numbers is hardly random at all, and could present a serious problem for all types of applications. In fact, that's an entirely-broken random number generator. I'm wondering how such an egregious PRNG/seeding-algo made it this long without someone noticing. Maybe it's because Bitcoin provides a financial incentive to find these flaws, and honestly it's pretty easy to spot it from a one-minute b

  • The most cursory search will turn up similar complaints for every OS's library random-number routine, over the history of computing. It's quite common for a random-number routine that has been good for years to suddenly become non-random in a new release. Basic advice has always been that, if it's important to have truly "random" numbers with any specific property, you should simply ignore any routines that came from vendors. You should look in "the literature" for routines with the properties you need, and have a good programmer (i.e., one who can handle basic arithmetic ;-) to code it up in whatever language you're using.

    And part of your testing suite is a test of your random-number routines(s), to verify that they are still generating numbers with the appropriate level of randomness. It's funny what things like "improved" optimizations in the compiler can do to the correctness of such code.

    If the bitcoin software managers are using any OS's random-number generators, well, they're just incompetent. Their job should be handed to someone with minimal understanding of the math that they're using. Someone who will ensure that other managers don't force their programmers to do it wrong.

    (Yes, I have been ordered by several managers to implement incorrect arithmetic. I've generally responded by writing and distributing a proof of the incorrectness of my orders, and updated my resume. Sometimes they've responded by putting me in charge of the math routines in question. But far more often, I've found a new job. ;-)

    (But this wasn't quite as funny as the case where a manager gave us written orders that clearly required that we implement messages that went faster than light. We quickly learned that his superiors supported him, so the entire team had new jobs a week later. We eventually learned that the product was finally abandoned. ;-)

  • mt gox is secured (insured?) against hacking so if someone hacks me(i probably need a dongle for that) ... or en masse ... i dont lose a penny (or a bit in this case)
    then again im not a blind person living under the illusion that a blockchain where every transaction is visible to everyone forever is anonimity so i wouldnt use it for
    sub-
    legal activities unless i really knew what i was doing or had a five star blackhat working for me ...

Slashdot Top Deals

Keep up the good work! But please don't ask me to help.

Close