1997-10-14 - Re: Encyrption Program

Header Data

From: Benjamin Grosman <bgrosman@sydney.healey.com.au>
To: semprini@theschool.com
Message Hash: a6fbdb6071fd97d70ee63af8f0145fc08ddef1897be295554b6503831a50e836
Message ID: <Pine.LNX.3.93.971015085727.21930A-100000@sydney.healey.com.au>
Reply To: <199710141958.MAA22050@k2.brigadoon.com>
UTC Datetime: 1997-10-14 23:29:50 UTC
Raw Date: Wed, 15 Oct 1997 07:29:50 +0800

Raw message

From: Benjamin Grosman <bgrosman@sydney.healey.com.au>
Date: Wed, 15 Oct 1997 07:29:50 +0800
To: semprini@theschool.com
Subject: Re: Encyrption Program
In-Reply-To: <199710141958.MAA22050@k2.brigadoon.com>
Message-ID: <Pine.LNX.3.93.971015085727.21930A-100000@sydney.healey.com.au>
MIME-Version: 1.0
Content-Type: text/plain



> random cube and a random location with that cube. The resulting 
> "random" character is then XORed with the appropriate character of 
> the plaintext. If someone can prove to me that this method is stupid 

The way I understand this is that only one character is chosen and this
same character is XORed with all plaintext for that session. Therefore,
given that there are 8 bits in an unsigned char (which I am assuming you
are using based on your choice of the word "character"), meaning that 
there are only 2^8 (256) possible 8 bit characters, hence only 256
different possible outcomes. Such a short keyspace is linearly searchable
in a very small amount of time, making the encryption scheme particularly
weak.

If I am writing this based on a false understanding of your scheme, would
you mind clarifying exactly the points in which I am in error, so that I
might analyse with that information taken into account.

Yours Sincerely,

Benjamin Grosman







Thread