I'm not familiar with AIR, but that's great if it has some kind of internal encryption mechanism.
I don't think there is any way you can safely encrypt a swf that can be somehow playable in the browser, however, since there is no secure way to deliver the key. My only point, really, is that, until there is some easy way to flip a switch and safely encrypt your swf, then these encryption methods that you are describing are not a substitute for obfuscation, if obfuscation is your only goal. -austin -- Austin Haas Pet Tomato, Inc. http://pettomato.com On Wed Jun 04 18:11 , zwetan wrote: > > > > I see. I don't think that would be a suitable alternative to obfuscation. > > > > For one thing, it requires a great deal more effort. Second, it puts the > > burden on the client to run the decryption on their machine (every time > > they access the swf). Finally, since you must provide the client with the > > key, you haven't really protected anything, you've just added one extra > > step. > > > > effective solution require effort in general > > you can protect the key too > simple example: if the SWF run within AIR you can use the encrypted storage > to save the key but without exposing it in the source code that could > be generated from decompilation > but yes you're right is much more difficult to put in place, > hence why you see very few people doing it right > > it's not just an extra step that is useless, with encryption done right > you can have your encryption algorithm source code exposed on the wild > and your crypted file still stays secure > > the only thing I was saying is that depending on your use case > obfuscation is not the end-all be-all , encryption is there too, > as steganography, etc. > > zwetan > > _______________________________________________ > osflash mailing list > [email protected] > http://osflash.org/mailman/listinfo/osflash_osflash.org > _______________________________________________ osflash mailing list [email protected] http://osflash.org/mailman/listinfo/osflash_osflash.org
