[Cryptography Team] Re: OpenPGP

[Robert Withers]

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