As long as we encrypt-then-MAC -- as recommended by the answers to Should we MAC-then-encrypt or encrypt-then-MAC?Should we MAC-then-encrypt or encrypt-then-MAC? -- the ciphertext still has perfect secrecy: the ciphertext could potentially decode to any conceivable plaintext, and even with the help of the MAC it's not possible to rule out any conceivable plaintext of the same length.
replaced http://crypto.stackexchange.com/ with https://crypto.stackexchange.com/
As long as we encrypt-then-MAC -- as recommended by the answers to Should we MAC-then-encrypt or encrypt-then-MAC? -- the ciphertext still has perfect secrecy: the ciphertext could potentially decode to any conceivable plaintext, and even with the help of the MAC it's not possible to rule out any conceivable plaintext of the same length.
As long as we encrypt-then-MAC -- as recommended by the answers to Should we MAC-then-encrypt or encrypt-then-MAC? -- the ciphertext still has perfect secrecy: the ciphertext could potentially decode to any conceivable plaintext, and even with the help of the MAC it's not possible to rule out any conceivable plaintext of the same length.
sufficient randomness
The Whirlygig RNG -- and some other similar low-cost hardware random number generators low-cost hardware random number generatorsa b -- have published schematics.
Yes, such a hardware random-number generator gives more than sufficient randomness to produce one-time pads. It seems quite possible that this Simtec "Entropy Key" works just as well, although it's hard to say without looking at its schematic.
In such systems, typically the raw data samples produced internally are slightly biased, but the system uses a "whitening" algorithm (aka "randomness extractor" aka "decorrelator") that takes large blocks of such slightly-biased bits and produces small blocks of completely uncorrelated bits ("high quality randomness").
The Whirlygig RNG produces over 500 KBytes/s of high quality randomness. While pseudo-random number generators running on commodity desktop machines run many times faster, I find it hard to imagine any application for high-quality random numbers where 500 KBytes/s is "too slow".
With a properly implemented randomness extractor, as long as the HRNG is in a physically secure room, most conceivable "attacks" (through-the-air electromagnetic interference, through-the-power-lines electromagnetic interference, etc.) at worst merely slow down the rate at which high-quality random bits are produced; they don't reduce the quality of whatever bits are produced. (The randomness extractor automatically compensates for any reduced quality of the internal raw data samples, throwing out "suspicious" samples).
message authentication
As Thomas pointed out, a MAC on top of the OTP is a good idea.
As long as we encrypt-then-MAC -- as recommended by the answers to Should we MAC-then-encrypt or encrypt-then-MAC? -- the ciphertext still has perfect secrecy: the ciphertext could potentially decode to any conceivable plaintext, and even with the help of the MAC it's not possible to rule out any conceivable plaintext of the same length.
Quick proof:
Say Eve obtains a block of ciphertext C produced by Alice using the one-time-pad algorithm. If Eve doesn't know the OTP block R that was used to produce it, ciphertext C could have been produced by any conceivable plaintext -- perhaps message P1 combined with R1 == P1 xor C; or perhaps message P2 combined with R2 == P2 xor C; or etc.
Say Eve then obtains the MAC tag that Alice generated from that ciphertext and Alice's MAC secret key using the encrypt-then-MAC system.
With any of these potential messages P1, P2, etc., since the ciphertext C is the same, and the MAC secret key is the same, the MAC algorithm would generate identically the same MAC tag in all cases, and so the MAC tag is useless to Eve for discriminating which particular message Alice is trying to send. Even if Eve somehow obtained the MAC secret key (which would be bad for Alice in other ways), Eve still wouldn't be able to narrow down which plaintext message Alice is trying to send without more information.
XORing
would XORing the output bits with the plaintext be enough?
Yes, for the easy part of the OTP -- encryption -- XORing the plaintext bits with the high-quality random bits is all that's needed.
The more difficult parts of implementing OTP still remain: Somehow transporting the high-quality random bits so both Alice and Bob, but no one else, has a copy of the OTP key. Somehow securely erasing each block of the key immediately after it is used for the one and only time each block is used. Etc.
sufficient randomness
The Whirlygig RNG -- and some other similar low-cost hardware random number generators -- have published schematics.
Yes, such a hardware random-number generator gives more than sufficient randomness to produce one-time pads. It seems quite possible that this Simtec "Entropy Key" works just as well, although it's hard to say without looking at its schematic.
In such systems, typically the raw data samples produced internally are slightly biased, but the system uses a "whitening" algorithm (aka "randomness extractor" aka "decorrelator") that takes large blocks of such slightly-biased bits and produces small blocks of completely uncorrelated bits ("high quality randomness").
The Whirlygig RNG produces over 500 KBytes/s of high quality randomness. While pseudo-random number generators running on commodity desktop machines run many times faster, I find it hard to imagine any application for high-quality random numbers where 500 KBytes/s is "too slow".
With a properly implemented randomness extractor, as long as the HRNG is in a physically secure room, most conceivable "attacks" (through-the-air electromagnetic interference, through-the-power-lines electromagnetic interference, etc.) at worst merely slow down the rate at which high-quality random bits are produced; they don't reduce the quality of whatever bits are produced. (The randomness extractor automatically compensates for any reduced quality of the internal raw data samples, throwing out "suspicious" samples).
message authentication
As Thomas pointed out, a MAC on top of the OTP is a good idea.
As long as we encrypt-then-MAC -- as recommended by the answers to Should we MAC-then-encrypt or encrypt-then-MAC? -- the ciphertext still has perfect secrecy: the ciphertext could potentially decode to any conceivable plaintext, and even with the help of the MAC it's not possible to rule out any conceivable plaintext of the same length.
Quick proof:
Say Eve obtains a block of ciphertext C produced by Alice using the one-time-pad algorithm. If Eve doesn't know the OTP block R that was used to produce it, ciphertext C could have been produced by any conceivable plaintext -- perhaps message P1 combined with R1 == P1 xor C; or perhaps message P2 combined with R2 == P2 xor C; or etc.
Say Eve then obtains the MAC tag that Alice generated from that ciphertext and Alice's MAC secret key using the encrypt-then-MAC system.
With any of these potential messages P1, P2, etc., since the ciphertext C is the same, and the MAC secret key is the same, the MAC algorithm would generate identically the same MAC tag in all cases, and so the MAC tag is useless to Eve for discriminating which particular message Alice is trying to send. Even if Eve somehow obtained the MAC secret key (which would be bad for Alice in other ways), Eve still wouldn't be able to narrow down which plaintext message Alice is trying to send without more information.
XORing
would XORing the output bits with the plaintext be enough?
Yes, for the easy part of the OTP -- encryption -- XORing the plaintext bits with the high-quality random bits is all that's needed.
The more difficult parts of implementing OTP still remain: Somehow transporting the high-quality random bits so both Alice and Bob, but no one else, has a copy of the OTP key. Somehow securely erasing each block of the key immediately after it is used for the one and only time each block is used. Etc.
sufficient randomness
The Whirlygig RNG -- and some other similar low-cost hardware random number generators a b -- have published schematics.
Yes, such a hardware random-number generator gives more than sufficient randomness to produce one-time pads. It seems quite possible that this Simtec "Entropy Key" works just as well, although it's hard to say without looking at its schematic.
In such systems, typically the raw data samples produced internally are slightly biased, but the system uses a "whitening" algorithm (aka "randomness extractor" aka "decorrelator") that takes large blocks of such slightly-biased bits and produces small blocks of completely uncorrelated bits ("high quality randomness").
The Whirlygig RNG produces over 500 KBytes/s of high quality randomness. While pseudo-random number generators running on commodity desktop machines run many times faster, I find it hard to imagine any application for high-quality random numbers where 500 KBytes/s is "too slow".
With a properly implemented randomness extractor, as long as the HRNG is in a physically secure room, most conceivable "attacks" (through-the-air electromagnetic interference, through-the-power-lines electromagnetic interference, etc.) at worst merely slow down the rate at which high-quality random bits are produced; they don't reduce the quality of whatever bits are produced. (The randomness extractor automatically compensates for any reduced quality of the internal raw data samples, throwing out "suspicious" samples).
message authentication
As Thomas pointed out, a MAC on top of the OTP is a good idea.
As long as we encrypt-then-MAC -- as recommended by the answers to Should we MAC-then-encrypt or encrypt-then-MAC? -- the ciphertext still has perfect secrecy: the ciphertext could potentially decode to any conceivable plaintext, and even with the help of the MAC it's not possible to rule out any conceivable plaintext of the same length.
Quick proof:
Say Eve obtains a block of ciphertext C produced by Alice using the one-time-pad algorithm. If Eve doesn't know the OTP block R that was used to produce it, ciphertext C could have been produced by any conceivable plaintext -- perhaps message P1 combined with R1 == P1 xor C; or perhaps message P2 combined with R2 == P2 xor C; or etc.
Say Eve then obtains the MAC tag that Alice generated from that ciphertext and Alice's MAC secret key using the encrypt-then-MAC system.
With any of these potential messages P1, P2, etc., since the ciphertext C is the same, and the MAC secret key is the same, the MAC algorithm would generate identically the same MAC tag in all cases, and so the MAC tag is useless to Eve for discriminating which particular message Alice is trying to send. Even if Eve somehow obtained the MAC secret key (which would be bad for Alice in other ways), Eve still wouldn't be able to narrow down which plaintext message Alice is trying to send without more information.
XORing
would XORing the output bits with the plaintext be enough?
Yes, for the easy part of the OTP -- encryption -- XORing the plaintext bits with the high-quality random bits is all that's needed.
The more difficult parts of implementing OTP still remain: Somehow transporting the high-quality random bits so both Alice and Bob, but no one else, has a copy of the OTP key. Somehow securely erasing each block of the key immediately after it is used for the one and only time each block is used. Etc.
sufficient randomness
The Whirlygig RNG -- and some other similar low-cost hardware random number generators -- have published schematics.
Yes, such a hardware random-number generator gives more than sufficient randomness to produce one-time pads. It seems quite possible that this Simtec "Entropy Key" works just as well, although it's hard to say without looking at its schematic.
In such systems, typically the raw data samples produced internally are slightly biased, but the system uses a "whitening" algorithm (aka "randomness extractor" aka "decorrelator") that takes large blocks of such slightly-biased bits and produces small blocks of completely uncorrelated bits ("high quality randomness").
The Whirlygig RNG produces over 500 KBytes/s of high quality randomness. While pseudo-random number generators running on commodity desktop machines run many times faster, I find it hard to imagine any application for high-quality random numbers where 500 KBytes/s is "too slow".
With a properly implemented randomness extractor, as long as the HRNG is in a physically secure room, most conceivable "attacks" (through-the-air electromagnetic interference, through-the-power-lines electromagnetic interference, etc.) at worst merely slow down the rate at which high-quality random bits are produced; they don't reduce the quality of whatever bits are produced. (The randomness extractor automatically compensates for any reduced quality of the internal raw data samples, throwing out "suspicious" samples).
message authentication
As Thomas pointed out, a MAC on top of the OTP is a good idea.
As long as we encrypt-then-MAC -- as recommended by the answers to Should we MAC-then-encrypt or encrypt-then-MAC? -- the ciphertext still has perfect secrecy: the ciphertext could potentially decode to any conceivable plaintext, and even with the help of the MAC it's not possible to rule out any conceivable plaintext of the same length.
Quick proof:
Say Eve obtains a block of ciphertext C produced by Alice using the one-time-pad algorithm. If Eve doesn't know the OTP block R that was used to produce it, ciphertext C could have been produced by any conceivable plaintext -- perhaps message P1 combined with R1 == P1 xor C; or perhaps message P2 combined with R2 == P2 xor C; or etc.
Say Eve then obtains the MAC tag that Alice generated from that ciphertext and Alice's MAC secret key using the encrypt-then-MAC system.
With any of these potential messages P1, P2, etc., since the ciphertext C is the same, and the MAC secret key is the same, the MAC algorithm would generate identically the same MAC tag in all cases, and so the MAC tag is useless to Eve for discriminating which particular message Alice is trying to send. Even if Eve somehow obtained the MAC secret key (which would be bad for Alice in other ways), Eve still wouldn't be able to narrow down which plaintext message Alice is trying to send without more information.
XORing
would XORing the output bits with the plaintext be enough?
Yes, for the easy part of the OTP -- encryption -- XORing the plaintext bits with the high-quality random bits is all that's needed.
The more difficult parts of implementing OTP still remain: Somehow transporting the high-quality random bits so both Alice and Bob, but no one else, has a copy of the OTP key. Somehow securely erasing each block of the key immediately after it is used for the one and only time each block is used. Etc.