Mixing
Which Encryption allows for the less output text than source?
Clash Royale CLAN TAG#URR8PPP
up vote
1
down vote
favorite
I am trying to figure out how to get my source information to compile smaller using encrypted text.
This could potentially change the game in transferring large-chunked data and offer security at the same time.
are there any encryption types that change source to fewer letters and numbers?
encryption
asked 52 mins ago
DeerSpotter
1062
New contributor
DeerSpotter is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |Â
up vote
1
down vote
favorite
I am trying to figure out how to get my source information to compile smaller using encrypted text.
This could potentially change the game in transferring large-chunked data and offer security at the same time.
are there any encryption types that change source to fewer letters and numbers?
encryption
asked 52 mins ago
DeerSpotter
1062
New contributor
DeerSpotter is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
4
That's called compression, and it's a completely separate thing from encryption.
– AndrolGenhald
46 mins ago
@AndrolGenhald lets stick to my question, i want to encrypt it first.
– DeerSpotter
44 mins ago
@DeerSpotter - You literally can't. Encrypted data is meant to be indistinguishable from random data and random data is provably uncompressable. If you could compress random data, there'd be nothing from stopping you from compressing the compressed output to get an even smaller file still. Repeat it enough and you'll end up with a 1-byte file which clearly isn't enough data to represent the original input.
– Mr. Llama
5 mins ago
add a comment |Â
up vote
1
down vote
favorite
up vote
1
down vote
favorite
I am trying to figure out how to get my source information to compile smaller using encrypted text.
This could potentially change the game in transferring large-chunked data and offer security at the same time.
are there any encryption types that change source to fewer letters and numbers?
encryption
asked 52 mins ago
DeerSpotter
1062
New contributor
DeerSpotter is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
I am trying to figure out how to get my source information to compile smaller using encrypted text.
This could potentially change the game in transferring large-chunked data and offer security at the same time.
are there any encryption types that change source to fewer letters and numbers?
encryption
encryption
asked 52 mins ago
DeerSpotter
1062
New contributor
DeerSpotter is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 52 mins ago
DeerSpotter
1062
New contributor
DeerSpotter is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 52 mins ago
DeerSpotter
1062
New contributor
DeerSpotter is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 52 mins ago
DeerSpotter
1062
asked 52 mins ago
DeerSpotter
1062
1062
New contributor
DeerSpotter is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
DeerSpotter is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
DeerSpotter is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
4
That's called compression, and it's a completely separate thing from encryption.
– AndrolGenhald
46 mins ago
@AndrolGenhald lets stick to my question, i want to encrypt it first.
– DeerSpotter
44 mins ago
@DeerSpotter - You literally can't. Encrypted data is meant to be indistinguishable from random data and random data is provably uncompressable. If you could compress random data, there'd be nothing from stopping you from compressing the compressed output to get an even smaller file still. Repeat it enough and you'll end up with a 1-byte file which clearly isn't enough data to represent the original input.
– Mr. Llama
5 mins ago
add a comment |Â
4
That's called compression, and it's a completely separate thing from encryption.
– AndrolGenhald
46 mins ago
@AndrolGenhald lets stick to my question, i want to encrypt it first.
– DeerSpotter
44 mins ago
@DeerSpotter - You literally can't. Encrypted data is meant to be indistinguishable from random data and random data is provably uncompressable. If you could compress random data, there'd be nothing from stopping you from compressing the compressed output to get an even smaller file still. Repeat it enough and you'll end up with a 1-byte file which clearly isn't enough data to represent the original input.
– Mr. Llama
5 mins ago
4
4
That's called compression, and it's a completely separate thing from encryption.
– AndrolGenhald
46 mins ago
That's called compression, and it's a completely separate thing from encryption.
– AndrolGenhald
46 mins ago
@AndrolGenhald lets stick to my question, i want to encrypt it first.
– DeerSpotter
44 mins ago
@AndrolGenhald lets stick to my question, i want to encrypt it first.
– DeerSpotter
44 mins ago
@DeerSpotter - You literally can't. Encrypted data is meant to be indistinguishable from random data and random data is provably uncompressable. If you could compress random data, there'd be nothing from stopping you from compressing the compressed output to get an even smaller file still. Repeat it enough and you'll end up with a 1-byte file which clearly isn't enough data to represent the original input.
– Mr. Llama
5 mins ago
@DeerSpotter - You literally can't. Encrypted data is meant to be indistinguishable from random data and random data is provably uncompressable. If you could compress random data, there'd be nothing from stopping you from compressing the compressed output to get an even smaller file still. Repeat it enough and you'll end up with a 1-byte file which clearly isn't enough data to represent the original input.
– Mr. Llama
5 mins ago
add a comment |Â
3 Answers
3
active
oldest
votes
up vote
5
down vote
Encrypted data should be indistinguishable from random noise. Random data cannot be compressed. Therefore, compress data first and then encrypt it.
answered 46 mins ago
DarkMatter
1315
i want to encrypt it first, seems straight forward question?
– DeerSpotter
45 mins ago
3
@DeerSpotter Encryption produces a high entropy output, making compression after encryption next to useless. The answer is correct.
– Daisetsu
40 mins ago
add a comment |Â
up vote
0
down vote
Per my co-worker: the less characters and numbers that you have, the less entropy you have, which could reduce your encryption to a vulnerable state
The less your attacker has to guess the more vulnerable it is.
you don't want to reduce it, you want to increase it, it will add more overhead but increases security
Edit: just realized someone said basically the same thing above
answered 31 mins ago
Matt
396
add a comment |Â
up vote
0
down vote
No, what you are trying to accomplish is impossible.
Encryption tries to keep information confidential. For this it takes one input message out of all possible input messages and encrypts in such a way that the output doesn't leak any information about the input message. Obviously you do not want that messages encrypt to the same output because in that case you would not be able to retrieve one message, or you would not be able to choose which message was encrypted.
Now if the output would be smaller than the input then by definition there would be fewer output values than input messages. In that case there must be messages mapped to an output value that has already been assigned to another input message. This is called the Pigeonhole principle and it is explained in most cryptography primers.
So the best you can do is to break even.
Even breaking even would get you into trouble if you try to reuse the key. The problem is that an identical message would encrypt to the same output, leaking information to an attacker that the messages are identical. For this most ciphers require an IV as input. Sometimes this IV can be generated during encryption and decryption (sector numbers for hard drive encryption) but often the IV needs to be stored next to the ciphertext.
And then you would still have a message that is confidential, but it is not integrity protected or authenticated. In general you would need to add an authentication tag as well. For this reason, in practice, encryption will expand the size of the message.
In other words: the only thing you can do is to reduce the input message space. This can be done by performing compression. But you could also try and find a better way of encoding the information in the input message. For instance, XML has a lot of overhead, which could be removed by using a binary encoding such as ASN.1 with DER or even the weird but highly efficient PER encoding rules.
Beware though that ciphertext size may also leak information to an attacker. For instance the bit rate of an variable rate MP3 stream could say a lot about the contents of the stream, which would be hidden if a constant rate stream would be used.
Finally I would like you to point to Format Preserving Encryption or FPE. FPE can be used to provide encryption of messages where the output message space is exactly as large as the input message space, even if the input message space is not a power of two (i.e. can be encoded simply as a set of bits). This method is often used to encrypt information such as credit card numbers, where the input message is certain to never repeat.
answered 12 mins ago
Maarten Bodewes
3,0611119
add a comment |Â
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
5
down vote
Encrypted data should be indistinguishable from random noise. Random data cannot be compressed. Therefore, compress data first and then encrypt it.
answered 46 mins ago
DarkMatter
1315
i want to encrypt it first, seems straight forward question?
– DeerSpotter
45 mins ago
3
@DeerSpotter Encryption produces a high entropy output, making compression after encryption next to useless. The answer is correct.
– Daisetsu
40 mins ago
add a comment |Â
up vote
5
down vote
Encrypted data should be indistinguishable from random noise. Random data cannot be compressed. Therefore, compress data first and then encrypt it.
answered 46 mins ago
DarkMatter
1315
i want to encrypt it first, seems straight forward question?
– DeerSpotter
45 mins ago
3
@DeerSpotter Encryption produces a high entropy output, making compression after encryption next to useless. The answer is correct.
– Daisetsu
40 mins ago
add a comment |Â
up vote
5
down vote
up vote
5
down vote
Encrypted data should be indistinguishable from random noise. Random data cannot be compressed. Therefore, compress data first and then encrypt it.
answered 46 mins ago
DarkMatter
1315
Encrypted data should be indistinguishable from random noise. Random data cannot be compressed. Therefore, compress data first and then encrypt it.
answered 46 mins ago
DarkMatter
1315
edited 35 mins ago
answered 46 mins ago
DarkMatter
1315
answered 46 mins ago
DarkMatter
1315
answered 46 mins ago
DarkMatter
1315
1315
i want to encrypt it first, seems straight forward question?
– DeerSpotter
45 mins ago
3
@DeerSpotter Encryption produces a high entropy output, making compression after encryption next to useless. The answer is correct.
– Daisetsu
40 mins ago
add a comment |Â
i want to encrypt it first, seems straight forward question?
– DeerSpotter
45 mins ago
3
@DeerSpotter Encryption produces a high entropy output, making compression after encryption next to useless. The answer is correct.
– Daisetsu
40 mins ago
i want to encrypt it first, seems straight forward question?
– DeerSpotter
45 mins ago
i want to encrypt it first, seems straight forward question?
– DeerSpotter
45 mins ago
3
3
@DeerSpotter Encryption produces a high entropy output, making compression after encryption next to useless. The answer is correct.
– Daisetsu
40 mins ago
@DeerSpotter Encryption produces a high entropy output, making compression after encryption next to useless. The answer is correct.
– Daisetsu
40 mins ago
add a comment |Â
up vote
0
down vote
Per my co-worker: the less characters and numbers that you have, the less entropy you have, which could reduce your encryption to a vulnerable state
The less your attacker has to guess the more vulnerable it is.
you don't want to reduce it, you want to increase it, it will add more overhead but increases security
Edit: just realized someone said basically the same thing above
answered 31 mins ago
Matt
396
add a comment |Â
up vote
0
down vote
Per my co-worker: the less characters and numbers that you have, the less entropy you have, which could reduce your encryption to a vulnerable state
The less your attacker has to guess the more vulnerable it is.
you don't want to reduce it, you want to increase it, it will add more overhead but increases security
Edit: just realized someone said basically the same thing above
answered 31 mins ago
Matt
396
add a comment |Â
up vote
0
down vote
up vote
0
down vote
Per my co-worker: the less characters and numbers that you have, the less entropy you have, which could reduce your encryption to a vulnerable state
The less your attacker has to guess the more vulnerable it is.
you don't want to reduce it, you want to increase it, it will add more overhead but increases security
Edit: just realized someone said basically the same thing above
answered 31 mins ago
Matt
396
Per my co-worker: the less characters and numbers that you have, the less entropy you have, which could reduce your encryption to a vulnerable state
The less your attacker has to guess the more vulnerable it is.
you don't want to reduce it, you want to increase it, it will add more overhead but increases security
Edit: just realized someone said basically the same thing above
answered 31 mins ago
Matt
396
answered 31 mins ago
Matt
396
answered 31 mins ago
Matt
396
answered 31 mins ago
Matt
396
396
add a comment |Â
add a comment |Â
up vote
0
down vote
No, what you are trying to accomplish is impossible.
Encryption tries to keep information confidential. For this it takes one input message out of all possible input messages and encrypts in such a way that the output doesn't leak any information about the input message. Obviously you do not want that messages encrypt to the same output because in that case you would not be able to retrieve one message, or you would not be able to choose which message was encrypted.
Now if the output would be smaller than the input then by definition there would be fewer output values than input messages. In that case there must be messages mapped to an output value that has already been assigned to another input message. This is called the Pigeonhole principle and it is explained in most cryptography primers.
So the best you can do is to break even.
Even breaking even would get you into trouble if you try to reuse the key. The problem is that an identical message would encrypt to the same output, leaking information to an attacker that the messages are identical. For this most ciphers require an IV as input. Sometimes this IV can be generated during encryption and decryption (sector numbers for hard drive encryption) but often the IV needs to be stored next to the ciphertext.
And then you would still have a message that is confidential, but it is not integrity protected or authenticated. In general you would need to add an authentication tag as well. For this reason, in practice, encryption will expand the size of the message.
In other words: the only thing you can do is to reduce the input message space. This can be done by performing compression. But you could also try and find a better way of encoding the information in the input message. For instance, XML has a lot of overhead, which could be removed by using a binary encoding such as ASN.1 with DER or even the weird but highly efficient PER encoding rules.
Beware though that ciphertext size may also leak information to an attacker. For instance the bit rate of an variable rate MP3 stream could say a lot about the contents of the stream, which would be hidden if a constant rate stream would be used.
Finally I would like you to point to Format Preserving Encryption or FPE. FPE can be used to provide encryption of messages where the output message space is exactly as large as the input message space, even if the input message space is not a power of two (i.e. can be encoded simply as a set of bits). This method is often used to encrypt information such as credit card numbers, where the input message is certain to never repeat.
answered 12 mins ago
Maarten Bodewes
3,0611119
add a comment |Â
up vote
0
down vote
No, what you are trying to accomplish is impossible.
Encryption tries to keep information confidential. For this it takes one input message out of all possible input messages and encrypts in such a way that the output doesn't leak any information about the input message. Obviously you do not want that messages encrypt to the same output because in that case you would not be able to retrieve one message, or you would not be able to choose which message was encrypted.
Now if the output would be smaller than the input then by definition there would be fewer output values than input messages. In that case there must be messages mapped to an output value that has already been assigned to another input message. This is called the Pigeonhole principle and it is explained in most cryptography primers.
So the best you can do is to break even.
Even breaking even would get you into trouble if you try to reuse the key. The problem is that an identical message would encrypt to the same output, leaking information to an attacker that the messages are identical. For this most ciphers require an IV as input. Sometimes this IV can be generated during encryption and decryption (sector numbers for hard drive encryption) but often the IV needs to be stored next to the ciphertext.
And then you would still have a message that is confidential, but it is not integrity protected or authenticated. In general you would need to add an authentication tag as well. For this reason, in practice, encryption will expand the size of the message.
In other words: the only thing you can do is to reduce the input message space. This can be done by performing compression. But you could also try and find a better way of encoding the information in the input message. For instance, XML has a lot of overhead, which could be removed by using a binary encoding such as ASN.1 with DER or even the weird but highly efficient PER encoding rules.
Beware though that ciphertext size may also leak information to an attacker. For instance the bit rate of an variable rate MP3 stream could say a lot about the contents of the stream, which would be hidden if a constant rate stream would be used.
Finally I would like you to point to Format Preserving Encryption or FPE. FPE can be used to provide encryption of messages where the output message space is exactly as large as the input message space, even if the input message space is not a power of two (i.e. can be encoded simply as a set of bits). This method is often used to encrypt information such as credit card numbers, where the input message is certain to never repeat.
answered 12 mins ago
Maarten Bodewes
3,0611119
add a comment |Â
up vote
0
down vote
up vote
0
down vote
No, what you are trying to accomplish is impossible.
Encryption tries to keep information confidential. For this it takes one input message out of all possible input messages and encrypts in such a way that the output doesn't leak any information about the input message. Obviously you do not want that messages encrypt to the same output because in that case you would not be able to retrieve one message, or you would not be able to choose which message was encrypted.
Now if the output would be smaller than the input then by definition there would be fewer output values than input messages. In that case there must be messages mapped to an output value that has already been assigned to another input message. This is called the Pigeonhole principle and it is explained in most cryptography primers.
So the best you can do is to break even.
Even breaking even would get you into trouble if you try to reuse the key. The problem is that an identical message would encrypt to the same output, leaking information to an attacker that the messages are identical. For this most ciphers require an IV as input. Sometimes this IV can be generated during encryption and decryption (sector numbers for hard drive encryption) but often the IV needs to be stored next to the ciphertext.
And then you would still have a message that is confidential, but it is not integrity protected or authenticated. In general you would need to add an authentication tag as well. For this reason, in practice, encryption will expand the size of the message.
In other words: the only thing you can do is to reduce the input message space. This can be done by performing compression. But you could also try and find a better way of encoding the information in the input message. For instance, XML has a lot of overhead, which could be removed by using a binary encoding such as ASN.1 with DER or even the weird but highly efficient PER encoding rules.
Beware though that ciphertext size may also leak information to an attacker. For instance the bit rate of an variable rate MP3 stream could say a lot about the contents of the stream, which would be hidden if a constant rate stream would be used.
Finally I would like you to point to Format Preserving Encryption or FPE. FPE can be used to provide encryption of messages where the output message space is exactly as large as the input message space, even if the input message space is not a power of two (i.e. can be encoded simply as a set of bits). This method is often used to encrypt information such as credit card numbers, where the input message is certain to never repeat.
answered 12 mins ago
Maarten Bodewes
3,0611119
No, what you are trying to accomplish is impossible.
Encryption tries to keep information confidential. For this it takes one input message out of all possible input messages and encrypts in such a way that the output doesn't leak any information about the input message. Obviously you do not want that messages encrypt to the same output because in that case you would not be able to retrieve one message, or you would not be able to choose which message was encrypted.
Now if the output would be smaller than the input then by definition there would be fewer output values than input messages. In that case there must be messages mapped to an output value that has already been assigned to another input message. This is called the Pigeonhole principle and it is explained in most cryptography primers.
So the best you can do is to break even.
Even breaking even would get you into trouble if you try to reuse the key. The problem is that an identical message would encrypt to the same output, leaking information to an attacker that the messages are identical. For this most ciphers require an IV as input. Sometimes this IV can be generated during encryption and decryption (sector numbers for hard drive encryption) but often the IV needs to be stored next to the ciphertext.
And then you would still have a message that is confidential, but it is not integrity protected or authenticated. In general you would need to add an authentication tag as well. For this reason, in practice, encryption will expand the size of the message.
In other words: the only thing you can do is to reduce the input message space. This can be done by performing compression. But you could also try and find a better way of encoding the information in the input message. For instance, XML has a lot of overhead, which could be removed by using a binary encoding such as ASN.1 with DER or even the weird but highly efficient PER encoding rules.
Beware though that ciphertext size may also leak information to an attacker. For instance the bit rate of an variable rate MP3 stream could say a lot about the contents of the stream, which would be hidden if a constant rate stream would be used.
Finally I would like you to point to Format Preserving Encryption or FPE. FPE can be used to provide encryption of messages where the output message space is exactly as large as the input message space, even if the input message space is not a power of two (i.e. can be encoded simply as a set of bits). This method is often used to encrypt information such as credit card numbers, where the input message is certain to never repeat.
answered 12 mins ago
Maarten Bodewes
3,0611119
edited 7 mins ago
answered 12 mins ago
Maarten Bodewes
3,0611119
answered 12 mins ago
Maarten Bodewes
3,0611119
answered 12 mins ago
Maarten Bodewes
3,0611119
3,0611119
add a comment |Â
add a comment |Â
DeerSpotter is a new contributor. Be nice, and check out our Code of Conduct.
DeerSpotter is a new contributor. Be nice, and check out our Code of Conduct.
DeerSpotter is a new contributor. Be nice, and check out our Code of Conduct.
DeerSpotter is a new contributor. Be nice, and check out our Code of Conduct.
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%2fsecurity.stackexchange.com%2fquestions%2f196390%2fwhich-encryption-allows-for-the-less-output-text-than-source%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
4
That's called compression, and it's a completely separate thing from encryption.
– AndrolGenhald
46 mins ago
@AndrolGenhald lets stick to my question, i want to encrypt it first.
– DeerSpotter
44 mins ago
@DeerSpotter - You literally can't. Encrypted data is meant to be indistinguishable from random data and random data is provably uncompressable. If you could compress random data, there'd be nothing from stopping you from compressing the compressed output to get an even smaller file still. Repeat it enough and you'll end up with a 1-byte file which clearly isn't enough data to represent the original input.
– Mr. Llama
5 mins ago