FW: First Attempt at Crypto Library

[David Roundy]

On Tue, Apr 22, 2003 at 12:15:41PM +0100, Malcolm Wallace wrote:
> I concur that Codec is a better name than FileFormat.  It is more
> general, since the encodings may in fact never be stored in files -
> they could just be transmitted directly to a decoder over a network
> for instance.

Me too.

> > If FileFormat became Codec, then the existing FileFormat.Encoding looks
> > a bit odd.  But moving FileFormat.Encoding.Base64 up to Codec.Base64
> > (similarly for FileFormat.Encoding.Yenc) would seem to make sense.
> 
> Since we already have a little hierarchy based on the codec's purpose:
>     Codec.Image			(e.g. Codec.Image.Jpeg)
>     Codec.Video			(e.g. Codec.Video.Mpeg2)
> then how about adding
>     Codec.Text			(e.g. Codec.Text.Base64)
> because its role, like uuencoding, is to convert binary streams to
> 7-bit ASCII text i.e. transmissible by email.

I would have thought Codec.Binary.Base64, since in the other cases (Image
and Video), the name is for the content you wish to code, not the format in
which it is encoded.  e.g. Jpeg is a format for encoding an image in
binary, while xpm is a format for encoding an image as text, but both would
go under Codec.Image.

> A codec that is truly multi-purposed would sit directly under Codec,
> but I can't immediately think of an example that might fit.

gzip? Although that would probably go under Compression or something.

> > Question 2: what should the insides of the FileFormat.Encryption (or
> > Codec.Encryption) hierarchy look like?
> 
> I would have thought that its population would look something like:
> 
>     Codec.Encryption.DES
>     Codec.Encryption.RSA
>     Codec.Encryption.Blowfish
> 
> etc.  No need for any deeper structure.  Any attempt to further
> classify crypto schemes by method or purpose would be confusing I
> think.  Crypto is just crypto, i.e. binary to binary.

I would imagine you'd want a Codec.Encryption.PublicKey and
Codec.Encryption.Symmetric, since public key encryption supports a
different set of operations from simple symmetric ciphers.  I'd think that
all symmetric encryption could use a common interface of some sort, but and
perhaps all PK encryption could do the same, and it would be nice to
reflect this in the hierarchy.  Then you'd probably also want a
Codec.Encryption.Hash for cryptographic hashes.  I'd think you'd also want
to create somewhere a module for converting a passphrase into a key of an
arbitrary number of characters (which would probably be used by all the
symmetric ciphers if they want to use a common interface), but here I'm
revealing my ignorance of cryptography, since I don't know what such a
thing is called.  Some sort of variable-sized hash I guess...
-- 
David Roundy
http://www.abridgegame.org