Re: cipher program

From: Dale Benjamin (daleb@k-online.com)
Date: 02/07/03 

From: "Dale Benjamin" <daleb@k-online.com>
Date: Thu, 6 Feb 2003 18:28:03 -0800

"Bryan Olson" <fakeaddress@nowhere.org> wrote in message
news:hnq0a.525$1B3.52030568@newssvr14.news.prodigy.com...
> Dale Benjamin wrote:
> [...]
> > Below you will find some Visual Basic 6 code that I developed over the
past
> > month or three which seems to incorporate a few precepts, such as a
large
> > key space.
>
> Both the program code and the cipher are, well, atrocious.
>
> > Lines 9 - 21 load the plaintext file, developing a checksum.
>
> I don't actually know Visual Basic, but it seems the program
> computes the checksum, then never references it again.

Right you are. I need to brood upon it for a while, to find some good use
for it, maybe start a round of arithmetic or transposition operations.

>
> The program reads the plaintext from a file, and stores it in a
> string variable. Good names for the variables that hold the file
> name and the plaintext would be "file_name" and "plaintext". The
> program gives a lesson in what not to do by using the variable
> "aa" for both.

Right again. But I prefer to reuse variables.

>
> > Lines 26 - 34 develop an index < 65536 based upon the passphrase
> > which can be up to 32K long, perhaps a stanza from a favorite song or
poem. I
> > wasn't very creative here and suppose further ideas may occur involving
the
> > length and checksum of both the plaintext and passphrase. Later for
that.
>
> Determining that 16 bits of entropy is all the passphrase does.

Shucks, I figured there was still a little room for improvement. The
Cabilist writes;

"We can measure how bad a key distribution is by calculating its
  entropy. This number E is the number of ``real bits of information''
  of the key: a cryptanalyst will typically happen across the key within
  2^E guesses. E is defined as the sum of -p_K log_2 p_K, where p_K is
  the probability of key K."

While the math is quite obscure to your humble and little learned
correspondent, the notion of ``real bits of information'' suggests that a
larger number would be preferable.

> > Lines 38 - 44 load a 64K file of random character developed with QBasic
> > pretty much from one of the samples in the package. But it involves
seeding
> > the random function with the number of seconds since midnight for each
256
> > byte chunk, and there's a good number of seconds in a day, so it seems
a
> > reasonable compromise for a start.
>
> All the presented program does is get 64KB from a file with the
> hard-coded path "E:\cipher\stuff23.txt", so I'll base my
> comments on the text description of the generator, above. There
> are 86,400 seconds in a day, so the time to the second has 16.4
> bits of entropy, even if perfectly uniform. The "for each 256
> byte chunk" seems useless, since they'll all be processed within
> a second or two.

Not just useless, counterproductive actually. Better to have the random
64K work thus;

  CLS : a$ = ""
   RANDOMIZE TIMER
   OPEN "e:\Cipher\stuff23a.txt" FOR OUTPUT AS #1
   FOR m = 0 TO 255
      FOR n = 0 TO 255
        x = INT(RND * 255)
        b$ = CHR$(x)
        PRINT #1, b$;
      NEXT
    PRINT m, n
   NEXT
   CLOSE

This will give me more entropy than the originally outlined method, right?

Playing around with the Visual Basic Randomize Statement, I find it accepts
arguements up to a million -1. This may be a better way to go. And the
Visual Basic Timer Function returns values in hundredths of a second.

> > Lines 48 - 57 do the actual ciphering, a simple XOR, which is nice,
> > the same program which enciphers will also decipher. Another measure of
security
> > might be achieved with a more complex algorithm, true.

> It's periodic XOR with a fixed period of 2^16 bytes.

> > Lines 59 - 68 just write the results to a file, and at 69 it ends.
Cewl.
> >
> > Discussion: The problem of compromising a ciphered message is
compounded by
> > the large and near unique 64K program key. Another difficulty arises
with
> > guessing the magic numbers in line 23 and 24. Thirdly, a 32K
passphrase is
> > rather much. Trying all possible keys and numbers is probably very time
> > consuming, with 64K * 32K * 64K * 64K of possible instances. With a
little
> > more work, all these can be changed frequently. I tend to imagine any
> > breaker program would also take a while, but am concerned. Comments,
please?
>
> The key has two components: 64KB from an unspecified PRNG, and
> an offset in 0..2^16-1. The cipher is periodic XOR starting
> from the offset, with a period of 2^16. A quarter Megabyte of
> ASCII-English will fall to a ciphertext-only attack in seconds,
> even if we assume the key components are truly random (just
> break it as a 4-time pad).

Seconds??? It took fifteen minutes to cipher a 125K .pdf file on my Celeron
333!

> It gets worse. The PRNG is not crypto-quality, and based on the
> description, it has only 16.4 + 16 = 32.4 bits of entropy. Once
> we realize for what to solve, we can exhaust the key-space in
> minutes on a Wall-Mart class machine.

Hmm. Looks like I better use the Windows Randomize function to develop the
random byte array rather than the DOS QBasic writing to a file. Thanks.

> Dale: Even if you only have a "month or three" to spend, you can
> understand what PGP does and how to use it. If you have more
> like three years to devote, you could learn to program crypto
> algorithms designed by experts. If you want to develop good
> crypto algorithms yourself, then be prepared to spend a large
> portion of your working life on that pursuit. Experts agree on
> how an itinerant algorithm designer should spend the first
> several years: study cryptanalysis.

Well, Doc, I played around with PGP some time ago, there was some problem
with WinME. Also it isn't free for commercial use. Also there is a problem
with a license for a patented algorithm, IDEA or something. Generally,
there are a bunch of conflicting claims about it. GPG is not so hot, but I
doubt many of my correspondents are going to open a DOS Prompt, much less a
BASH shell for anything that isn't immediately life-threatening.

Thanks a bunch for taking the time to sketch the most immediately apparent
failings of my humble effort, I hope I got the lesson. I reckon you guys
'up there' don't always have a free moment every other week, and if you
don't care to ponder this followup, that's cool, I have a bunch of notions
that are going to take me a week or three to develop. Like the cabalist
writes in the FAQ, security is in the key, not the algorithm or program, so
I'll maybe send the next effort in a few weeks.

Relevant Pages

  • Re: Pseudorandom keystream ciphers
    ... cipher such as RC4 is wholly dependent on the pseudorandom ... My code is symmetrical but a truly hidden algorithm. ... I would have to overlay it with a real private key ... So now I am wondering if the original overlay ...
    (sci.crypt)
  • Re: Enigma machine strenght using a computer
    ... cipher with rotors that spin backwards, forwards, stop and start based ... Is this a good way to get security on modern ... encryption less error-prone and they were a cost effective way to get ... case) than not since a wider base uses the same algorithm. ...
    (sci.crypt)
  • Re: is this double CBC?
    ... understand the difference between algorithm and implementation. ... a cipher it is subject to the same security requirements of a cipher. ... The documentation on CBC is correct, but your comparison of your algorithm ...
    (sci.crypt)
  • Re: Enigma machine strenght using a computer
    ... cipher with rotors that spin backwards, forwards, stop and start based ... Is this a good way to get security on modern ... encryption less error-prone and they were a cost effective way to get ... case) than not since a wider base uses the same algorithm. ...
    (sci.crypt)
  • Re: real random
    ... Fortuna is, excluding everything they have to say on the matter. ... Are you literally saying that Fortuna is not an algorithm? ... have a source of entropy. ...
    (comp.lang.c)