If your encryption can be broken just because somebody has the source to your algorithm, then it's worthless already =) That's why we've got standard algorithms that rely on keys in the first place.
-J On Wed, May 21, 2008 at 2:25 PM, kenny14390 <[EMAIL PROTECTED]> wrote: > So the bottom line is to use an algorithm like RSA? To take a much > simpler example, if the Flex app receives the encrypted data "1234" > and it wishes to use that data, it must first decrypt it. So it > performs the decryption in some AS and now you have the decrypted data > that you wanted. My question now is, if someone decompiles your app > they can see your decryption method and thus decode the data on their > own. Nothing is private in the Flex app due to the decompilation concern. > > Regarding SSL, I suppose this is out of the question if we're talking > about a Facebook application. I don't have much control over their > security. > > > --- In flexcoders@yahoogroups.com <flexcoders%40yahoogroups.com>, > "andrewwestberg" > <[EMAIL PROTECTED]> wrote: > > > > I think you're confusing simple secret key encryption (DES, AES, > > etc..) with public/private key encryption (RSA). > > > > In secret-key encryption if an attacker steals the data and guesses or > > brute forces the secret key, they can see the data. > > > > In public/private key encryption, a message you send to the server is > > encrypted by a public key and can ONLY be decrypted by a private key > > known only to the webserver (the certificate you bought from verisign, > > thawte, etc...) This is how when you sign onto paypal or some other > > site over https, you don't have to worry about your credit-card being > > stolen in transmission. Sitting in some DB at the company where > > employees can get at it, you should worry, but during transmission, > > it's unlikely to get cracked. > > > > -Andrew > > > > > -- "Therefore, send not to know For whom the bell tolls. It tolls for thee." :: Josh 'G-Funk' McDonald :: 0437 221 380 :: [EMAIL PROTECTED]
