🚀 go-pugleaf

In article <1992Oct13.084205.1@kean.ucs.mun.ca>, jgarland@kean.ucs.mun.ca writes:
> In article <gH2JsB7w165w@works.uucp>, hacker@works.uucp (DamDum) writes:
>> lou@Cadence.COM (Louis K. Scheffer) writes:
>> 
>>> 
>>> While pondering the well known problem of DES cracking via exhaustive
>>> key search, I started wondering if you could apply genetic engineering to
>>> the problem.  It seems like it may be possible.
>>> 
>>> The basic approach would be to build a bacteria that acts as a DES key search
>>> machine.  Each bacteria generates keys at random, decrypts the encrypted bloc
>>> with the key, and compares the result with the plaintext.  If there is a matc
>>> it generates lots of a string of DNA that contains the key and a specific
>>> marker that binds to an antibody, and excretes the result.  Otherwise it
>>> just keeps trying keys.
>>> 
> 
> 
> Isn't one feature of genetic algorithms that they operate on a problem 
> space that isn't flat.  That is, I fail to see how there can be any 
> 'goodness' test here except success or failure of a key to decode 
> ciphertext into sensible output.  This would seem to reduce the 
> idea to a variant of exhaustive search.  [This assumes that keys close to 
> the correct key do not provide any information to the attacker as to their 
> closeness (which is true of DES isn't it?).]
> 
> John Garland
> jgarland@kean.ucs.mun.ca

Excuse me...but I left out 1 thing I meant to say above...I meant to say:

This would seem to reduce the idea to an _extremely slow_ variant of 
exhaustive search.  

[Expanding]  I mean, why not just search the entire space directly 
when there is no reason/way to narrow the search heuristically in some way?
Also to search an entire keyspace when sampling _with_ replacement--which 
is the case in at least the one implementation of genetic algorithms that I've 
seen--would be inordinately time-consuming.  (Of course it might be possible
to cast the problem in such a way that algorithmic variants cannot return 
to previously tried values, but I do not see how to do this without keeping 
some sort of list of unworkable keys.  This list would get very lengthy 
very quickly).


John Garland
jgarland@kean.ucs.mun.ca