Mixing
Is a PRG more costly than AES or any other encryption standard?
Clash Royale CLAN TAG#URR8PPP
up vote
2
down vote
favorite
I know that there are many encryption standards that take a key and sometimes an IV, and produces a cipher-text (the most prominent one is AES). These standards usually involve many rounds of addition and multiplication. However, using a OTP is much easier than this. You XOR the plaintext with your pad, this is the only requirement computation-wise. However, OTP comes with the problem of a key-stream as long as the plaintext. This key-stream is supposed to be random. My question is, is this randomness more costly than the encryption standards that are in use? Why don't we use OTP in every case, what is the downside?
Let's say I cannot afford to use encryption algorithms, but I have a stream of data that is nearly-random. If I use this as an OTP (I know this is not perfectly random), what do I sacrifice in return? What can be done to obtain the best pseudo-random characteristics from this arbitrary stream of data, to make it as qualified as it can get to be an OTP?
encryption keys one-time-pad
asked 2 hours ago
Ninja Bug
191
add a comment |Â
up vote
2
down vote
favorite
I know that there are many encryption standards that take a key and sometimes an IV, and produces a cipher-text (the most prominent one is AES). These standards usually involve many rounds of addition and multiplication. However, using a OTP is much easier than this. You XOR the plaintext with your pad, this is the only requirement computation-wise. However, OTP comes with the problem of a key-stream as long as the plaintext. This key-stream is supposed to be random. My question is, is this randomness more costly than the encryption standards that are in use? Why don't we use OTP in every case, what is the downside?
Let's say I cannot afford to use encryption algorithms, but I have a stream of data that is nearly-random. If I use this as an OTP (I know this is not perfectly random), what do I sacrifice in return? What can be done to obtain the best pseudo-random characteristics from this arbitrary stream of data, to make it as qualified as it can get to be an OTP?
encryption keys one-time-pad
asked 2 hours ago
Ninja Bug
191
add a comment |Â
up vote
2
down vote
favorite
up vote
2
down vote
favorite
I know that there are many encryption standards that take a key and sometimes an IV, and produces a cipher-text (the most prominent one is AES). These standards usually involve many rounds of addition and multiplication. However, using a OTP is much easier than this. You XOR the plaintext with your pad, this is the only requirement computation-wise. However, OTP comes with the problem of a key-stream as long as the plaintext. This key-stream is supposed to be random. My question is, is this randomness more costly than the encryption standards that are in use? Why don't we use OTP in every case, what is the downside?
Let's say I cannot afford to use encryption algorithms, but I have a stream of data that is nearly-random. If I use this as an OTP (I know this is not perfectly random), what do I sacrifice in return? What can be done to obtain the best pseudo-random characteristics from this arbitrary stream of data, to make it as qualified as it can get to be an OTP?
encryption keys one-time-pad
asked 2 hours ago
Ninja Bug
191
I know that there are many encryption standards that take a key and sometimes an IV, and produces a cipher-text (the most prominent one is AES). These standards usually involve many rounds of addition and multiplication. However, using a OTP is much easier than this. You XOR the plaintext with your pad, this is the only requirement computation-wise. However, OTP comes with the problem of a key-stream as long as the plaintext. This key-stream is supposed to be random. My question is, is this randomness more costly than the encryption standards that are in use? Why don't we use OTP in every case, what is the downside?
Let's say I cannot afford to use encryption algorithms, but I have a stream of data that is nearly-random. If I use this as an OTP (I know this is not perfectly random), what do I sacrifice in return? What can be done to obtain the best pseudo-random characteristics from this arbitrary stream of data, to make it as qualified as it can get to be an OTP?
encryption keys one-time-pad
encryption keys one-time-pad
asked 2 hours ago
Ninja Bug
191
asked 2 hours ago
Ninja Bug
191
asked 2 hours ago
Ninja Bug
191
asked 2 hours ago
Ninja Bug
191
asked 2 hours ago
Ninja Bug
191
191
add a comment |Â
add a comment |Â
4 Answers
4
active
oldest
votes
up vote
1
down vote
Distilling your question down to these two salient points:-
Why don't we use OTP in every case, what is the downside?
which leads directly to Why wouldn't everyone encrypt with a One Time Pad? and I won't add to the confusion, but that question might provide some insight.
I have a stream of data that is nearly-random
Then use it seed a CSPRNG as Why in one time pad must the key distribution to be truly random and Why does the key for a one-time pad have to be uniformly distributed? show why you shouldn't use it raw. If your system has the capacity to store a large one time pad, it probably has enough computing power to run some form of CSPRNG. There are ChaCha derived implementations that will run as low as Arduino level. Just make sure that your original entropy is sufficient, typically 128 bits or more. That might require some compression /folding of the raw data to suite the seed size of the CSPRNG you should be using.
In many respects, this is the hardest part facing you as accurate entropy measurement of data is tricky. You clearly want to avoid the situation where a 1kbit stream of data only has a few bits of entropy as it's generated purely arithmetically.
answered 1 hour ago
Paul Uszak
6,19411332
add a comment |Â
up vote
1
down vote
Let's say I cannot afford to use encryption algorithms, but I have a stream of data that is nearly-random. [...]
I think one problem you're having is that you're treating this as a reasonable assumption: that cryptographic algorithms are somehow costlier than random bit generation. But it's the other way around—OTP is the costlier alternative.
One useful way to think about modern cryptography is this: the point of cryptography is to reduce our requirements for pre-cryptographic secure channels. All cryptography, from OTP to DH, needs to make some use of some such channel to work:
- OTP requires that the parties share at least as much random key material as the amount of data they plan to encrypt. This key material must be exchanged over a channel that's confidential and guarantees message authenticity.
- Modern symmetric encryption requires the parties to share a small random secret key. This key must also be exchanged over a channel that's confidential and guarantees message authenticity.
- Public-key encryption requires one of the parties to know the other's public key. This key must be obtained over a channel that guarantees message authenticity, but doesn't have to be confidential.
So looking at it from this angle, OTP is the costliest by far. Every bit that you encrypt with an OTP must be "paid for" by sending a pad bit over a costlier key establishment channel that you cannot protect cryptographically. If you think about it you can see that this volume limit also implies an average bandwidth limit—measured over long time periods, your encrypted message bandwidth cannot exceed the key establishment channel's bandwidth. If I can only establish 1 GiB of pad material per week, then that's how much data I can encrypt on average as well.
In comparison, with modern symmetric encryption a 128-bit AES key is sufficient to encrypt vast volumes of data. My key establishment channel can have a bandwidth vastly smaller than my encrypted communications.
answered 28 mins ago
Luis Casillas
9,13211135
add a comment |Â
up vote
0
down vote
If I use this as an OTP (I know this is not perfectly random), what do I sacrifice in return?
Why don't we use OTP in every case, what is the downside?
The problem with OPT is key distribution. If you have a secure channel to transmit the key, then instead of the key, transmit the message.
OPT is used between embassies and the governments. The embassies can return the Capitol and take a suitcase to carry the OPT with them. There the problem is when the OTP key is finished will you stop communicating or start to reuse?
It is used since it has perfect secrecy.
I have a stream of data that is nearly-random. If I use this as an OTP (I know this is not perfectly random), what do I sacrifice in return?
The answer depends on the definition of your nearly random. If it is an LFSR, I can try all possible LFSR outputs up to some length.
Is a PRG more costly than AES or any other encryption standard?
Compare the cost of carrying securely the OPT or using Public Key Encryption to Key exchange for Symmetric key encryption.
answered 2 hours ago
kelalaka
1,133217
add a comment |Â
up vote
0
down vote
A one-time pad requires a true random sequence that is as long as the material you want to encrypt. If you have a pseudo-random sequence, then you don't have a one-time pad: you have a stream cipher. If you have a stream of data that is only “nearly randomâ€Â, then you don't have a one-time pad, you have a broken stream cipher.
Concretely, if the nearly-random sequence isn't uniform, it means that there are biases: certain arrangements of bits are more likely than certain others. Whenever these arrangements are aligned with a pattern in the plaintext — for example English text contains more E than J, text in most languages contains more spaces than any other character, HTML tends to have a > shortly after each <, … — the pattern in the plaintext becomes apparent in the ciphertext. So certain patterns appear in the ciphertext more often than chance, they will reveal patterns in the plaintext.
To generate a cryptographically secure random sequence from a source of randomness that isn't perfectly uniform, you need to pass this random source through a cryptographically secure pseudorandom generator. One of the cheapest techniques to build a pseudorandom generator is to use an encryption algorithm such as AES in a construction known as CTR_DRBG. If all you want to do is to encrypt one message, then it's simpler and cheaper to encrypt the message with AES-CTR than do use AES-CTR_DRBG to build a key stream and to use that key stream to encrypt a message.
In addition, a one-time pad doesn't help with the authenticity of the message. If the message is modified in transit, there's no way to detect it. Encryption algorithms can be combined with authentication algorithm, and the cost of doing the two together is less than the cost of doing the two completely independently. The computational cost is only slightly less, but the cost in code size or in gate count is significantly less. For example, once you have the AES block cipher, it only takes a little additional work to build an authenticated encryption mode such as GCM or CCM.
answered 12 mins ago
Gilles
7,04732548
add a comment |Â
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
Distilling your question down to these two salient points:-
Why don't we use OTP in every case, what is the downside?
which leads directly to Why wouldn't everyone encrypt with a One Time Pad? and I won't add to the confusion, but that question might provide some insight.
I have a stream of data that is nearly-random
Then use it seed a CSPRNG as Why in one time pad must the key distribution to be truly random and Why does the key for a one-time pad have to be uniformly distributed? show why you shouldn't use it raw. If your system has the capacity to store a large one time pad, it probably has enough computing power to run some form of CSPRNG. There are ChaCha derived implementations that will run as low as Arduino level. Just make sure that your original entropy is sufficient, typically 128 bits or more. That might require some compression /folding of the raw data to suite the seed size of the CSPRNG you should be using.
In many respects, this is the hardest part facing you as accurate entropy measurement of data is tricky. You clearly want to avoid the situation where a 1kbit stream of data only has a few bits of entropy as it's generated purely arithmetically.
answered 1 hour ago
Paul Uszak
6,19411332
add a comment |Â
up vote
1
down vote
Distilling your question down to these two salient points:-
Why don't we use OTP in every case, what is the downside?
which leads directly to Why wouldn't everyone encrypt with a One Time Pad? and I won't add to the confusion, but that question might provide some insight.
I have a stream of data that is nearly-random
Then use it seed a CSPRNG as Why in one time pad must the key distribution to be truly random and Why does the key for a one-time pad have to be uniformly distributed? show why you shouldn't use it raw. If your system has the capacity to store a large one time pad, it probably has enough computing power to run some form of CSPRNG. There are ChaCha derived implementations that will run as low as Arduino level. Just make sure that your original entropy is sufficient, typically 128 bits or more. That might require some compression /folding of the raw data to suite the seed size of the CSPRNG you should be using.
In many respects, this is the hardest part facing you as accurate entropy measurement of data is tricky. You clearly want to avoid the situation where a 1kbit stream of data only has a few bits of entropy as it's generated purely arithmetically.
answered 1 hour ago
Paul Uszak
6,19411332
add a comment |Â
up vote
1
down vote
up vote
1
down vote
Distilling your question down to these two salient points:-
Why don't we use OTP in every case, what is the downside?
which leads directly to Why wouldn't everyone encrypt with a One Time Pad? and I won't add to the confusion, but that question might provide some insight.
I have a stream of data that is nearly-random
Then use it seed a CSPRNG as Why in one time pad must the key distribution to be truly random and Why does the key for a one-time pad have to be uniformly distributed? show why you shouldn't use it raw. If your system has the capacity to store a large one time pad, it probably has enough computing power to run some form of CSPRNG. There are ChaCha derived implementations that will run as low as Arduino level. Just make sure that your original entropy is sufficient, typically 128 bits or more. That might require some compression /folding of the raw data to suite the seed size of the CSPRNG you should be using.
In many respects, this is the hardest part facing you as accurate entropy measurement of data is tricky. You clearly want to avoid the situation where a 1kbit stream of data only has a few bits of entropy as it's generated purely arithmetically.
answered 1 hour ago
Paul Uszak
6,19411332
Distilling your question down to these two salient points:-
Why don't we use OTP in every case, what is the downside?
which leads directly to Why wouldn't everyone encrypt with a One Time Pad? and I won't add to the confusion, but that question might provide some insight.
I have a stream of data that is nearly-random
Then use it seed a CSPRNG as Why in one time pad must the key distribution to be truly random and Why does the key for a one-time pad have to be uniformly distributed? show why you shouldn't use it raw. If your system has the capacity to store a large one time pad, it probably has enough computing power to run some form of CSPRNG. There are ChaCha derived implementations that will run as low as Arduino level. Just make sure that your original entropy is sufficient, typically 128 bits or more. That might require some compression /folding of the raw data to suite the seed size of the CSPRNG you should be using.
In many respects, this is the hardest part facing you as accurate entropy measurement of data is tricky. You clearly want to avoid the situation where a 1kbit stream of data only has a few bits of entropy as it's generated purely arithmetically.
answered 1 hour ago
Paul Uszak
6,19411332
answered 1 hour ago
Paul Uszak
6,19411332
answered 1 hour ago
Paul Uszak
6,19411332
answered 1 hour ago
Paul Uszak
6,19411332
6,19411332
add a comment |Â
add a comment |Â
up vote
1
down vote
Let's say I cannot afford to use encryption algorithms, but I have a stream of data that is nearly-random. [...]
I think one problem you're having is that you're treating this as a reasonable assumption: that cryptographic algorithms are somehow costlier than random bit generation. But it's the other way around—OTP is the costlier alternative.
One useful way to think about modern cryptography is this: the point of cryptography is to reduce our requirements for pre-cryptographic secure channels. All cryptography, from OTP to DH, needs to make some use of some such channel to work:
- OTP requires that the parties share at least as much random key material as the amount of data they plan to encrypt. This key material must be exchanged over a channel that's confidential and guarantees message authenticity.
- Modern symmetric encryption requires the parties to share a small random secret key. This key must also be exchanged over a channel that's confidential and guarantees message authenticity.
- Public-key encryption requires one of the parties to know the other's public key. This key must be obtained over a channel that guarantees message authenticity, but doesn't have to be confidential.
So looking at it from this angle, OTP is the costliest by far. Every bit that you encrypt with an OTP must be "paid for" by sending a pad bit over a costlier key establishment channel that you cannot protect cryptographically. If you think about it you can see that this volume limit also implies an average bandwidth limit—measured over long time periods, your encrypted message bandwidth cannot exceed the key establishment channel's bandwidth. If I can only establish 1 GiB of pad material per week, then that's how much data I can encrypt on average as well.
In comparison, with modern symmetric encryption a 128-bit AES key is sufficient to encrypt vast volumes of data. My key establishment channel can have a bandwidth vastly smaller than my encrypted communications.
answered 28 mins ago
Luis Casillas
9,13211135
add a comment |Â
up vote
1
down vote
Let's say I cannot afford to use encryption algorithms, but I have a stream of data that is nearly-random. [...]
I think one problem you're having is that you're treating this as a reasonable assumption: that cryptographic algorithms are somehow costlier than random bit generation. But it's the other way around—OTP is the costlier alternative.
One useful way to think about modern cryptography is this: the point of cryptography is to reduce our requirements for pre-cryptographic secure channels. All cryptography, from OTP to DH, needs to make some use of some such channel to work:
- OTP requires that the parties share at least as much random key material as the amount of data they plan to encrypt. This key material must be exchanged over a channel that's confidential and guarantees message authenticity.
- Modern symmetric encryption requires the parties to share a small random secret key. This key must also be exchanged over a channel that's confidential and guarantees message authenticity.
- Public-key encryption requires one of the parties to know the other's public key. This key must be obtained over a channel that guarantees message authenticity, but doesn't have to be confidential.
So looking at it from this angle, OTP is the costliest by far. Every bit that you encrypt with an OTP must be "paid for" by sending a pad bit over a costlier key establishment channel that you cannot protect cryptographically. If you think about it you can see that this volume limit also implies an average bandwidth limit—measured over long time periods, your encrypted message bandwidth cannot exceed the key establishment channel's bandwidth. If I can only establish 1 GiB of pad material per week, then that's how much data I can encrypt on average as well.
In comparison, with modern symmetric encryption a 128-bit AES key is sufficient to encrypt vast volumes of data. My key establishment channel can have a bandwidth vastly smaller than my encrypted communications.
answered 28 mins ago
Luis Casillas
9,13211135
add a comment |Â
up vote
1
down vote
up vote
1
down vote
Let's say I cannot afford to use encryption algorithms, but I have a stream of data that is nearly-random. [...]
I think one problem you're having is that you're treating this as a reasonable assumption: that cryptographic algorithms are somehow costlier than random bit generation. But it's the other way around—OTP is the costlier alternative.
One useful way to think about modern cryptography is this: the point of cryptography is to reduce our requirements for pre-cryptographic secure channels. All cryptography, from OTP to DH, needs to make some use of some such channel to work:
- OTP requires that the parties share at least as much random key material as the amount of data they plan to encrypt. This key material must be exchanged over a channel that's confidential and guarantees message authenticity.
- Modern symmetric encryption requires the parties to share a small random secret key. This key must also be exchanged over a channel that's confidential and guarantees message authenticity.
- Public-key encryption requires one of the parties to know the other's public key. This key must be obtained over a channel that guarantees message authenticity, but doesn't have to be confidential.
So looking at it from this angle, OTP is the costliest by far. Every bit that you encrypt with an OTP must be "paid for" by sending a pad bit over a costlier key establishment channel that you cannot protect cryptographically. If you think about it you can see that this volume limit also implies an average bandwidth limit—measured over long time periods, your encrypted message bandwidth cannot exceed the key establishment channel's bandwidth. If I can only establish 1 GiB of pad material per week, then that's how much data I can encrypt on average as well.
In comparison, with modern symmetric encryption a 128-bit AES key is sufficient to encrypt vast volumes of data. My key establishment channel can have a bandwidth vastly smaller than my encrypted communications.
answered 28 mins ago
Luis Casillas
9,13211135
Let's say I cannot afford to use encryption algorithms, but I have a stream of data that is nearly-random. [...]
I think one problem you're having is that you're treating this as a reasonable assumption: that cryptographic algorithms are somehow costlier than random bit generation. But it's the other way around—OTP is the costlier alternative.
One useful way to think about modern cryptography is this: the point of cryptography is to reduce our requirements for pre-cryptographic secure channels. All cryptography, from OTP to DH, needs to make some use of some such channel to work:
- OTP requires that the parties share at least as much random key material as the amount of data they plan to encrypt. This key material must be exchanged over a channel that's confidential and guarantees message authenticity.
- Modern symmetric encryption requires the parties to share a small random secret key. This key must also be exchanged over a channel that's confidential and guarantees message authenticity.
- Public-key encryption requires one of the parties to know the other's public key. This key must be obtained over a channel that guarantees message authenticity, but doesn't have to be confidential.
So looking at it from this angle, OTP is the costliest by far. Every bit that you encrypt with an OTP must be "paid for" by sending a pad bit over a costlier key establishment channel that you cannot protect cryptographically. If you think about it you can see that this volume limit also implies an average bandwidth limit—measured over long time periods, your encrypted message bandwidth cannot exceed the key establishment channel's bandwidth. If I can only establish 1 GiB of pad material per week, then that's how much data I can encrypt on average as well.
In comparison, with modern symmetric encryption a 128-bit AES key is sufficient to encrypt vast volumes of data. My key establishment channel can have a bandwidth vastly smaller than my encrypted communications.
answered 28 mins ago
Luis Casillas
9,13211135
answered 28 mins ago
Luis Casillas
9,13211135
answered 28 mins ago
Luis Casillas
9,13211135
answered 28 mins ago
Luis Casillas
9,13211135
9,13211135
add a comment |Â
add a comment |Â
up vote
0
down vote
If I use this as an OTP (I know this is not perfectly random), what do I sacrifice in return?
Why don't we use OTP in every case, what is the downside?
The problem with OPT is key distribution. If you have a secure channel to transmit the key, then instead of the key, transmit the message.
OPT is used between embassies and the governments. The embassies can return the Capitol and take a suitcase to carry the OPT with them. There the problem is when the OTP key is finished will you stop communicating or start to reuse?
It is used since it has perfect secrecy.
I have a stream of data that is nearly-random. If I use this as an OTP (I know this is not perfectly random), what do I sacrifice in return?
The answer depends on the definition of your nearly random. If it is an LFSR, I can try all possible LFSR outputs up to some length.
Is a PRG more costly than AES or any other encryption standard?
Compare the cost of carrying securely the OPT or using Public Key Encryption to Key exchange for Symmetric key encryption.
answered 2 hours ago
kelalaka
1,133217
add a comment |Â
up vote
0
down vote
If I use this as an OTP (I know this is not perfectly random), what do I sacrifice in return?
Why don't we use OTP in every case, what is the downside?
The problem with OPT is key distribution. If you have a secure channel to transmit the key, then instead of the key, transmit the message.
OPT is used between embassies and the governments. The embassies can return the Capitol and take a suitcase to carry the OPT with them. There the problem is when the OTP key is finished will you stop communicating or start to reuse?
It is used since it has perfect secrecy.
I have a stream of data that is nearly-random. If I use this as an OTP (I know this is not perfectly random), what do I sacrifice in return?
The answer depends on the definition of your nearly random. If it is an LFSR, I can try all possible LFSR outputs up to some length.
Is a PRG more costly than AES or any other encryption standard?
Compare the cost of carrying securely the OPT or using Public Key Encryption to Key exchange for Symmetric key encryption.
answered 2 hours ago
kelalaka
1,133217
add a comment |Â
up vote
0
down vote
up vote
0
down vote
If I use this as an OTP (I know this is not perfectly random), what do I sacrifice in return?
Why don't we use OTP in every case, what is the downside?
The problem with OPT is key distribution. If you have a secure channel to transmit the key, then instead of the key, transmit the message.
OPT is used between embassies and the governments. The embassies can return the Capitol and take a suitcase to carry the OPT with them. There the problem is when the OTP key is finished will you stop communicating or start to reuse?
It is used since it has perfect secrecy.
I have a stream of data that is nearly-random. If I use this as an OTP (I know this is not perfectly random), what do I sacrifice in return?
The answer depends on the definition of your nearly random. If it is an LFSR, I can try all possible LFSR outputs up to some length.
Is a PRG more costly than AES or any other encryption standard?
Compare the cost of carrying securely the OPT or using Public Key Encryption to Key exchange for Symmetric key encryption.
answered 2 hours ago
kelalaka
1,133217
If I use this as an OTP (I know this is not perfectly random), what do I sacrifice in return?
Why don't we use OTP in every case, what is the downside?
The problem with OPT is key distribution. If you have a secure channel to transmit the key, then instead of the key, transmit the message.
OPT is used between embassies and the governments. The embassies can return the Capitol and take a suitcase to carry the OPT with them. There the problem is when the OTP key is finished will you stop communicating or start to reuse?
It is used since it has perfect secrecy.
I have a stream of data that is nearly-random. If I use this as an OTP (I know this is not perfectly random), what do I sacrifice in return?
The answer depends on the definition of your nearly random. If it is an LFSR, I can try all possible LFSR outputs up to some length.
Is a PRG more costly than AES or any other encryption standard?
Compare the cost of carrying securely the OPT or using Public Key Encryption to Key exchange for Symmetric key encryption.
answered 2 hours ago
kelalaka
1,133217
edited 1 hour ago
answered 2 hours ago
kelalaka
1,133217
answered 2 hours ago
kelalaka
1,133217
answered 2 hours ago
kelalaka
1,133217
1,133217
add a comment |Â
add a comment |Â
up vote
0
down vote
A one-time pad requires a true random sequence that is as long as the material you want to encrypt. If you have a pseudo-random sequence, then you don't have a one-time pad: you have a stream cipher. If you have a stream of data that is only “nearly randomâ€Â, then you don't have a one-time pad, you have a broken stream cipher.
Concretely, if the nearly-random sequence isn't uniform, it means that there are biases: certain arrangements of bits are more likely than certain others. Whenever these arrangements are aligned with a pattern in the plaintext — for example English text contains more E than J, text in most languages contains more spaces than any other character, HTML tends to have a > shortly after each <, … — the pattern in the plaintext becomes apparent in the ciphertext. So certain patterns appear in the ciphertext more often than chance, they will reveal patterns in the plaintext.
To generate a cryptographically secure random sequence from a source of randomness that isn't perfectly uniform, you need to pass this random source through a cryptographically secure pseudorandom generator. One of the cheapest techniques to build a pseudorandom generator is to use an encryption algorithm such as AES in a construction known as CTR_DRBG. If all you want to do is to encrypt one message, then it's simpler and cheaper to encrypt the message with AES-CTR than do use AES-CTR_DRBG to build a key stream and to use that key stream to encrypt a message.
In addition, a one-time pad doesn't help with the authenticity of the message. If the message is modified in transit, there's no way to detect it. Encryption algorithms can be combined with authentication algorithm, and the cost of doing the two together is less than the cost of doing the two completely independently. The computational cost is only slightly less, but the cost in code size or in gate count is significantly less. For example, once you have the AES block cipher, it only takes a little additional work to build an authenticated encryption mode such as GCM or CCM.
answered 12 mins ago
Gilles
7,04732548
add a comment |Â
up vote
0
down vote
A one-time pad requires a true random sequence that is as long as the material you want to encrypt. If you have a pseudo-random sequence, then you don't have a one-time pad: you have a stream cipher. If you have a stream of data that is only “nearly randomâ€Â, then you don't have a one-time pad, you have a broken stream cipher.
Concretely, if the nearly-random sequence isn't uniform, it means that there are biases: certain arrangements of bits are more likely than certain others. Whenever these arrangements are aligned with a pattern in the plaintext — for example English text contains more E than J, text in most languages contains more spaces than any other character, HTML tends to have a > shortly after each <, … — the pattern in the plaintext becomes apparent in the ciphertext. So certain patterns appear in the ciphertext more often than chance, they will reveal patterns in the plaintext.
To generate a cryptographically secure random sequence from a source of randomness that isn't perfectly uniform, you need to pass this random source through a cryptographically secure pseudorandom generator. One of the cheapest techniques to build a pseudorandom generator is to use an encryption algorithm such as AES in a construction known as CTR_DRBG. If all you want to do is to encrypt one message, then it's simpler and cheaper to encrypt the message with AES-CTR than do use AES-CTR_DRBG to build a key stream and to use that key stream to encrypt a message.
In addition, a one-time pad doesn't help with the authenticity of the message. If the message is modified in transit, there's no way to detect it. Encryption algorithms can be combined with authentication algorithm, and the cost of doing the two together is less than the cost of doing the two completely independently. The computational cost is only slightly less, but the cost in code size or in gate count is significantly less. For example, once you have the AES block cipher, it only takes a little additional work to build an authenticated encryption mode such as GCM or CCM.
answered 12 mins ago
Gilles
7,04732548
add a comment |Â
up vote
0
down vote
up vote
0
down vote
A one-time pad requires a true random sequence that is as long as the material you want to encrypt. If you have a pseudo-random sequence, then you don't have a one-time pad: you have a stream cipher. If you have a stream of data that is only “nearly randomâ€Â, then you don't have a one-time pad, you have a broken stream cipher.
Concretely, if the nearly-random sequence isn't uniform, it means that there are biases: certain arrangements of bits are more likely than certain others. Whenever these arrangements are aligned with a pattern in the plaintext — for example English text contains more E than J, text in most languages contains more spaces than any other character, HTML tends to have a > shortly after each <, … — the pattern in the plaintext becomes apparent in the ciphertext. So certain patterns appear in the ciphertext more often than chance, they will reveal patterns in the plaintext.
To generate a cryptographically secure random sequence from a source of randomness that isn't perfectly uniform, you need to pass this random source through a cryptographically secure pseudorandom generator. One of the cheapest techniques to build a pseudorandom generator is to use an encryption algorithm such as AES in a construction known as CTR_DRBG. If all you want to do is to encrypt one message, then it's simpler and cheaper to encrypt the message with AES-CTR than do use AES-CTR_DRBG to build a key stream and to use that key stream to encrypt a message.
In addition, a one-time pad doesn't help with the authenticity of the message. If the message is modified in transit, there's no way to detect it. Encryption algorithms can be combined with authentication algorithm, and the cost of doing the two together is less than the cost of doing the two completely independently. The computational cost is only slightly less, but the cost in code size or in gate count is significantly less. For example, once you have the AES block cipher, it only takes a little additional work to build an authenticated encryption mode such as GCM or CCM.
answered 12 mins ago
Gilles
7,04732548
A one-time pad requires a true random sequence that is as long as the material you want to encrypt. If you have a pseudo-random sequence, then you don't have a one-time pad: you have a stream cipher. If you have a stream of data that is only “nearly randomâ€Â, then you don't have a one-time pad, you have a broken stream cipher.
Concretely, if the nearly-random sequence isn't uniform, it means that there are biases: certain arrangements of bits are more likely than certain others. Whenever these arrangements are aligned with a pattern in the plaintext — for example English text contains more E than J, text in most languages contains more spaces than any other character, HTML tends to have a > shortly after each <, … — the pattern in the plaintext becomes apparent in the ciphertext. So certain patterns appear in the ciphertext more often than chance, they will reveal patterns in the plaintext.
To generate a cryptographically secure random sequence from a source of randomness that isn't perfectly uniform, you need to pass this random source through a cryptographically secure pseudorandom generator. One of the cheapest techniques to build a pseudorandom generator is to use an encryption algorithm such as AES in a construction known as CTR_DRBG. If all you want to do is to encrypt one message, then it's simpler and cheaper to encrypt the message with AES-CTR than do use AES-CTR_DRBG to build a key stream and to use that key stream to encrypt a message.
In addition, a one-time pad doesn't help with the authenticity of the message. If the message is modified in transit, there's no way to detect it. Encryption algorithms can be combined with authentication algorithm, and the cost of doing the two together is less than the cost of doing the two completely independently. The computational cost is only slightly less, but the cost in code size or in gate count is significantly less. For example, once you have the AES block cipher, it only takes a little additional work to build an authenticated encryption mode such as GCM or CCM.
answered 12 mins ago
Gilles
7,04732548
answered 12 mins ago
Gilles
7,04732548
answered 12 mins ago
Gilles
7,04732548
answered 12 mins ago
Gilles
7,04732548
7,04732548
add a comment |Â
add a comment |Â
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
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcrypto.stackexchange.com%2fquestions%2f63160%2fis-a-prg-more-costly-than-aes-or-any-other-encryption-standard%23new-answer', 'question_page');
);
Post as a guest
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
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
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
