Think if all the off-topic threads was like this.
Oh, time to wake up from the dream world
Topic: On encryption (Read 649 times)
This must be the most serious thread I have ever seen in the off-topic section
Think if all the off-topic threads was like this.
Oh, time to wake up from the dream world
Think if all the off-topic threads was like this.
Oh, time to wake up from the dream world
Ok, not the same length but the length isn't known in advance.
Huh. I thought it was. I guess with larger files it's close enough to make no difference. As you point out, it doesn't matter anyway.I'm tipping you a beer, or something like that 
.
Cheers. .
It is obvious, but not for the reason you think. Entropy analysis will reveal that the file is either encrypted or compressed, and the fact that it lacks the headers of any compressed file format rules out the latter.
Thanks, this was helpful. There's another option, it's actually random data, but that begs the question "why are you storing random data?".
No, you don't. You get an error when the password results in invalid block padding. There is a 1 in 256 chance that an incorrect password will be valid, and "successfully" produce a decrypted file of the same size as the original, but filled with entirely random data, and no way to know anything went wrong.
I actually went and try this to see it with my own eyes:
Code:
$ echo foo |aes >123 ## password "f"
enter aes-256-cbc encryption password:
Verifying - enter aes-256-cbc encryption password:
$ xxd 123
0000000: 5361 6c74 6564 5f5f ade9 addb 6d65 c7cd 00f6 4535 6b11 20bb 3bb9 aa91 f4ee 6db1 Salted__....me....E5k. .;.....m.
$ aes -d <123 |xxd
enter aes-256-cbc decryption password:
0000000: 666f 6f0a foo.
$ aes -d <123 |xxd ## password "026"
enter aes-256-cbc decryption password:
0000000: 4bf6 0a0c a1dc 465e cf40 d4ad 71e6 87 K.....F^[email protected]..
I tried decrypting with passwords 000, 001, 002… and then it happened, at 026 it decrypted without errors. Ok, not the same length but the length isn't known in advance. I'm tipping you a beer, or something like that
.@Cryptowatch: you're rolling your own crypto, that's a no no. I know steg, that's another layer I'll use.
The problem I see with this, is that it's obviously encrypted.
It is obvious, but not for the reason you think. Entropy analysis will reveal that the file is either encrypted or compressed, and the fact that it lacks the headers of any compressed file format rules out the latter.Another issue with this is that, by trying to decrypt, we get an error when the password is incorrect but a good result then the password matches:
No, you don't. You get an error when the password results in invalid block padding. There is a 1 in 256 chance that an incorrect password will be valid, and "successfully" produce a decrypted file of the same size as the original, but filled with entirely random data, and no way to know anything went wrong.
You explained your problem well, however I'm curious as to why you want it to be random looking.
One method to make it 'look' random could be to use a ROT13 inspired scheme. The very determined adversary would be able to figure it out, but for the random geek looking at the hexdump, he would be none the wiser.
Since the english alphabet has 26 letters, you could roll your own rotation scheme.
Start by doing something like:
A = M
B = X
C = H
etc..
Do this until all letters are mapped to another. You should now have 13 pairs. Since the mapping is fairly random, if someone hexdumped the data, instead of ABC, they'd see MXH. If there's considerable amounts of letters in the data, it would be possible to reverse engineer your mapping by using a frequency table and some experimentation.
Another perhaps easier method would be to try different encryption methods and view the hex of the data and see if any of those satisfy your requirements. Of course, if you chose to go with a rotation/mapping scheme, you'd have to reverse it before you could decrypt the data with normal methods.
But it would be a good programming exercise. First you'd have to read in the file, then do the substitutions. For example 'S' = '53', so that would need to be replaced with the letter you map it to. Let's say you mapped it to 'G', then the hexcode would be '47'. The hedump would now show '47' instead of '53'.
Such a wrapper could be done in any programming language.
When you use openssl to decrypt, you will receive standard messages from that program. That behaviour could however be changed locally if you got the source code, then changed it slightly to achieve the result you are after. However, this would naturally only be in effect on your local machine, and not on anyone elses, as they'd not have the modified openssl program.
However, if some geek where to get your encrypted data-file that you already had obfuscated through your rotation scheme and tried to do something like "echo 'U2FsdGVkX19lqSi+Z8UoUmfnUqX7QJf+vQwwlyQ0tL4=' |openssl aes-256-cbc -salt -a -d", they would probably get an error as openssl most likely would not recognize the datafile as an encrypted file. I have not tested it, so I might be wrong, but that's what seems logical.
If you want stealth, ie. hiding data without anybody being able to see it, you might want to try stenography, that means altering the content of an image to contain data. Any non-technical expert browsing through your files, would only see your nice vacation images, and not see your elaborate idea for a new energy device that would free the world.
If it's easy or not to detect images with hidden data in it, I don't know. This would warrant more research on your part.
There are most likely many other methods as well, that would be far more complicated to detect and that could deter even a very resourceful adversary, however what I just described should fool most geeks.
One method to make it 'look' random could be to use a ROT13 inspired scheme. The very determined adversary would be able to figure it out, but for the random geek looking at the hexdump, he would be none the wiser.
Since the english alphabet has 26 letters, you could roll your own rotation scheme.
Start by doing something like:
A = M
B = X
C = H
etc..
Do this until all letters are mapped to another. You should now have 13 pairs. Since the mapping is fairly random, if someone hexdumped the data, instead of ABC, they'd see MXH. If there's considerable amounts of letters in the data, it would be possible to reverse engineer your mapping by using a frequency table and some experimentation.
Another perhaps easier method would be to try different encryption methods and view the hex of the data and see if any of those satisfy your requirements. Of course, if you chose to go with a rotation/mapping scheme, you'd have to reverse it before you could decrypt the data with normal methods.
But it would be a good programming exercise. First you'd have to read in the file, then do the substitutions. For example 'S' = '53', so that would need to be replaced with the letter you map it to. Let's say you mapped it to 'G', then the hexcode would be '47'. The hedump would now show '47' instead of '53'.
Such a wrapper could be done in any programming language.
Quote
When trying to decrypt, it should always succeed, but return bogus data on wrong password.
When you use openssl to decrypt, you will receive standard messages from that program. That behaviour could however be changed locally if you got the source code, then changed it slightly to achieve the result you are after. However, this would naturally only be in effect on your local machine, and not on anyone elses, as they'd not have the modified openssl program.
However, if some geek where to get your encrypted data-file that you already had obfuscated through your rotation scheme and tried to do something like "echo 'U2FsdGVkX19lqSi+Z8UoUmfnUqX7QJf+vQwwlyQ0tL4=' |openssl aes-256-cbc -salt -a -d", they would probably get an error as openssl most likely would not recognize the datafile as an encrypted file. I have not tested it, so I might be wrong, but that's what seems logical.
If you want stealth, ie. hiding data without anybody being able to see it, you might want to try stenography, that means altering the content of an image to contain data. Any non-technical expert browsing through your files, would only see your nice vacation images, and not see your elaborate idea for a new energy device that would free the world.
If it's easy or not to detect images with hidden data in it, I don't know. This would warrant more research on your part.
There are most likely many other methods as well, that would be far more complicated to detect and that could deter even a very resourceful adversary, however what I just described should fool most geeks.
This is my first post in this section. In fact, I have the entire board ignored and don't even read it . However I think this could be a good place to ask before trying other more encryption-oriented places.
I'm currently encrypting things on several layers. On the individual file layer, I use openssl:
The problem I see with this, is that it's obviously encrypted. If we remove the "-a" parameter to openssl and run the output through an hexdump, we can see it:
Another issue with this is that, by trying to decrypt, we get an error when the password is incorrect but a good result then the password matches:
I'd like to use an encryption algorithm that produced random-looking output without any kind of prefix like openssl's "Salted__". When trying to decrypt, it should always succeed, but return bogus data on wrong password. I'd rather not mess with the "Salted__" prefix on my own or, god forbid, roll my own crypto. Could anyone give me some pointers? Searching on duckduckgo for "random looking encryption" gives a bunch of results about random number generation
.
. However I think this could be a good place to ask before trying other more encryption-oriented places.I'm currently encrypting things on several layers. On the individual file layer, I use openssl:
Code:
$ echo foo |openssl aes-256-cbc -salt -a
enter aes-256-cbc encryption password:
Verifying - enter aes-256-cbc encryption password:
U2FsdGVkX19lqSi+Z8UoUmfnUqX7QJf+vQwwlyQ0tL4=
The problem I see with this, is that it's obviously encrypted. If we remove the "-a" parameter to openssl and run the output through an hexdump, we can see it:
Code:
$ echo foo |openssl aes-256-cbc -salt |xxd
enter aes-256-cbc encryption password:
Verifying - enter aes-256-cbc encryption password:
0000000: 5361 6c74 6564 5f5f 237d 34c9 d818 28d6 Salted__#}4...(.
0000010: 37f6 db75 cb87 bb5f e689 fd06 9d54 bf8b 7..u..._.....T..
Another issue with this is that, by trying to decrypt, we get an error when the password is incorrect but a good result then the password matches:
Code:
$ echo 'U2FsdGVkX19lqSi+Z8UoUmfnUqX7QJf+vQwwlyQ0tL4=' |openssl aes-256-cbc -salt -a -d
enter aes-256-cbc decryption password:
bad decrypt
140357412120232:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:539:
$ echo 'U2FsdGVkX19lqSi+Z8UoUmfnUqX7QJf+vQwwlyQ0tL4=' |openssl aes-256-cbc -salt -a -d
enter aes-256-cbc decryption password:
foo
I'd like to use an encryption algorithm that produced random-looking output without any kind of prefix like openssl's "Salted__". When trying to decrypt, it should always succeed, but return bogus data on wrong password. I'd rather not mess with the "Salted__" prefix on my own or, god forbid, roll my own crypto. Could anyone give me some pointers? Searching on duckduckgo for "random looking encryption" gives a bunch of results about random number generation
. Jump to: