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?
random-number-generator randomness
New contributor
add a comment |
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?
random-number-generator randomness
New contributor
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
add a comment |
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?
random-number-generator randomness
New contributor
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
random-number-generator randomness
New contributor
New contributor
edited 11 mins ago
Ella Rose
14.7k44077
14.7k44077
New contributor
asked 10 hours ago
user50486
161
161
New contributor
New contributor
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
add a comment |
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
add a comment |
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.
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
add a comment |
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.
add a comment |
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.
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
add a comment |
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.
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
add a comment |
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.
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.
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
add a comment |
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
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
answered 2 hours ago
Paul Uszak
6,86811534
6,86811534
add a comment |
add a comment |
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.
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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