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
_______________________________________________
Cryptography mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
Locked
smime.p7s (3K)