Because I had a need for it, I started putting together the beginnings of a Fantom crypto pod. I've only implemented a DigestInStream for the moment, but it'll be trivial to implement a corresponding OutStream as well.

Check the code at http://bitbucket.org/liamstask/fantomcrypto

If it's interesting to use this as the basis of a crypto pod that ships with the Fantom distro, that'd be swell. I haven't put any licensing info on it for now, so feel free to grab it and add some.

One API question I thought I'd ask for some feedback on is whether DigestInStream (and OutStream for that matter) should be exposed directly, or if there should simply be a Digest class that provides the appropriate in() and out() methods to add data to the digest. That seems like it might be nicer, now that I'm actually typing it...

A filtering stream in the original implementation is quite flexible - you can compute hashcodes as you read the input stream (via callbacks on some Digest class) and you don't have to discard it. If I'm not mistaken this is not possible in your current implementation...

Nice work!

I'd say the biggest design issue, is whether DigestInStream should actually subclass InStream. I think it should, but I'm not sure we all the hooks in there to make it work efficiently. I guess that is what you were trying to do with that other posting.

Yeah - the way it's currently implemented, it's a little bit misleading to call it DigestInStream :) And yes, this was what I was poking around at with that other pesky post. If the machinery to subclass InStream were in place, that might be the simplest approach. Otherwise, returning a DigestInStream as an InStream via Digest.in() (assuming a new Digest class) also seems coherent. That way we wouldn't need to worry about subclassing InStream, since we'd just be wrapping SysInStream.

@katox - there's no reason not to expose more of those kinds of possibilities in this scheme, I suppose. This is just what came out first, and I thought I'd keep it as simple as possible. Please feel free to clone and submit a pull request :)

Otherwise, returning a DigestInStream as an InStream via Digest.in() (assuming a new Digest class) also seems coherent.

That that might work pretty well. I think we need to figure out the right pattern here to use for the entire crypto API. We'll have SSL, other encryption streams, etc.

Do you have even a rough outline of classes/APIs in mind for any of the rest of the crypto pod? If so, we could use that as a guideline for these first implementations...otherwise plodding along as we are is probably ok too :)

Do you have even a rough outline of classes/APIs in mind for any of the rest of the crypto pod?

All the basic functionality available in javax.crypto, maybe some other stuff:

• digest streams
• cipher streams (blowfish, AES, etc)
• SSL/TLS
• public/private keys

Figuring out how SSL hooks into inet and wisp is probably one of the key use cases.

I may have a need for SSL Sockets soon.

I've been learning the POP3 and IMAP email protocols over the weekend. I wanted to connect to my gmail account and do some analysis of my email. I have a fairly complete implementation of a POP3 client and a barebones implementation of an IMAP client.

When I'm done with what I'm using them for, I want to contribute them to the core for inclusion in the email pod.

One caveat, though. I don't think any email servers serve unencrypted requests any more. I've been using Java FFI to get at javax.net.ssl.SSLSocket, but it doesn't seem the best option to toss random FFI references into the core. It seems like it would be best for me to wait for native SSL.

I just wanted to give a heads up to whoever's working on crypto.

Yes, the need for SSL has hit me too regarding email (even SMTP requires SSL for gmail). Going to have to tackle it sooner or later. I definitely don't want to use FFI from email directly - should be wrapped in crypto pod.

Getting POP3 and IMAP APIs would be really nice. I started wrapping Java Mail, but that API is a total piece of crap. Luckily the email protocols are simple and pretty easy to implement.

As an aside, I use Gmail Backup to bulk copy emails to my PC - its worked well for me. It does the labels too.

Pop3 especially was a snap.

The hard part will be integrating the client API with the existing mime classes. That and exposing the API in a nice, sensical way.