States and the 8 bit dilemma

• Messages sorted by: [ date ][ thread ][ subject ][ author ]
• Previous message: Laurence Lundblade: "Re: the 8-bit dilemma"

Derek RIP (rites in part)
>	1) I am sending a complete multimedia message and I want to
>sign the whole shabang.  In this case the best way to do it is to
>format the message and sign the whole MIME content (c.f.
>multipart/signed).  This is message security.  I want the recipient to
>be able to verify that this is the message that I intended to send.
>Complete.

Understand. What we want as an endstate is to be able to sent a multi-element
image that can be verified either as the complete image or as any individual
part, or for the whole thing.

I have been doing something similar: ZIP a group of files. Do a pkunzip -v
piped to a list file. Sign *that* (includes a CRC32 of each element). Add
to ZIP file. Not perfect and manual but accomplishes the same thing.

What we really want to do is to create a mechanism whereby such authentication
is added by default and on-the-fly which also allows extraction/verification/
execution in one movement that only requires user intervention if something
is wrong/missing.

Biggest change required is from "sign whatever I want" to "sign everything
unless I say no".

For today I suspect that the need is for something that can be signed/verified
without having to go completely off-line and which may be omitted by either
end without losing functionality.

The 8 bit issue would seem to be something else. For E-mail that would seem 
to be "less than 80 character lines made up of that subset of ASCII which
is expressed in Bytes ranging from 20h to 7Eh and which are insensitive to
line terminators. SGML restricts this further with restrictions on certain
characters (such as the double quote - 22h, and ampersand - 26h). We will
not go into the vagaries of EBCDIC.

Any number of mechanisms exist for performing this transformation. The 
simplest require a 2:1 expansion with each transmitted byte actually carrying
a nibble of information. Better means such as UUencode result in about a
3:2 ratio plus add error correction. For formatted text, MIME works well
though is a kludge much like the shift character used to send numbers with
the 5-bit Baudot code. Since the kludge is not needed often, it works well. 

Binary or properly encrypted files are a different proposition. Instead of
being rare, the kludge would be needed greater than 50% of the time and would
become inefficient.

One of the nice things about PGP is that it combines the ASCIIzation process
with LZ compression so that even through encrypted and ASCIIzed, often the
resultant file is shorter than the original plaintext. Since this is done
with a single invocation, it is easy. Since the process is compress->
encrypt->ASCIIze, it is efficient. Doing so with a previously compressed
file could become unwieldy.

When we talk about multimedia, most of the elements range from not-very-
compressable (GIFs) to pretty compressible (text) to highly compressible 
(JPEGs). When considering total bandwidth, this is important. The prime
factor is that both compression and encryption stages result in a container 
that is highly random. Therefore, an ASCIIrizer transport mechanism to be
efficient, should not use MIME which is optimized for formatted text, but 
rather something optimized for use with random binary.

				Just some thoughts,
						Padgett 

• Previous message: Laurence Lundblade: "Re: the 8-bit dilemma"