Re: Barcode Email

From: Ari Silversteinn (abcarisilverstein_at_yahoo.comxyz)
Date: 07/30/05 

Date: Fri, 29 Jul 2005 18:56:07 -0400

On Fri, 29 Jul 2005 14:19:48 +0000 (UTC), Walter Roberson wrote:

> You are starting with an octet stream, and you are applying a
> consistant transformation [with no extra input] to produce
> a new octet stream. You then represent that as barcodes, but
> that's irrelevant when considering the security or mathematical
> properties.
>
> No matter how many steps you take to do it, all you are doing
> is applying a hash function. [If the size of the output is the
> same as the size of the input, then it is a "perfect hash"].
>
> Is a "bizzare and unorthodox" hash function more difficult to
> reverse than a "simple and orthodox" one? Not necessarily.
> Especially not when one has access to the binary implementing the
> [fixed] algorithm.

All of what you have said is true, only parts of it apply however to The
Program.
 
> -Typically-, what "bizarre and unorthodox" gains you that simple and
> orthodox does not have, is implementation and logic mistakes, logic
> errors that might, for example lead to two different messages
> encoding to the same output.

Sure can, hasn't happened yet.

 
> You have indicated that you can reliably get about 8000 characters
> encoded into a single PDF417 symbol. A PDF417 symbol is restricted to
> 30 rows by 90 columns, *including* the Reed- Solomon error-correction
> code words. 30 * 90 is 2700, so your statements imply that you are
> consistantly getting 3:1 compression.

Compression is not used, technically.

>Your statements indicating that
> people could encrypt the data before putting it through The Program
> imply that you expect to be able to continue to get that 3:1
> compression even on octet streams that have very different
> frequency distributions than English text. If the input is uniformly
> randomly chosen from 95 printable ASCII characters plus newline,
> your long-term compression factor can be no better than about 0.823
> (e.g., 823 full-range octets required to store 1000 restricted-range
> input octets.) This suggests to me that your compressive operations
> are either broken or that you have not accurately stated the
> actual capacities of your proposed Program.

No compression, all is accurate. 

-- 
Drop the alphabet for email

Relevant Pages

  • Re: Barcode Email
    ... Bizarre and unorthodox simply do not matter in this context. ... a new octet stream. ... Is a "bizzare and unorthodox" hash function more difficult to ... consistantly getting 3:1 compression. ...
    (comp.security.misc)
  • Re: Barcode Email
    ... Bizarre and unorthodox simply do not matter in this context. ... a new octet stream. ... Is a "bizzare and unorthodox" hash function more difficult to ... consistantly getting 3:1 compression. ...
    (sci.crypt)
  • Re: Barcode Email
    ... > a new octet stream. ... Compression is not used, technically. ... > input octets.) ... > actual capacities of your proposed Program. ...
    (comp.security.misc)
Quantcast