Substitution and encoding are quite different from encryption Shadowself.
The above text substituted by rot13:
Fhofgvghgvba naq rapbqvat ner dhvgr qvssrerag sebz rapelcgvba Funqbjfrys.
It may be properly encrypted with the following command line:
Code:
echo 'Substitution and encoding are quite different from encryption Shadowself.' | openssl enc -aes128 -e -k Shadowself -a
we get
Code:
U2FsdGVkX1/KTlLL3p3dIXeXQ44gcA/BpEABeEQra9IGfqTWc34I6XsEL923Li6f
koPM+Mk2JgtqV0qD9FW5BtKPSEuVBoRbohZfnFYYb7ibsoVoS9AxC5SjAFujckwK
We are using the aes128 encryption algorithm with the password "Shadowself" and encrypted output is base64 encoded. It is impossible to represent binary data output from aes128 cipher in this post without a text representation. So binary data needs to be hex, base32 or base64 encoded, something normal when character based medium is required for the final representation/rendering of binary data.
You an decrypt the output with the following command.
Code:
echo 'U2FsdGVkX1/KTlLL3p3dIXeXQ44gcA/BpEABeEQra9IGfqTWc34I6XsEL923Li6f
koPM+Mk2JgtqV0qD9FW5BtKPSEuVBoRbohZfnFYYb7ibsoVoS9AxC5SjAFujckwK' | openssl enc -aes128 -d -k Shadowself -a
To examine possible watermark attack possibilities with aes128 let's encrypt a 128 character string of space characters. With a defined salt value 0:
Code:
echo ' ' | openssl enc -aes128 -e -k Shadowself -a -S 0
Code:
U2FsdGVkX18AAAAAAAAAADUuzFK+PvZ+2jG8AeNJTVGAbFHNpgJihHHCkSAFKZPr
OEivCe0FT4sWdu/v0ENGp/ZPaF1wd1GiEaDfm3rqxEhsO7rpBNv5iCskls4KrBHL
2Aql/u2pHLbmBNkWvEKJXc9EZKpiV2o/D62Wl8pTCojzUaTxgkUb1/KMoKp+JSPV
IBJDEMlGTqzX+S8DTwsc2A==
As part of our watermark test, we will subsitute the letter A for the first character.
Code:
echo 'A ' | openssl enc -aes128 -e -k Shadowself -a -S 0
Code:
U2FsdGVkX18AAAAAAAAAAN6Y6HvVrFfCtCgmsoAnvYMyI73RuihKB7dWrFXy5NBe
gUn7TpFw3QE9sWAJhITg9zHNtBxTnelupyLXr/RlPSNvtPnELfjd/fC4l1FQG3FF
C5xKeoD1YaWDx8c7Il1uBxGsBO5Qp7OWVZkXMy/lvDEObaNHmSpJWQYlIoIaOQUB
BAvdX9XDwz7iXGoGfS3DKQ==
And then the second character...
Code:
echo ' A ' | openssl enc -aes128 -e -k Shadowself -a -S 0
Code:
U2FsdGVkX18AAAAAAAAAAMsr/WMQmLSrcuZFid5vZYznrpaO5Udu4o/qXHedu/jw
guLoHu9zwp9j9Hk05v4rzUmNgNFRhfids9ANP0kiKuZIfvbbuYvawBPhP1qR8pw4
CXqh1fdux3cVX8OLXMU5xsxWTV4Ms2Iu5LuzrmnGmVnp5M3BFzur4DEKDV4mDzVy
hi6l+eGE1PlzZP9T2KxF8A==
As you can see, shifting the data one character results in all data elements after the data "header" to be altered. There is no indication that the input data being encrypted was so similar, rather, one cannot deduce much about the original data much less whether or not watermark data exists. Perhaps we may only be able to deduce that input data was "small" or 128 characters.
If you do not pass the -S 0 parameter defining the random number generator "salt" value, one would see completely different encrypted data even when encrypting the same data. The salt value would be encoded in the "header" and perhaps retrievable. But even with the salt data known (as in my example above) aes128 does not appear to be very vulnerable to a watermark attack.
You can see that encryption is way more sophisticated than character or phrase translations or substitutions.
The above image, if the 3 representations are very common, they would serve as a means to compress, abbreviate or contract the expanded data representation by substituting it with a form that has fewer glyphs. In the english language this type of construction is common in both written and spoken phrases.
can not => can't
they will => they'll
of the clock => o'clock
corporation => corp.
mister => mr.
incorporated => inc.
copyright => ©
We have many area specific substitutions.
Deoxyribonucleic acid => DNA
internal combustion engine => ICE
And with the modern day of the internet where everyone is trying to type less:
Be right back => BRB
Oh my god => OMG
laugh my a55 off => LMAO
The list goes on and on; so to suppose you have encryption is way more specific than contracted or abbreviated expression. Way more than character substitutions (rot13), or data encoding (binary vs base64).
If you really mean examine your information as encrypted data:
The first step would be transpose the information in the image into a format that is more easily manipulated by a computer.
Whether you interpret the glyphs to be characters (phonetics) or words/ideas you will need a mapping from those character representations to a binary representation since that is what our computers manipulate.
If you establish another system of manipulation that is not based on binary manipulations, then the rules of that system must be completely defined. This hypothesis suggests that either the information systems from the future that encoded/encrypted your data is not binary, but perhaps based on some future google defined word vectoring fundamental, or that the data is not from the a future where our computing architecture was functional and accessible.
Reply With Quote
Originally posted by lcam88
Bookmarks