Cryptography's random number problem?











up vote
3
down vote

favorite












Sophie Chen at Wired Magazine;




quantum mechanics could solve cryptography's random number problem




Such machine already exist, but it's too huge and not so fast in order to use it all the time.



Anyway, can it solve the problems connected to randomization and security or it will be still vulnerable?










share|improve this question









New contributor




user50486 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
















  • 6




    What's the problem supposedly being solved?
    – Maeher
    10 hours ago






  • 5




    Welcome to crypto.se - Here is some advice to help you get an answer for your question: What is cryptography's random number problem? What machines are you referring to? TRNGs based on quantum effects can be the size of regular computer hardware. We can't answer "Can it solve the problems connected to randomization and security" without knowing what "it" is and what problems you are referring to.
    – Ella Rose
    10 hours ago






  • 4




    also, “who” says this? the quote source would help with context
    – b degnan
    10 hours ago















up vote
3
down vote

favorite












Sophie Chen at Wired Magazine;




quantum mechanics could solve cryptography's random number problem




Such machine already exist, but it's too huge and not so fast in order to use it all the time.



Anyway, can it solve the problems connected to randomization and security or it will be still vulnerable?










share|improve this question









New contributor




user50486 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
















  • 6




    What's the problem supposedly being solved?
    – Maeher
    10 hours ago






  • 5




    Welcome to crypto.se - Here is some advice to help you get an answer for your question: What is cryptography's random number problem? What machines are you referring to? TRNGs based on quantum effects can be the size of regular computer hardware. We can't answer "Can it solve the problems connected to randomization and security" without knowing what "it" is and what problems you are referring to.
    – Ella Rose
    10 hours ago






  • 4




    also, “who” says this? the quote source would help with context
    – b degnan
    10 hours ago













up vote
3
down vote

favorite









up vote
3
down vote

favorite











Sophie Chen at Wired Magazine;




quantum mechanics could solve cryptography's random number problem




Such machine already exist, but it's too huge and not so fast in order to use it all the time.



Anyway, can it solve the problems connected to randomization and security or it will be still vulnerable?










share|improve this question









New contributor




user50486 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











Sophie Chen at Wired Magazine;




quantum mechanics could solve cryptography's random number problem




Such machine already exist, but it's too huge and not so fast in order to use it all the time.



Anyway, can it solve the problems connected to randomization and security or it will be still vulnerable?







random-number-generator randomness






share|improve this question









New contributor




user50486 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











share|improve this question









New contributor




user50486 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this question




share|improve this question








edited 11 mins ago









Ella Rose

14.7k44077




14.7k44077






New contributor




user50486 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









asked 10 hours ago









user50486

161




161




New contributor




user50486 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





user50486 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






user50486 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.








  • 6




    What's the problem supposedly being solved?
    – Maeher
    10 hours ago






  • 5




    Welcome to crypto.se - Here is some advice to help you get an answer for your question: What is cryptography's random number problem? What machines are you referring to? TRNGs based on quantum effects can be the size of regular computer hardware. We can't answer "Can it solve the problems connected to randomization and security" without knowing what "it" is and what problems you are referring to.
    – Ella Rose
    10 hours ago






  • 4




    also, “who” says this? the quote source would help with context
    – b degnan
    10 hours ago














  • 6




    What's the problem supposedly being solved?
    – Maeher
    10 hours ago






  • 5




    Welcome to crypto.se - Here is some advice to help you get an answer for your question: What is cryptography's random number problem? What machines are you referring to? TRNGs based on quantum effects can be the size of regular computer hardware. We can't answer "Can it solve the problems connected to randomization and security" without knowing what "it" is and what problems you are referring to.
    – Ella Rose
    10 hours ago






  • 4




    also, “who” says this? the quote source would help with context
    – b degnan
    10 hours ago








6




6




What's the problem supposedly being solved?
– Maeher
10 hours ago




What's the problem supposedly being solved?
– Maeher
10 hours ago




5




5




Welcome to crypto.se - Here is some advice to help you get an answer for your question: What is cryptography's random number problem? What machines are you referring to? TRNGs based on quantum effects can be the size of regular computer hardware. We can't answer "Can it solve the problems connected to randomization and security" without knowing what "it" is and what problems you are referring to.
– Ella Rose
10 hours ago




Welcome to crypto.se - Here is some advice to help you get an answer for your question: What is cryptography's random number problem? What machines are you referring to? TRNGs based on quantum effects can be the size of regular computer hardware. We can't answer "Can it solve the problems connected to randomization and security" without knowing what "it" is and what problems you are referring to.
– Ella Rose
10 hours ago




4




4




also, “who” says this? the quote source would help with context
– b degnan
10 hours ago




also, “who” says this? the quote source would help with context
– b degnan
10 hours ago










2 Answers
2






active

oldest

votes

















up vote
12
down vote













The title of this article is complete hype. Tip: when a journalist says “X could solve Y”, read “X probably won't solve Y”. Much of the content of the article is hype too.



Cryptography has a random number problem, but the problem is not producing random number, and the proposal in this article wouldn't be useful to produce random number anyway.



Cryptography does need random numbers for many things. The problem of obtaining random numbers can be divided into three parts: generating sufficient entropy for security, generating a sufficient quantity and quality random numbers for the applications, and actually bringing the random data where it's needed. The first problem is solvable, the second is solved, the third one is where the difficulty is.



To generate random numbers, it's necessary to have a source of non-determinism. A deterministic computer, by definition, is incapable of producing anything random. But there is no need for any expensive machine using quantum mechanics. Classical mechanics or cheap applications of quantum mechanics are good enough in practice. Your PC has a random number generator, if it isn't an antique. Your phone probably has one too, if it's a not-too-old smartphone. If your credit card has a chip, it has a hardware random generator. You can find microcontrollers that cost a few cents (I'm talking bulk prices here) that have a built-in RNG. Many devices lack one (your home router might not have one), but at current prices it's a supply chain and requirements problem, not a cost problem. If you can control how a device is designed, there's no excuse not to include a hardwarre random generator.



A hardware random generator gives you entropy, but it isn't directly usable for cryptography. It usually has limited bandwidth and biases (no measurement apparatus is perfect). Fortunately, turning an entropy source into a cryptography-grade random generator is a solved problem. All you need to do is to use the entropy source to seed a pseudorandom generator. Any cryptography library has one or more PRNG available.



