[SDL] Communication between 2 SDL programs (Security?)

[Donny Viszneki]

On Aug 28, 2004, at 8:15 PM, xm at ca.inter.net wrote:

>> yeah truly, but what i meant is for instance if you had critical data 
>> stored
>> in your surfaces, someone could hack up their own sdl lib from source 
>> that
>> would make it so whenever a surface was displayed, it would dump the 
>> data
>> from that surface to a file.
>>
>> Since the license garauntees that they should be able to relink your 
>> app to
>> sdl, theyd be able to circumvent your security this way.
>
> Well, that would meen that someone would have to make changes within 
> the computer
> either remotely or in front of it, and this falls outside the scope of 
> what I can
> ever do.

> If the information is very sensitive, then the client using such 
> program should
> have a network adminstrator capable of securing the network and should 
> have an
> alarm system or other devices to stop an intruder to do anything with 
> the computer.
> That is not my job.

> But, thanks I did not think about just changing the SDL lib itself to 
> hack a program...
> Actually, any dynamic libraries are subject to that kind of security 
> flaw...

I can't believe what you're saying. It's so ridiculous! It's just not 
logical thought at all!

Possibility #1: You want to create an application that uses encryption 
to prevent even the operating system kernel from getting at that 
information, it will require special hardware.

Possibility #2: You want to create an application that just secures 
data on a SECURE SYSTEM on a SECURE NETWORK (see your second paragraph) 
then this really isn't any different than using ORDINARY ENCRYPTION. 
You download the encrypted file, you decrypt it (on your secure 
system,) and you view it (on your secure system.) There! Security!

What other possibilities are there? You clearly aren't doing either one 
of these because one of them already exists and the other is largely a 
matter of hardware.

-----

That isn't the only contradiction of logic going on here (though 
admittedly, this is somewhat related to the above contradiction.)

Possibility #1: You are trying to create software that a client can 
download onto any public terminal and view encrypted documents with an 
expectation of security based on whether or not the system can be 
trusted.

Possibility #2: You are trying to create software that a client can run 
on machines he already trusts, which means he can just use ORDINARY 
ENCRYPTION. As before, you download the encrypted file, you decrypt it 
(on a trusted machine,) and you view it (on a trusted machine.)

Again, in paragraph #2, you forfeit your claim to protect data on an 
UNTRUSTED MACHINE. What use is your software then? On a TRUSTED MACHINE 
people already have a great deal of security using modern encryption.

-----

These were a bit redundant - but I can't believe I didn't get my point 
through already in previous emails! Call a doctor! There's something 
wrong with you!

-----

Paragraph 3 is total bullshit too! Dynamically linked libraries AREN'T 
a SECURITY FLAW! Any hacker of ANY ABILITY WHATSOEVER will NOT have 
been saved a great deal of time nor effort because the function names 
have been spelled out for him - this only helps a SCRIPT KIDDIE. Again 
I say!- if you think you're offering your "clients" ANY SECURITY AT ALL 
by basically saying to all the script kiddies out there "Look, my 
software is a bit too hard for you to crack now, but some time soon a 
good hacker will crack it and post his programs for doing so on the 
internet in windows executable form for you so you don't have to strain 
yourself," you've got another thing coming.

When I was in highschool for my LTP (long-term project) I wrote an 
encryption demonstration that discussed the history of cryptography and 
its practical applications, and showed the exact inner workings of a 
few really simple obfuscation algorithms (XOR comes to mind, but my 
algorithms weren't THAT simple.) It was great for a highschool project, 
and most script kiddies probably wouldn't have been able to crack them 
- BUT IF I SOLD IT TO SOMEONE SAYING IT WAS A SECURE WAY TO ENCRYPT 
THEIR DATA IT WOULD BE A BALD-FACED LIE.

> Thanks,
>
> xm
>
>
> _______________________________________________
> SDL mailing list
> SDL at libsdl.org
> http://www.libsdl.org/mailman/listinfo/sdl
>