Twan van der Schoot
Mon Jan 30 01:30:59 CET 2006
I've been confronted with the same problem as you; doing crypto in flash
actionscript in a big flash-base online game.
Although actionscript is a nice programming language it is not particular
well suited to implement cryptographical algorithms in it.
But as long you don't have to do authentication and a preshared key will do,
why don't you implement RC4? RC4 is in itself very fast and very easy to
this site, which, btw, also shows the implementation of several other crypto
algorithms in javascrip: http://www.fact-index.com/r/rc/rc4_cipher.html)
> -----Original Message-----
> [mailto:]On Behalf Of Samuel
> Sent: vrijdag 27 januari 2006 18:39
> To: Ryan Rawson
> Ryan Rawson wrote:
> >Why not just use HTTPS ? JS can easily do a HTTPS get, and I'm sure
> >(as an erlang newbie) there must be a https something or other for
> >On 1/26/06, Samuel Montgomery-Blinn <> wrote:
> >>compatible implementations with Erlang's crypt module? I'm having a
> >>from Blowfish, AES, etc. This is for encrypting/decrypting the TCP
> >>socket traffic between an AFLAX (aflax.org) socket (Flash ActionScript
> >>XMLSocket) and an Erlang tcp server.
> Because in this case there is not an HTTP stack speaking over the port.
> It is not a "pull" or "poll", which yes of course an HTTPS request would
> provide. This is a bidirectional nearly raw TCP socket connection from
> the Browser via Flash, going over TCP to a server listening on some
> port. The server can of course take input over the socket, but there
> would not be any real gain in that over using some standard AJAX calls
> which would yes of course be able to take advantage of simple HTTPS. But
> to push data to the client (say, multiple streams of stock updates,
> logs, chat windows) without using any HTTP pull/poll request, the server
> has these nearly raw TCP sockets which end up firing Shock events on the
> So to perform this without pull/poll of the HTTP/S request cycle, I need
> to be able to encrypt and sign a message at the server and push the data
> along the TCP pipe to the browser, which has to be able to decrypt and
> verify the received data.
More information about the erlang-questions