🚀 go-pugleaf

KnightBird wrote:
> 
> On Sat, 28 Sep 1996, Scott Earnest wrote:
> 
> > > I know of a college who reversed ASCII values for an encryption
> > > program. DOES ANYONE KNOW THE CODE TO DO THIS.
> >

> > Well, depending on what you mean by "reverse", sure.  But why on earth wo
> > want to do that if you want encryption?  It's pathetically easy to break.
> >
> > program this_is_lousy_encryption;
> >
> > var
> >   fi, fo : file of byte;
> >   b : byte;
> >
> > begin
> >   assign (fi,'source.dat');
> >   assign (fo,'dest.dat');

Heh, can't believe I forgot the reset() and rewrite()!  :-/

> >   while not eof(fi) do
> >     begin
> >       read (fi,b);
> >       b := 255-b;
> >       write (fo,b);
> >     end;
> >   close (fi);
> >   close (fo);
> > end.
> >
> > (Yes, I'm intentionally demoing this in about the slowest way possible.)
> 
> I came up with a more interesting <but still useless> XOR routine.  The
> program was simple:  The first few bytes of the encrypted file were ENC,
> the next two were the major/minor revision, followed by the source file's
> original extention.  The rest of the file was the encrypted source.

Oh, and BTW, on a simple XOR encryption, try looking for runs of repeated text. 
If the file has a long series of 0's you could see the "naked" passcode.  But 
it's not uncommon to have a long run of spaces, periods, or line characters in 
text files.  Then it's just simple addition.

I wrote an encryption/decryption engine myself (based on a friend's ideas).  I 
set it up to use random numbers, with a shifting seed (based on the random 
stream, so it's repeatable).  It also rotates bits and uses a modified XOR 
based on the offset in the password and a value in the random number stream.  
It doesn't store the password in the header of the file, but it does store a 
folded and mangled version which can't possibly be decrypted, but can be used 
as a fingerprint test to see if the password entered was valid -- a bit nicer 
than decrypting a file and finding out that you got crap back.  :-)  Actually, 
the length of the password isn't stored, so if it were to try decoding, it 
would probably start off at the wrong position anyway.  And when the passcode 
can be anywhere from 2 to 253 characters, fat chance on breaking it by brute 
force or guessing.  I have no idea how it would stand up to real cryptography 
cracking, though.

> The encryption was accomplished by asking for a string.  I was in a hurry,
> so I just used Readln..  <owch>  Then, I started, byte for byte, reading

Well, I'd suppose that if you clean up memory and make sure the keyboard buffer 
is flushed before you start reading the password might make it a bit more 
secure to cracking.  OTOH, I'm not sure anyone would want to use a program that 
puts the password up on the screen so rubberneckers could get a better look at 
it. . . .

> the file and XORing it with the next char of the password string.  When
> StrOfs > Length (PW) I would reset the offset to 1.
> 
> Simple, alomost totally useless, and a perfect A...  hehehehe  The only

Mine wasn't homework, just leisure time.  :-)

> thing I DIDN'T do was put in the password checking CRC...  Wow, that would
> have increased security and usability, wouldn't it?  <G>

Mebbe, mebbe not.

>            \|/           Peace can not exist without war, nor can war
>        \\\\/|\////          exist without peace. Think about it...
>         \\\\|////             ----------------------------------
>             V                 KnightBird - knghtbrd@teleport.com

-- 
Scott Earnest                      | _,-""-_,-""-_,-""-_,-""-_,-""-_,-" |
setech@ix.netcom.com (primary)     | We now return you to our regularly |
sinykal@cyberspace.org (alternate) | scheduled chaos and mayhem. . . .  |