There is this one guy controlling every aspect of it, hiding his precious source code until he deems it ready for another release, and generally being way too slow at moderating blog comments, let alone answering emails or fixing bugs.
If this was a small pet project nobody used, that wouldn’t be so bad. But our little encryption framework is actually getting used in quite a few cool projects. So something has to improve here.
The controlling guy is going to stick around, but we’re not going to let him be a choke point anymore.

In concrete terms, this means:

• The As3Crypto project is now hosted on google code at https://code.google.com/p/as3crypto/
• The As3Crypto project has a public discussion list at https://groups.google.com/group/as3crypto

For developers, this means:

• The public subversion repository will be used consistently for all development work
• Radical library changes should be documented in wiki pages, preferably before the changes happen
• Use the mailing list to let folks know what you’re working on.

For users, this means:

• You can use the “issues” tab in the project site to report bugs (much better alternative than blog comments)
• You can use the mailing list to follow what’s happening, and help fellow users figure out how to do things.

I encourage everyone with an interest in this library to join the mailing list now.

More recently, when the Flash Player 10 beta came out, I ended up wishing I could do the same thing: Browse through the APIs and try whatever new stuff was hiding there. So I’ve ported my original Java Explorer into a Flash Explorer.

Just like the original, it only works on Gecko-based browsers, although that could be fixed given a bit of effort.

As an aside, this includes an early version of a 2-way bridge between Flash and Javascript, which will totally kick ass when it’s done.

One final thought regarding ScreamingDonkey. As part of ScreamingDonkey, I’ve been trying pretty hard to make the browser DOM available to ESC-compiled scripts, but there’s actually some demand for fully isolated scripting containers. In a presentation last November, Douglas Crockford calls those containers “vat”, and thinks they can help provide secure mashups. Anyway, it would be pretty easy to take ESC, wrap it into a little “vat” mechanism and ponder the security value of the resulting product.

So here is ScreamingDonkey. Not to be confused with ScreamingMonkey, a serious project done by the good folks at Mozilla. The names are similar, because the projects goals are similar, and they use some of the same underlying technologies: the tamarin VM and the ESC self-hosting compiler.
In both projects, the goal is to bring Ecmascript 4 scripting to a browser near you.

ScreamingMonkey relies on a locally installed ActiveX control packaging Tamarin and some browser glue. In contrast, ScreamingDonkey relies on a locally installed Flash Player that includes Tamarin and some browser glue.
More seriously, ScreamingMonkey is gluing Tamarin and the browser at a low level, bypassing sandbox or language limitations. Also, ScreamingMonkey’s version of Tamarin could be customized, and the compilation of scripts could be handled by a SpiderMonkey derivative, which would be likely to be faster than ESC.
ScreamingDonkey doesn’t have any of these luxuries. We do have the ESC self-hosting compiler, packaged to run within a flash movie. We also have a layer of glue that transparently exposes browser objects to the flash player. It gets us pretty close.

Anyway, check out the ScreamingDonkey project page. There’s also a test demo that should look familiar yet different, and for Firefox folks, a little spin on John Resig’s processing.js project.

Interestingly, the evalui demo is a fun way to tweak ESC and see the results in real time: Edit one of the .es source files, paste the modified version in the input area and run it. The next compilation will start using the modifications you just made.
That’s a rather powerful demonstration of the self-hosting nature of ESC.

Anyway, give it a whirl. I’ve finally included the es4eval.swc file too. I’ve another little project that builds on this stuff that I’ll blog about soon.

My apologies to folks reporting bugs or asking for advice. Your pleas are not lost on me, and I’ll make a point to fix the known bugs, and generally try to be a wee bit more helpful.

As much as it itches me, I’ll try hard not to start some new project yet, at least not until I feel better about the state of the existing stuff.

Anyway, here’s my tentative TODO list for now:

