FW: First Attempt at Crypto Library

Matthew Donadio m.p.donadio@ieee.org
Wed, 23 Apr 2003 21:26:30 -0400


Andrew J Bromage wrote:
> This table may help clarify the thinking:
> 
>                         | Algorithm     | Codec         | Format
>         ----------------+---------------+---------------+----------------
>          Cipher         | DES           | CBC-DES       | SSL
>          MAC            | SHA-1         | HMAC-SHA-96   | SNMPv3
>          Text compress  | LZ77          | Deflate       | GZip
>          Image compress | DCT           | JPEG          | JFIF

These algorithms are all normative.  All compliant encoders and decoders
produce the same output for the same input (they are true functions with
inverses).

How would you handle something like the MPEG audio and visual specs
which only specify the bitstream, and not the actual algorithm?  For
example, two MPEG encoders with the same set of parameters can produce
two totally different, yet compliant, bitstreams.  Decoders, on the
other hand, basically produce the same output for the same input (there
is allowance for different roundoff/truncation strategies).

MPEG is also complicated by the various layers, so there are multiple
formats.  For example, an MPEG program (a group of audio and video
streams) can be stuffed into a program stream (DVD's do this) or a
transport stream (digital TV via ATSC or DVB).

AVI and QuickTime formats also a have a similar issue, where they really
specify a file format, and you can use a variety of codecs in them.

This may not be a problem, but it is something to consider.

-- 
Matthew Donadio (m.p.donadio@ieee.org)