1997-07-29 - Re: New Crypto Application

Header Data

From: Guillotine <guill@xmission.com>
To: cypherpunks@toad.com
Message Hash: 494c8f976f8233e6e986d7ed54c48e8ee2979a8a883ee4f00799eaedbae93c61
Message ID: <199707290750.BAA01427@xmission.xmission.com>
Reply To: N/A
UTC Datetime: 1997-07-29 08:18:22 UTC
Raw Date: Tue, 29 Jul 1997 16:18:22 +0800

Raw message

From: Guillotine <guill@xmission.com>
Date: Tue, 29 Jul 1997 16:18:22 +0800
To: cypherpunks@toad.com
Subject: Re: New Crypto Application
Message-ID: <199707290750.BAA01427@xmission.xmission.com>
MIME-Version: 1.0
Content-Type: text/plain

The first of ten replies to my e-mail that has any decent information...

>>I'm creating a new _text_ cryptography program.  
>What do you mean by "text cryptography"?  You'll only accept text as input,
>or you'll produce your output in ASCII, or you'll produce your output
>as English-like words?

It's going to be a GUI program for Windows/95 (evil, I know, but where else
is the money at?) written in Delphi.  For a quick explanation...  it has two
memo-textareas for the input and output and one edit-area for the key.  I
called it a _text_ encryption program because it's a small application like
NotePad.exe which you can just type into, encrypt, and copy the output into
your e-mail or into a file...  and it accepts ANY ascii characters as input.
The output is as garbled as hell too, not alphanumeric.

>  None of the common encryption algorithms treats
>text input any differently that raw bits, and it's worth taking whatever
>input you have and compressing it to reduce the amount of data the
>encryption and transmission phases need to handle.  Producing printable
>ASCII as an output format isn't a cryptography issue - it's just a 
>simple reversable transform from a bunch of raw bits to printable,
>and there's no excuse for inventing a new format rather than using
>MIME encoding, uuencode, or btoa, unless you're doing something extremely
>creative with Unicode...  

True, it's all raw bits to this program.  As an added plus, it supports
pasting from clipboard of any binary format using a clipboard memory dump.
Just go to your favorite graphics program and copy an entire picture, paste
it, and encrypt it.  I see no use for that whatsoever, but the point is that
if you copy it to clipboard, it can paste and encrypt it.  Since Win95 has
the ability to copy and paste even FILES then I guess that those who want
file encryption are in luck, I have implemented the file detection for
clipboard usage and I have also implemented manual file selection and

>Producing output as English-like words is more interesting.
>It's a steganography issue, not a cryptography issue, since you should
>be doing the secure part first anyway, but it can be useful for
>obscuring the fact that you're using crypto in a message.
>The canonical reference is to Peter Wayner's Mimic Functions,
>which let you model an arbitrary context-free grammar for output,
>but you should also look around for "texto".  (The other canonical
>reference is to "PHB", Dilbert's program that disguises the message
>in Pointy Haired Boss jargon, but I'm not aware that anyone's written it.)
>A good book to read on cryptois Bruce Schneier's "Applied Cryptography",
>which discusses most of the current algorithms and how they're used.

Me and a friend of mine have written some new bit switching procedures which
use keys to encrypt the input in a dozen different number systems, but since
that realllllllly slows it down I'm going to have to write a random
number/phrase generator mainly used to hash the key and make it a couple of
dozen characters long no matter how long it is.  Brute force will be
possible (it's unavoidable!) but just decrypting the text alone will not
work.  It will have to contain an ability to hash a guessed key just like
this program and then try the guess, making it take much longer in general
to brute force it.  That doesn't apply to the governments computers, but
since when does anything to do with slowing down brute forcing apply to them
and their mainframe-using crypanalytic selves???

>>The encryption algorithm,
>>using a symmetrical is going to be as strong as legally allowed, 

>There are no legal restrictions on cryptography strength in the US;
>only restrictions on what's exportable, and even then you need permission. 

I was just implying of the possibility that the US might soon resolve some
_MORE_ restrictions on cryptography, since they've already proven their
capability of imposing as much on the US.

Thanks for the information Bill!

For who ever said that I was going to release the source to this program's
copy protection... I'M NOT!  I don't have to prove to you how good or bad
its copy protection is!!!  Someone will reverse-engineer it anyways, and it
might as well take them a day or ten.  Besides, this program isn't even
going to cost ten bucks.... but I'll stop now before this e-mail spams any