🚀 go-pugleaf

In <1992Apr10.140052.28412@uwm.edu> rick@ee.uwm.edu writes:

>>[info about availability of PKCONTST.ZIP]
>Ok, I'll bite...  How does one choose a key "in such a way that brute
>force attacks are not possible"???  I think I'll try "zzzzzzzz".  :-)
>Gimme a break!  Brute force is *always* "possible"...  It's just not
>very *quick* sometimes.  Tell ya what...  let's divide up the keyspace
>between all of us, and break it just for fun!  (That'd probably leave

I'm in. If someone has a nice way to do this I will make it available to
as many people as possible. What about this one: make a program which starts
at a random value and keeps increasing. This could be seen as some sort
of lotery. With a real prize even! If enough people waste their computer
nights on this it should be possible (of cource the author should get
a nice thank you bonus like 0.01% or some other generous amount, I would
like to see a licence agreement dealing with this BTW).

>us each with a share of about $5, eh?)
Would only be anough to pay 200 persons. Just enough to get rid of one
bytes leaves 256^6 (wasn't the password 7 characters?) options. I have
a ZX81 here somewhere, should be no problem.

But to say something serious about this. I don't think the PKCONTST proves
much. It does perhaps prove the scheme is good (nice to know) but it does
not prove it is good. The major advantage remains (in my option) that there
is very little time with the PK scheme between trying a password and knowing
it is good. The NSEA scheme for example seems much better in this respect.
You can always claim the user should use a better password but we all know
users :-). At least the program should warn when a too simple password is
used (hint, are you listening PK?).

>Serge!  Here's your chance to finance your trip to CalTech!  Go for it!!!

>Rick Miller  rick@discus.mil.wi.us  discus!rick@uwm.edu  rick@ee.uwm.edu

Nico