On May 5, 2007, at 1:26 PM, Hans-Martin Mosner wrote:

Hi Rob,

Robert Withers schrieb:

...

Hey Hans,

I just read the OpenPGP spec and browsed your code. You are close to processing packets! Are you still developing this package? Let's revive it.

Well I haven't been doing anything on it for quite some time. I think the code is mostly able to read public and private key files. I never decided on a good abstraction for reading and writing encrypted files, though, so that part would need some design work.

Ok, I see where you are reading in the public and private keys. I would need to be able to generate them as well, since I don't have an OpenPGP/GPG installation. then we could come up with a default location fo these files in the squeak default directory. For SMIME, I keep all of the certificates and private key in a CertificateStore object, which is serialized to disk as 'certificates/cert.store'. Perhaps we need a 'security/pgpkeys.private' and 'security/ pgpkeys.public'. I could move 'certificates' under 'security'.

...

I recently finished implementing SMIME, although it has yet to be integrated with Celeste. I think it's possible to have both SMIME and OpenPGP support in Celeste, when we get around to it.

What do you think?

That would be a very good idea. My main motivation for OpenPGP was that it could be used in code signing (back when I tinkered with my distributed code repository stuff) but its use in a mail client is definitely a good goal.

Ah, yes I recall you were working on that. Lots of choices now with Monticello, Universes, packages, none with code signing. Perhaps the mail client would be a good entry point for broader use.

Do you happen to have an idea for a good abstraction for encrypted/signed files and streams?

Not really. It seems to me that there is an input stream (chunk), with ancillary input state (public/private/session keys), which would decode to an output stream (chunk).

Decryption failure is an exception as is signature verification failure. We could then use a chain of responsibility of decoders. I.e. the first attempt to verify the signature may fail/throw an exception, shifting to a second decoder which would extract the message without verifying the signature. A higher level would be responsible for reporting the outcome, based on which decoder was successful. A decoder (encoder) could be composite, so we could handle/generate encrypted, signed packets.

I suspect all of this is above the layer you are talking about, which is the internals of processing a single packet. For that I think of the ASN.1 framework I implemented with help from VW. There is a ASN1Stream holding BER encoded bytes, and you use a Type class to control how to read or write those bytes. So there is an OpenPGPStream holding encoded bytes, and you use a Type (Packet) to control how to read or write those bytes. This is what you have, is it not?

What kinds of abstractions were you thinking over?

cheers, Robert