Re: Bonehead basic crypto question

From: Tom St Denis (tomstdenis_at_yahoo.com)
Date: 10/18/03 

Date: 18 Oct 2003 06:04:26 -0700

zoomzoomzoom@xtra.co.nz (Matthue Gera) wrote in message news:<F73kb.182172$JA5.4557778@news.xtra.co.nz>...
> Good question Ben,
> you know doubt know that computing power is multiplying
> itself on the desktop at a very fast rate. So are supercomputers that
> can be used for brute force attempts.

Oooh now I'm trembling. Of course I know just a tad more than you do.

> You are right that 128bit is strong, however with the advances we have seen
> in computing power recently we need to step up and take advantage in more
> powerful technology when it arrives. 128bit encryption is old, its that
> simple.

Which 128 bit encryption? Also what is your evidence to back this up?
  Let's do some math. Worlds fastest ALU is 5Ghz [intel prototype].
That's 5x2^30 cycles there abouts. At that rate you would need
2,009,846,842,066,573,759,349 such devices to brute force a 128 bit
key in one year assuming that the cipher and verification takes one
cycle [not realistic].

> It is much easier and quicker to crack today, therefore we need to
> increase the odds even more, way above whats considered 'acceptable',
> then we can be sure what we have now will not be so easily compromised in
> the near future.

I'd say that's already done. AES-256 for instance isn't twice as hard
as AES-128, it's 2^128 times harder!

> The 1024 bit encryption engine built into GEM 2003 requires a very powerfull PC
> to encrypt files at a reasonably fast rate, this is because of the complexity of
> this new technology for which has taken me years to develop.

Oh *** not another of these. Maybe the cipher is slow because you're
an incompetent hackjob who hasn't studied the field and you don't know
what you're doing.

For example, I'm fairly certain I could make a slow MPEG encoder but
I'm not a DSP expert!

Why would you think you're qualified to a) write software people
should trust and b) give out advice on anything?

> You may be asking yourself why use this instead of PGP?
> Another good question, however if we stopped considering new things in the world
> we would still be using stone and wood wheels to get around.

New is good. But is it truly better? I could use RC5 with a 128 byte
key too. Would I feel any more secure than using a 16 byte key? Not
really. Why? Cuz I know how to f'ing count!
 
> GEM 1024 is new and needs to be trialed just like any other new technology that
> comes along to be proven like other technology used previously.

Perhaps but you are approaching this all wrong. First divulge the
design in an academic forum then let people attack it. Packing it in
a program that people may inadvertantly use and get screwed is not a
good idea.

> However if we are to advance, we need to have an open mind to new and better things
> arriving on our doorstep, if we dont we will not be taking advantage of the new
> possibilities that arrive and be disadvantaged by that.

What advantage? So far all you have mentioned is that we have
supercomputers capable of say 2^100 operations per second and that we
need 128 byte keys... What advantage? RC5 can use 128 byte keys.

> Confidence and trust comes with time and usage.

No it comes from reputation. You don't have one so don't presume to
lecture anyone here.

> I can totally understand people having doubts, this is because they do not have
> trust and a previous history of use of anything new.

Because you fit the profile. In fact you are acting very similar to
the VMPC dude.

> I hope you will take advantage of this new tool just as other have already.
> Improvements may be made in the near future to increase the speed of the algorithm
> but with computing speed advancing very quickly this should catch up to the CPU
> requirements of GEM 2003 in no time. The GEM algorithm is very CPU intensive, this
> is because of the workload required to pass information through the engine and
> process it. Slow machines around today may suffer from this forward advanced
> requirement but as I have said before, they will catch up very soon and provide
> more KBytes per second processing that what can be achieved today.

It couldn't possibly be because you just threw stuff together and you
don't understand what makes a cipher "secure". Any half-ass stoned
comp.sci major with a weekend of cloak and dagger movies can come up
with a slow cipher. Nobody cares about those [unless they present new
theory which I doubt yours does].

My recommendation is that you pull your software, post a detailed
explanation of the cipher and why people would want it.

BTW does your cipher even MAC the data? I bet not.

Tom