The real problem with random numbers in practice is getting all the software out there to use them correctly. This is a difficult problem to solve because every piece of software needs to get things right: properly relay the data, don't leave a copy lying around. The operating system driver needs to get it right, the system installer needs to get it right, all the layers of software libraries need to get it right, and the application needs to use the libraries properly. Proper use of randomness is near-impossible to test, so bugs are difficult to detect. Common problems include developers using non-cryptographic random generators when they need cryptographic ones (don't use rand anywhere near cryptographic code!), using a cryptographic PRNG that is not seeded properly (always use your OS's randomness source such as /dev/urandom or CryptGenRandom), using non-random inputs to functions where random input was needed, and systems where the entropy source is not configured properly.



So when the article says




Eventually, it would be great if they shrank the setup to fit on a chip, says Bierhorst: a random number generator in every laptop, so that nobody ever uses those algorithm-based numbers for encryption again.




that's attacking the part of the problem that doesn't need new technology. The reason people use “algorithm-based numbers for encryption” is that either their device lacks a generator which can be built cheaply using current technology, or that there's a problem in the software. This new machine would not help with either part of the problem.



As for the proposed application of a “randomness beacon”, it's a plausible one, but it's of limited use and difficult to put to practice. A randomness beacon, as the article explains, is useless for most cryptographic applications since it wouldn't be secret. It's useful as an impartial arbiter, for example to assign auditors to auditees, but that can be done with any source of randomness. The fact that the machine itself is more difficult to “hack” than a PC with RDRAND is not all that useful, because the hacking could be done in the reporting and logging system.






share|improve this answer

















  • 1




    An additional major problem with hardware random number generators is that they are often very difficult to audit, a hardware source of entropy followed by a hardware whitener (Intel I3/5/7 for example) is indistinguishable from say AES128 in CTR mode unless you know the key to that AES implementation. Because of this you can never be sure that that nice hardware is actually giving you random and not something that collapses if you are the agency that created the key. In this respect a hash of a frame from a webcam or the low bit of the audio sample is probably at least easier to audit.
    – Dan Mills
    3 hours ago










  • @DanMills You can't audit an RNG as a black box. The right way to design an RNG is to give software access to the unwhitened source, and to give auditors full access to both the hardware design and the software design (and manufacturing!). You also need to give the software access to the unwhitened source so that it can detect telltale patterns of bad environment conditions that cause the source to have less entropy than it should.
    – Gilles
    2 hours ago






  • 1




    Yep, which is exactly what Intel didn't do! The point about manufacturing is also very much on point, easy to diddle a metal layer so that your noise diode is short circuited.... the unwhitened source is what the low bit of a 24 bit microphone ADC or ADC connected to a warm resistor is, and at least in the resistor case that is a quantum source (Boltzmann noise). The trap there of course is that small signal analogue is easy to interfere with and computers have lots of things that might couple enough to correlate if the design is not spot on.
    – Dan Mills
    2 hours ago










  • @DanMills Do you know of dopant-level hardware trojans? See §3.2 especially. Uber sneaky.
    – Paul Uszak
    2 hours ago










  • @PaulUszak Yep, sneaky indeed, not the easiest thing to pull off, but kind of tough to spot if you manage it. I doubt that just sneaking a diddled bottle of arsine into TMSC would get it done.
    – Dan Mills
    1 hour ago


















up vote
0
down vote













There isn't really too much of a problem. Uncharacteristically, Wired has produced quite a bad article for a piece of technology. Sophie has focused on the number generation rate, not realising that the machine is not primarily a random number generator. Journalistic licence?



The official paper for the machine and experiment is here. It was built to test the Bell Inequality, and to disprove local realism that might have underpinned quantum mechanics. The size of the machine is necessary to ensure that the pairs of measurements are made outside of their respective light cones. That's the reason for the device's two ~130m legs.The random numbers popping out are just the experimental byproduct put to use via the randomness beacon.



The experiment was successful and local realism has been disproved, thereby supporting Spooky Action paradigms. Spooky indeed.



The other answer clearly demonstrates that small alternative true random number generators already successfully exist.






share|improve this answer





















    Your Answer





    StackExchange.ifUsing("editor", function () {
    return StackExchange.using("mathjaxEditing", function () {
    StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix) {
    StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["$", "$"], ["\\(","\\)"]]);
    });
    });
    }, "mathjax-editing");

    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "281"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    convertImagesToLinks: false,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    noCode: true, onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });






    user50486 is a new contributor. Be nice, and check out our Code of Conduct.










    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcrypto.stackexchange.com%2fquestions%2f64810%2fcryptographys-random-number-problem%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    12
    down vote













    The title of this article is complete hype. Tip: when a journalist says “X could solve Y”, read “X probably won't solve Y”. Much of the content of the article is hype too.



    Cryptography has a random number problem, but the problem is not producing random number, and the proposal in this article wouldn't be useful to produce random number anyway.



    Cryptography does need random numbers for many things. The problem of obtaining random numbers can be divided into three parts: generating sufficient entropy for security, generating a sufficient quantity and quality random numbers for the applications, and actually bringing the random data where it's needed. The first problem is solvable, the second is solved, the third one is where the difficulty is.



    To generate random numbers, it's necessary to have a source of non-determinism. A deterministic computer, by definition, is incapable of producing anything random. But there is no need for any expensive machine using quantum mechanics. Classical mechanics or cheap applications of quantum mechanics are good enough in practice. Your PC has a random number generator, if it isn't an antique. Your phone probably has one too, if it's a not-too-old smartphone. If your credit card has a chip, it has a hardware random generator. You can find microcontrollers that cost a few cents (I'm talking bulk prices here) that have a built-in RNG. Many devices lack one (your home router might not have one), but at current prices it's a supply chain and requirements problem, not a cost problem. If you can control how a device is designed, there's no excuse not to include a hardwarre random generator.



    A hardware random generator gives you entropy, but it isn't directly usable for cryptography. It usually has limited bandwidth and biases (no measurement apparatus is perfect). Fortunately, turning an entropy source into a cryptography-grade random generator is a solved problem. All you need to do is to use the entropy source to seed a pseudorandom generator. Any cryptography library has one or more PRNG available.



    The real problem with random numbers in practice is getting all the software out there to use them correctly. This is a difficult problem to solve because every piece of software needs to get things right: properly relay the data, don't leave a copy lying around. The operating system driver needs to get it right, the system installer needs to get it right, all the layers of software libraries need to get it right, and the application needs to use the libraries properly. Proper use of randomness is near-impossible to test, so bugs are difficult to detect. Common problems include developers using non-cryptographic random generators when they need cryptographic ones (don't use rand anywhere near cryptographic code!), using a cryptographic PRNG that is not seeded properly (always use your OS's randomness source such as /dev/urandom or CryptGenRandom), using non-random inputs to functions where random input was needed, and systems where the entropy source is not configured properly.



    So when the article says




    Eventually, it would be great if they shrank the setup to fit on a chip, says Bierhorst: a random number generator in every laptop, so that nobody ever uses those algorithm-based numbers for encryption again.




    that's attacking the part of the problem that doesn't need new technology. The reason people use “algorithm-based numbers for encryption” is that either their device lacks a generator which can be built cheaply using current technology, or that there's a problem in the software. This new machine would not help with either part of the problem.



    As for the proposed application of a “randomness beacon”, it's a plausible one, but it's of limited use and difficult to put to practice. A randomness beacon, as the article explains, is useless for most cryptographic applications since it wouldn't be secret. It's useful as an impartial arbiter, for example to assign auditors to auditees, but that can be done with any source of randomness. The fact that the machine itself is more difficult to “hack” than a PC with RDRAND is not all that useful, because the hacking could be done in the reporting and logging system.






    share|improve this answer

















    • 1




      An additional major problem with hardware random number generators is that they are often very difficult to audit, a hardware source of entropy followed by a hardware whitener (Intel I3/5/7 for example) is indistinguishable from say AES128 in CTR mode unless you know the key to that AES implementation. Because of this you can never be sure that that nice hardware is actually giving you random and not something that collapses if you are the agency that created the key. In this respect a hash of a frame from a webcam or the low bit of the audio sample is probably at least easier to audit.
      – Dan Mills
      3 hours ago










    • @DanMills You can't audit an RNG as a black box. The right way to design an RNG is to give software access to the unwhitened source, and to give auditors full access to both the hardware design and the software design (and manufacturing!). You also need to give the software access to the unwhitened source so that it can detect telltale patterns of bad environment conditions that cause the source to have less entropy than it should.
      – Gilles
      2 hours ago






    • 1




      Yep, which is exactly what Intel didn't do! The point about manufacturing is also very much on point, easy to diddle a metal layer so that your noise diode is short circuited.... the unwhitened source is what the low bit of a 24 bit microphone ADC or ADC connected to a warm resistor is, and at least in the resistor case that is a quantum source (Boltzmann noise). The trap there of course is that small signal analogue is easy to interfere with and computers have lots of things that might couple enough to correlate if the design is not spot on.
      – Dan Mills
      2 hours ago










    • @DanMills Do you know of dopant-level hardware trojans? See §3.2 especially. Uber sneaky.
      – Paul Uszak
      2 hours ago










    • @PaulUszak Yep, sneaky indeed, not the easiest thing to pull off, but kind of tough to spot if you manage it. I doubt that just sneaking a diddled bottle of arsine into TMSC would get it done.
      – Dan Mills
      1 hour ago















    up vote
    12
    down vote













    The title of this article is complete hype. Tip: when a journalist says “X could solve Y”, read “X probably won't solve Y”. Much of the content of the article is hype too.



    Cryptography has a random number problem, but the problem is not producing random number, and the proposal in this article wouldn't be useful to produce random number anyway.



    Cryptography does need random numbers for many things. The problem of obtaining random numbers can be divided into three parts: generating sufficient entropy for security, generating a sufficient quantity and quality random numbers for the applications, and actually bringing the random data where it's needed. The first problem is solvable, the second is solved, the third one is where the difficulty is.



    To generate random numbers, it's necessary to have a source of non-determinism. A deterministic computer, by definition, is incapable of producing anything random. But there is no need for any expensive machine using quantum mechanics. Classical mechanics or cheap applications of quantum mechanics are good enough in practice. Your PC has a random number generator, if it isn't an antique. Your phone probably has one too, if it's a not-too-old smartphone. If your credit card has a chip, it has a hardware random generator. You can find microcontrollers that cost a few cents (I'm talking bulk prices here) that have a built-in RNG. Many devices lack one (your home router might not have one), but at current prices it's a supply chain and requirements problem, not a cost problem. If you can control how a device is designed, there's no excuse not to include a hardwarre random generator.



    A hardware random generator gives you entropy, but it isn't directly usable for cryptography. It usually has limited bandwidth and biases (no measurement apparatus is perfect). Fortunately, turning an entropy source into a cryptography-grade random generator is a solved problem. All you need to do is to use the entropy source to seed a pseudorandom generator. Any cryptography library has one or more PRNG available.



    The real problem with random numbers in practice is getting all the software out there to use them correctly. This is a difficult problem to solve because every piece of software needs to get things right: properly relay the data, don't leave a copy lying around. The operating system driver needs to get it right, the system installer needs to get it right, all the layers of software libraries need to get it right, and the application needs to use the libraries properly. Proper use of randomness is near-impossible to test, so bugs are difficult to detect. Common problems include developers using non-cryptographic random generators when they need cryptographic ones (don't use rand anywhere near cryptographic code!), using a cryptographic PRNG that is not seeded properly (always use your OS's randomness source such as /dev/urandom or CryptGenRandom), using non-random inputs to functions where random input was needed, and systems where the entropy source is not configured properly.



    So when the article says




    Eventually, it would be great if they shrank the setup to fit on a chip, says Bierhorst: a random number generator in every laptop, so that nobody ever uses those algorithm-based numbers for encryption again.




    that's attacking the part of the problem that doesn't need new technology. The reason people use “algorithm-based numbers for encryption” is that either their device lacks a generator which can be built cheaply using current technology, or that there's a problem in the software. This new machine would not help with either part of the problem.



    As for the proposed application of a “randomness beacon”, it's a plausible one, but it's of limited use and difficult to put to practice. A randomness beacon, as the article explains, is useless for most cryptographic applications since it wouldn't be secret. It's useful as an impartial arbiter, for example to assign auditors to auditees, but that can be done with any source of randomness. The fact that the machine itself is more difficult to “hack” than a PC with RDRAND is not all that useful, because the hacking could be done in the reporting and logging system.






    share|improve this answer

















    • 1




      An additional major problem with hardware random number generators is that they are often very difficult to audit, a hardware source of entropy followed by a hardware whitener (Intel I3/5/7 for example) is indistinguishable from say AES128 in CTR mode unless you know the key to that AES implementation. Because of this you can never be sure that that nice hardware is actually giving you random and not something that collapses if you are the agency that created the key. In this respect a hash of a frame from a webcam or the low bit of the audio sample is probably at least easier to audit.
      – Dan Mills
      3 hours ago










    • @DanMills You can't audit an RNG as a black box. The right way to design an RNG is to give software access to the unwhitened source, and to give auditors full access to both the hardware design and the software design (and manufacturing!). You also need to give the software access to the unwhitened source so that it can detect telltale patterns of bad environment conditions that cause the source to have less entropy than it should.
      – Gilles
      2 hours ago






    • 1




      Yep, which is exactly what Intel didn't do! The point about manufacturing is also very much on point, easy to diddle a metal layer so that your noise diode is short circuited.... the unwhitened source is what the low bit of a 24 bit microphone ADC or ADC connected to a warm resistor is, and at least in the resistor case that is a quantum source (Boltzmann noise). The trap there of course is that small signal analogue is easy to interfere with and computers have lots of things that might couple enough to correlate if the design is not spot on.
      – Dan Mills
      2 hours ago










    • @DanMills Do you know of dopant-level hardware trojans? See §3.2 especially. Uber sneaky.
      – Paul Uszak
      2 hours ago










    • @PaulUszak Yep, sneaky indeed, not the easiest thing to pull off, but kind of tough to spot if you manage it. I doubt that just sneaking a diddled bottle of arsine into TMSC would get it done.
      – Dan Mills
      1 hour ago













    up vote
    12
    down vote










    up vote
    12
    down vote









    The title of this article is complete hype. Tip: when a journalist says “X could solve Y”, read “X probably won't solve Y”. Much of the content of the article is hype too.



    Cryptography has a random number problem, but the problem is not producing random number, and the proposal in this article wouldn't be useful to produce random number anyway.



    Cryptography does need random numbers for many things. The problem of obtaining random numbers can be divided into three parts: generating sufficient entropy for security, generating a sufficient quantity and quality random numbers for the applications, and actually bringing the random data where it's needed. The first problem is solvable, the second is solved, the third one is where the difficulty is.



    To generate random numbers, it's necessary to have a source of non-determinism. A deterministic computer, by definition, is incapable of producing anything random. But there is no need for any expensive machine using quantum mechanics. Classical mechanics or cheap applications of quantum mechanics are good enough in practice. Your PC has a random number generator, if it isn't an antique. Your phone probably has one too, if it's a not-too-old smartphone. If your credit card has a chip, it has a hardware random generator. You can find microcontrollers that cost a few cents (I'm talking bulk prices here) that have a built-in RNG. Many devices lack one (your home router might not have one), but at current prices it's a supply chain and requirements problem, not a cost problem. If you can control how a device is designed, there's no excuse not to include a hardwarre random generator.



    A hardware random generator gives you entropy, but it isn't directly usable for cryptography. It usually has limited bandwidth and biases (no measurement apparatus is perfect). Fortunately, turning an entropy source into a cryptography-grade random generator is a solved problem. All you need to do is to use the entropy source to seed a pseudorandom generator. Any cryptography library has one or more PRNG available.



    The real problem with random numbers in practice is getting all the software out there to use them correctly. This is a difficult problem to solve because every piece of software needs to get things right: properly relay the data, don't leave a copy lying around. The operating system driver needs to get it right, the system installer needs to get it right, all the layers of software libraries need to get it right, and the application needs to use the libraries properly. Proper use of randomness is near-impossible to test, so bugs are difficult to detect. Common problems include developers using non-cryptographic random generators when they need cryptographic ones (don't use rand anywhere near cryptographic code!), using a cryptographic PRNG that is not seeded properly (always use your OS's randomness source such as /dev/urandom or CryptGenRandom), using non-random inputs to functions where random input was needed, and systems where the entropy source is not configured properly.



    So when the article says




    Eventually, it would be great if they shrank the setup to fit on a chip, says Bierhorst: a random number generator in every laptop, so that nobody ever uses those algorithm-based numbers for encryption again.




    that's attacking the part of the problem that doesn't need new technology. The reason people use “algorithm-based numbers for encryption” is that either their device lacks a generator which can be built cheaply using current technology, or that there's a problem in the software. This new machine would not help with either part of the problem.



    As for the proposed application of a “randomness beacon”, it's a plausible one, but it's of limited use and difficult to put to practice. A randomness beacon, as the article explains, is useless for most cryptographic applications since it wouldn't be secret. It's useful as an impartial arbiter, for example to assign auditors to auditees, but that can be done with any source of randomness. The fact that the machine itself is more difficult to “hack” than a PC with RDRAND is not all that useful, because the hacking could be done in the reporting and logging system.






    share|improve this answer












    The title of this article is complete hype. Tip: when a journalist says “X could solve Y”, read “X probably won't solve Y”. Much of the content of the article is hype too.



    Cryptography has a random number problem, but the problem is not producing random number, and the proposal in this article wouldn't be useful to produce random number anyway.



    Cryptography does need random numbers for many things. The problem of obtaining random numbers can be divided into three parts: generating sufficient entropy for security, generating a sufficient quantity and quality random numbers for the applications, and actually bringing the random data where it's needed. The first problem is solvable, the second is solved, the third one is where the difficulty is.



    To generate random numbers, it's necessary to have a source of non-determinism. A deterministic computer, by definition, is incapable of producing anything random. But there is no need for any expensive machine using quantum mechanics. Classical mechanics or cheap applications of quantum mechanics are good enough in practice. Your PC has a random number generator, if it isn't an antique. Your phone probably has one too, if it's a not-too-old smartphone. If your credit card has a chip, it has a hardware random generator. You can find microcontrollers that cost a few cents (I'm talking bulk prices here) that have a built-in RNG. Many devices lack one (your home router might not have one), but at current prices it's a supply chain and requirements problem, not a cost problem. If you can control how a device is designed, there's no excuse not to include a hardwarre random generator.



    A hardware random generator gives you entropy, but it isn't directly usable for cryptography. It usually has limited bandwidth and biases (no measurement apparatus is perfect). Fortunately, turning an entropy source into a cryptography-grade random generator is a solved problem. All you need to do is to use the entropy source to seed a pseudorandom generator. Any cryptography library has one or more PRNG available.



    The real problem with random numbers in practice is getting all the software out there to use them correctly. This is a difficult problem to solve because every piece of software needs to get things right: properly relay the data, don't leave a copy lying around. The operating system driver needs to get it right, the system installer needs to get it right, all the layers of software libraries need to get it right, and the application needs to use the libraries properly. Proper use of randomness is near-impossible to test, so bugs are difficult to detect. Common problems include developers using non-cryptographic random generators when they need cryptographic ones (don't use rand anywhere near cryptographic code!), using a cryptographic PRNG that is not seeded properly (always use your OS's randomness source such as /dev/urandom or CryptGenRandom), using non-random inputs to functions where random input was needed, and systems where the entropy source is not configured properly.



    So when the article says




    Eventually, it would be great if they shrank the setup to fit on a chip, says Bierhorst: a random number generator in every laptop, so that nobody ever uses those algorithm-based numbers for encryption again.




    that's attacking the part of the problem that doesn't need new technology. The reason people use “algorithm-based numbers for encryption” is that either their device lacks a generator which can be built cheaply using current technology, or that there's a problem in the software. This new machine would not help with either part of the problem.



    As for the proposed application of a “randomness beacon”, it's a plausible one, but it's of limited use and difficult to put to practice. A randomness beacon, as the article explains, is useless for most cryptographic applications since it wouldn't be secret. It's useful as an impartial arbiter, for example to assign auditors to auditees, but that can be done with any source of randomness. The fact that the machine itself is more difficult to “hack” than a PC with RDRAND is not all that useful, because the hacking could be done in the reporting and logging system.







    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered 7 hours ago









    Gilles

    7,60732653




    7,60732653








    • 1




      An additional major problem with hardware random number generators is that they are often very difficult to audit, a hardware source of entropy followed by a hardware whitener (Intel I3/5/7 for example) is indistinguishable from say AES128 in CTR mode unless you know the key to that AES implementation. Because of this you can never be sure that that nice hardware is actually giving you random and not something that collapses if you are the agency that created the key. In this respect a hash of a frame from a webcam or the low bit of the audio sample is probably at least easier to audit.
      – Dan Mills
      3 hours ago










    • @DanMills You can't audit an RNG as a black box. The right way to design an RNG is to give software access to the unwhitened source, and to give auditors full access to both the hardware design and the software design (and manufacturing!). You also need to give the software access to the unwhitened source so that it can detect telltale patterns of bad environment conditions that cause the source to have less entropy than it should.
      – Gilles
      2 hours ago






    • 1




      Yep, which is exactly what Intel didn't do! The point about manufacturing is also very much on point, easy to diddle a metal layer so that your noise diode is short circuited.... the unwhitened source is what the low bit of a 24 bit microphone ADC or ADC connected to a warm resistor is, and at least in the resistor case that is a quantum source (Boltzmann noise). The trap there of course is that small signal analogue is easy to interfere with and computers have lots of things that might couple enough to correlate if the design is not spot on.
      – Dan Mills
      2 hours ago










    • @DanMills Do you know of dopant-level hardware trojans? See §3.2 especially. Uber sneaky.
      – Paul Uszak
      2 hours ago










    • @PaulUszak Yep, sneaky indeed, not the easiest thing to pull off, but kind of tough to spot if you manage it. I doubt that just sneaking a diddled bottle of arsine into TMSC would get it done.
      – Dan Mills
      1 hour ago














    • 1




      An additional major problem with hardware random number generators is that they are often very difficult to audit, a hardware source of entropy followed by a hardware whitener (Intel I3/5/7 for example) is indistinguishable from say AES128 in CTR mode unless you know the key to that AES implementation. Because of this you can never be sure that that nice hardware is actually giving you random and not something that collapses if you are the agency that created the key. In this respect a hash of a frame from a webcam or the low bit of the audio sample is probably at least easier to audit.
      – Dan Mills
      3 hours ago










    • @DanMills You can't audit an RNG as a black box. The right way to design an RNG is to give software access to the unwhitened source, and to give auditors full access to both the hardware design and the software design (and manufacturing!). You also need to give the software access to the unwhitened source so that it can detect telltale patterns of bad environment conditions that cause the source to have less entropy than it should.
      – Gilles
      2 hours ago






    • 1




      Yep, which is exactly what Intel didn't do! The point about manufacturing is also very much on point, easy to diddle a metal layer so that your noise diode is short circuited.... the unwhitened source is what the low bit of a 24 bit microphone ADC or ADC connected to a warm resistor is, and at least in the resistor case that is a quantum source (Boltzmann noise). The trap there of course is that small signal analogue is easy to interfere with and computers have lots of things that might couple enough to correlate if the design is not spot on.
      – Dan Mills
      2 hours ago










    • @DanMills Do you know of dopant-level hardware trojans? See §3.2 especially. Uber sneaky.
      – Paul Uszak
      2 hours ago










    • @PaulUszak Yep, sneaky indeed, not the easiest thing to pull off, but kind of tough to spot if you manage it. I doubt that just sneaking a diddled bottle of arsine into TMSC would get it done.
      – Dan Mills
      1 hour ago








    1




    1




    An additional major problem with hardware random number generators is that they are often very difficult to audit, a hardware source of entropy followed by a hardware whitener (Intel I3/5/7 for example) is indistinguishable from say AES128 in CTR mode unless you know the key to that AES implementation. Because of this you can never be sure that that nice hardware is actually giving you random and not something that collapses if you are the agency that created the key. In this respect a hash of a frame from a webcam or the low bit of the audio sample is probably at least easier to audit.
    – Dan Mills
    3 hours ago




    An additional major problem with hardware random number generators is that they are often very difficult to audit, a hardware source of entropy followed by a hardware whitener (Intel I3/5/7 for example) is indistinguishable from say AES128 in CTR mode unless you know the key to that AES implementation. Because of this you can never be sure that that nice hardware is actually giving you random and not something that collapses if you are the agency that created the key. In this respect a hash of a frame from a webcam or the low bit of the audio sample is probably at least easier to audit.
    – Dan Mills
    3 hours ago












    @DanMills You can't audit an RNG as a black box. The right way to design an RNG is to give software access to the unwhitened source, and to give auditors full access to both the hardware design and the software design (and manufacturing!). You also need to give the software access to the unwhitened source so that it can detect telltale patterns of bad environment conditions that cause the source to have less entropy than it should.
    – Gilles
    2 hours ago




    @DanMills You can't audit an RNG as a black box. The right way to design an RNG is to give software access to the unwhitened source, and to give auditors full access to both the hardware design and the software design (and manufacturing!). You also need to give the software access to the unwhitened source so that it can detect telltale patterns of bad environment conditions that cause the source to have less entropy than it should.
    – Gilles
    2 hours ago




    1




    1




    Yep, which is exactly what Intel didn't do! The point about manufacturing is also very much on point, easy to diddle a metal layer so that your noise diode is short circuited.... the unwhitened source is what the low bit of a 24 bit microphone ADC or ADC connected to a warm resistor is, and at least in the resistor case that is a quantum source (Boltzmann noise). The trap there of course is that small signal analogue is easy to interfere with and computers have lots of things that might couple enough to correlate if the design is not spot on.
    – Dan Mills
    2 hours ago




    Yep, which is exactly what Intel didn't do! The point about manufacturing is also very much on point, easy to diddle a metal layer so that your noise diode is short circuited.... the unwhitened source is what the low bit of a 24 bit microphone ADC or ADC connected to a warm resistor is, and at least in the resistor case that is a quantum source (Boltzmann noise). The trap there of course is that small signal analogue is easy to interfere with and computers have lots of things that might couple enough to correlate if the design is not spot on.
    – Dan Mills
    2 hours ago












    @DanMills Do you know of dopant-level hardware trojans? See §3.2 especially. Uber sneaky.
    – Paul Uszak
    2 hours ago




    @DanMills Do you know of dopant-level hardware trojans? See §3.2 especially. Uber sneaky.
    – Paul Uszak
    2 hours ago












    @PaulUszak Yep, sneaky indeed, not the easiest thing to pull off, but kind of tough to spot if you manage it. I doubt that just sneaking a diddled bottle of arsine into TMSC would get it done.
    – Dan Mills
    1 hour ago




    @PaulUszak Yep, sneaky indeed, not the easiest thing to pull off, but kind of tough to spot if you manage it. I doubt that just sneaking a diddled bottle of arsine into TMSC would get it done.
    – Dan Mills
    1 hour ago










    up vote
    0
    down vote













    There isn't really too much of a problem. Uncharacteristically, Wired has produced quite a bad article for a piece of technology. Sophie has focused on the number generation rate, not realising that the machine is not primarily a random number generator. Journalistic licence?



    The official paper for the machine and experiment is here. It was built to test the Bell Inequality, and to disprove local realism that might have underpinned quantum mechanics. The size of the machine is necessary to ensure that the pairs of measurements are made outside of their respective light cones. That's the reason for the device's two ~130m legs.The random numbers popping out are just the experimental byproduct put to use via the randomness beacon.



    The experiment was successful and local realism has been disproved, thereby supporting Spooky Action paradigms. Spooky indeed.



    The other answer clearly demonstrates that small alternative true random number generators already successfully exist.






    share|improve this answer

























      up vote
      0
      down vote













      There isn't really too much of a problem. Uncharacteristically, Wired has produced quite a bad article for a piece of technology. Sophie has focused on the number generation rate, not realising that the machine is not primarily a random number generator. Journalistic licence?



      The official paper for the machine and experiment is here. It was built to test the Bell Inequality, and to disprove local realism that might have underpinned quantum mechanics. The size of the machine is necessary to ensure that the pairs of measurements are made outside of their respective light cones. That's the reason for the device's two ~130m legs.The random numbers popping out are just the experimental byproduct put to use via the randomness beacon.



      The experiment was successful and local realism has been disproved, thereby supporting Spooky Action paradigms. Spooky indeed.



      The other answer clearly demonstrates that small alternative true random number generators already successfully exist.






      share|improve this answer























        up vote
        0
        down vote










        up vote
        0
        down vote









        There isn't really too much of a problem. Uncharacteristically, Wired has produced quite a bad article for a piece of technology. Sophie has focused on the number generation rate, not realising that the machine is not primarily a random number generator. Journalistic licence?



        The official paper for the machine and experiment is here. It was built to test the Bell Inequality, and to disprove local realism that might have underpinned quantum mechanics. The size of the machine is necessary to ensure that the pairs of measurements are made outside of their respective light cones. That's the reason for the device's two ~130m legs.The random numbers popping out are just the experimental byproduct put to use via the randomness beacon.



        The experiment was successful and local realism has been disproved, thereby supporting Spooky Action paradigms. Spooky indeed.



        The other answer clearly demonstrates that small alternative true random number generators already successfully exist.






        share|improve this answer












        There isn't really too much of a problem. Uncharacteristically, Wired has produced quite a bad article for a piece of technology. Sophie has focused on the number generation rate, not realising that the machine is not primarily a random number generator. Journalistic licence?



        The official paper for the machine and experiment is here. It was built to test the Bell Inequality, and to disprove local realism that might have underpinned quantum mechanics. The size of the machine is necessary to ensure that the pairs of measurements are made outside of their respective light cones. That's the reason for the device's two ~130m legs.The random numbers popping out are just the experimental byproduct put to use via the randomness beacon.



        The experiment was successful and local realism has been disproved, thereby supporting Spooky Action paradigms. Spooky indeed.



        The other answer clearly demonstrates that small alternative true random number generators already successfully exist.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered 2 hours ago









        Paul Uszak

        6,86811534




        6,86811534






















            user50486 is a new contributor. Be nice, and check out our Code of Conduct.










            draft saved

            draft discarded


















            user50486 is a new contributor. Be nice, and check out our Code of Conduct.













            user50486 is a new contributor. Be nice, and check out our Code of Conduct.












            user50486 is a new contributor. Be nice, and check out our Code of Conduct.
















            Thanks for contributing an answer to Cryptography Stack Exchange!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            Use MathJax to format equations. MathJax reference.


            To learn more, see our tips on writing great answers.





            Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


            Please pay close attention to the following guidance:


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcrypto.stackexchange.com%2fquestions%2f64810%2fcryptographys-random-number-problem%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            What visual should I use to simply compare current year value vs last year in Power BI desktop

            How to ignore python UserWarning in pytest?

            Alexandru Averescu