• isSigned() chokes on a certificate served for www.openssl.org. That’s probably a clue my ASN-1 parsing sucks. I have an incomplete but potentially much better parsing method for ASN-1 (based on *gasp* actually reading a spec), so that might be the way to go there.
• There’s something rotten in my BigInteger implementation, which seems to result in RSA key lengths being occasionally off.
• Fix some TLS bugs (Andy’s parsing bugs, at least)
• Implement some missing bits of TLS (to at least get https://api.del.icio.us/v1/tags/get to load.)
• Check RSAKeyTest::testPem2(), since it might be broken.
• Update the Eval library with a recent tamarin dump, and fix the newline problem in the test app.

If I’m missing something in that list, feel free to remind me.

So here’s JSObject. Yes, same name. In fact, it behaves remarkably similarly like its Java counterpart: Get a handle to the browser window, and climb up the DOM from there. However, it distinguishes itself by its transparent syntax.
To the untrained eye, it looks like your javascript objects have been carried over inside the Flash player.
For example, you can do this with it:

[code lang=”actionscript”]
with (JSObject.getWindow()) {
e = document.getElementById(”test”);
b = document.createElement(”button”);
b.innerHTML = “Click me!”;
b.onclick = function(e:*):void {
alert(”clicked on “+this+” at “+e.clientX+”,”+e.clientY);
};
document.body.insertBefore(b,e);
}
[/code]
Except for the typing of the function parameter and return value, there is no difference between this and browser javascript code.
Even neater, if you put a breakpoint inside that code, you can browse through JSObject instances and effectively walk your browser DOM through the flash debugger.
There’s a lame demo that uses the above example.. You should probably browse the source view, though.
At the risk of giving away the ending, this is done by coupling flash.utils.Proxy with ExternalInterface, with a fair amount of javascript glue on the browser side.
It has various performance limitations, but hopefully that can be minimized over time.

Also, I’ve added another compiler to the as3 eval() project. This one is just a straight linkage of the ESC abc files, as made available through the tamarin-central repository. It works, but it’s not particularly more interesting than the AS3 version, for now. However, as time goes by, and the ESC stuff improves, it will be a cheap way to see those improvements in a pretty web UI, without some codemonkey having to port the darn thing over and over again.

Well that’s it for now. Eval and JSObject.. I wonder where I’m going with this.

Long story short, I’ve ported that stuff into an as3 library. It’s not done, and won’t be done until the es4 self-compiler itself is done.
It works though, whenever it doesn’t crash. You can try it here.
It has a lot of potential too. Let me count the ways:

• Dynamically compiled code within the flash player. eval() is possibly the most misused command in JS, but you can do some really neat stuff with it. Plus, the flash VM lets you segregate code rather well, so you can eval() code without chancing a clobber of your existing code. With a bit more investigation, it might even be possible to run untrusted code safely. Maybe.
• Letting web apps accelerate themselves by eval()-ing themselves in the flash VM. It’d require proxying the browser DOM through ExternalInterface and the Proxy class, which might negate some of the speed benefits. Still, it could probably beat up every other implementation on a SunSpider benchmark, and take their lunch money too.
• A poor man’s ScreamingMonkey. If esc ever gets to support the full set of ES4 proposals, then every non-ES4 browser out there that already has Flash could suddenly run ES4. That’s a nifty thought right there.

Anyway, that’s a way off. For now, I’ll try and backport esc updates on a semi-regular basis.

Also, crypto people, I haven’t forgotten you. I’ll put a better ASN-1 parser and a bunch of contributed bug fixes out soon.

Oh, and happy new year!

This has various implications, one of which is one could someday interface their as3 code directly with a library like openSSL.

Anyway, it’s neat, and so I’m kinda starting on a quest to figure out how it’s done. So far, I can see 2 big chunks to this:

1. map those bytecodes to those bytecodes.
2. put together an actionscript runtime that lets C code feel at home. That includes reconciling the asynchronousness of as3 with the synchronousness of a C program. Also things like arbitrary pointer arithmetic would need to be handled.

Beside this crazy but fun exploration, I’m also reading some specs on ASN.1 and such, so it’s possible as3crypto might sprout a ASN.1 parser that doesn’t suck.
Part of the fun here is mapping the ASN.1 type notation to something very similar-looking, yet valid as AS3 code. The other part is having a DER parser that doesn’t think typing is optional or fuzzy.

Nothing, that is, until Marcos Boyington over at Yuniti ported the RSA logic to AS2.

Now technically, the RSA stuff in As3Crypto was directly lifted from JSBN , therefore porting it to AS2 is pretty much equivalent to porting JSBN straight to AS2.
Still, Marcos was nice enough to give my library some props.
Anyway, go check out his As2 RSA library if ActionScript 2 is your thing.

In spite of my previous post, I didn’t feel right releasing something that didn’t have a shot at protecting against Man-in-the-middle attacks, so I took a few more days to implement some X.509 certificate parsing and validating.
This release ships with a number of well-known Certificate Authorities, so you should be able to use the lib to connect to public TLS-enabled services easily.

The easiest way to get started is with TLSSocket. Check out TLSTest.as for some sample code using it.

As an aside, RSAKey.as now has sign/verify methods, which get used by X509Certificate.as.

I reverted a change I talked about in the last post, namely the existence of some odd “rc4block” cipher. It’s not needed, so it’s gone.

Here are the release notes for this version:

- TLS: partial TLS 1.0 support (RSA only), with TLSSocket and STARTTLS support.
- cert: Basic X509 (v1 and v2) Certificate parsing and validation
- cert: Builtin Root CAs, ripped from Mozilla. (see MozillaRootCertificates.as)
- DER: bug fix in parsing of UTCTime
- DER: limited support for outputing ASN-1 structures as DER (as little as needed for X509 cert. signing to work.)
- RSA: support for RSA signing/verifying (needed for TLS cert validation)
- hash: MD5 and MD2 classes no longer alter their source data
- secret key: RC4 doesn’t reset its state before every encrypt/decrypt operation anymore.
If you need that behavior, you need to use .init(key) before each call.

So where do we go from here? Well, that’s a whole lot of new code, so expect a release or two dedicated to stabilizing the code base. I’m also falling behind on my test coverage, and I don’t even have a demo UI to showcase TLS.

That should keep me busy for a little while.

By the way, if you guys are using this library in some public project, please write a quick comment with a URL to your project.
I’d like to keep a list of projects somewhere on the site.