|
Re: How to tell if something is encrypted
by arhuman (Vicar) on Apr 18, 2001 at 19:08 UTC
|
If you have the key, trying to decrypt it is THE solution ;-)
Otherwise a compression test may be a quick (but bad) solution depending on the data being transmitted.
(quite efficient if you transmit text, or other redundant informations)
If you can't save space by compressing it :
It's probably that it's
- Already compressed
- Encrypted
"Only Bad Coders Badly Code In Perl" (OBC2IP)
| [reply] |
Re: How to tell if something is encrypted
by kal (Hermit) on Apr 18, 2001 at 19:43 UTC
|
You can do something a bit like the way passwords are stored in LDAP servers - write out the parameter as <input type="hidden" name="foo" value="{blowfish}As92Kd..">. Then, just check $val with a regex...
my $string = "Hello";
if ($enc) {
print '{blowfish}', encrypt_string ($string);
} else {
print "{unencrypted}$string";
}
....
my $val = $q->param ('foo');
my $actual_val;
if ($val =~ /^{([a-z]+)}(.*)$/) {
if ($1 eq 'blowfish') {
$actual_val = decrypt ($2);
} else {
$actual_val = $2;
} else {
$actual_val = $val; # didn't match - old-style param?
}
That way, you should be able to re-write the bits you need to take encryption, without breaking the old-style way of doing things, unless {something} appears in your params :) | [reply]
[d/l]
[select] |
|
|
This is almost exactly the idea that I have been playing with. I was however hoping for a method that would avoid picking an "arbitrary" string. I too believe that, given a sufficiently "weird" string, this method is unlikely to cause a false positive on the encryption question.
As a note: I actually have written an extension to CGI.pm to make the param() method perform the decryption where appropriate. That means the coders do not have to alter anything to decrypt() the information.
Thank you all for your suggestions.
| [reply] |
Re: How to tell if something is encrypted
by diskcrash (Hermit) on Apr 18, 2001 at 20:00 UTC
|
This may be somewhat lame, but practical. Assuming your unencrypted text is mainly ASCII, it would be unlikely to contain many byte codes under x1F. Presumably encryption would drive the bytes all over the 0-FF map. So if it contained a significant number of bytes below 1F, it's encrypted or compressed.
-diskcrash | [reply] |
|
|
If the file were an uncompressed binary, it would likely have a proportionally high number of 0x00 characters. If the file were a compressed file, it would have a proportionally high number of 0x00 characters near the beginning of the file, but not so much in the remainder of the file. If the file is encrypted, there is unlikely to be a high proportion of 0x00 characters.
| [reply] |
|
|
A compression mechanism that always results in a non-uniform distribution of 0-bytes within the output isn't doing the best compression it could.
Well-compressed output, well-encrypted output, and random output should all be indistinguishable.
-
tye
(but my friends call me "Tye")
| [reply] |
|
|
|
|
|
|
|
A polyalphabetic substitution cipher is a form of encryption, and could obviously remain in the set of printable characters. Of course, no one would use such a simple cipher :) Also, Encrypted text could be "ASCII armored" ala Base64 or some other coding scheme, which would change the alignment of the data to be ASCII printable, but nonetheless the data is encrypted.
| [reply] |
Re: How to tell if something is encrypted
by Beatnik (Parson) on Apr 18, 2001 at 19:57 UTC
|
well basically there is NO 100% way of telling if "ABCDEFGHIJKLMNOPQRSTUVWXYZ" is encrypted or not... You can only assume it isnt, but what if it is? :)
Greetz
Beatnik
... Quidquid perl dictum sit, altum viditur. | [reply] |
Re: How to tell if something is encrypted
by derby (Abbot) on Apr 18, 2001 at 21:32 UTC
|
Well the quickest way with no code changes would
be to move it to a secure server; otherwise I'm
afraid your quick changes will not be secure (how are you
going to sync up the secret keys between server and
client?). | [reply] |
|
|
Hi,
We are running on a secure server, but that only protects the information during transfer from client to server. The pages which are delivered however ocassionally require sensitive information to be passed via HIDDEN inputs or worse yet HREF links.
There is no client side secret key required in this case. The server side is the only place encryption/decryption is occuring. Also, the keys used are linked to sessions as well as time-sensitive -- as an additional precaution.
I know that this is not ultra-secure, but I am not protecting Fort Knox -- just trying to disuade nosey people.
Later and thanks all,
Sifmole
| [reply] |