[Courses] [security] Crypto Scientists Crack Prime Problem

[Raven Alder]

Heya --

Quoth Cynthia Grossen (Tue, Aug 13, 2002 at 05:00:15PM -0400):
> > 2. have you heard about the 'Expert Encryption System' ? Some info is
> > here : http://www.chantilley.com/html/news3.htm Is it any good?
> 
> I haven't ever heard of it before either, but after reading the press
> release snake oil comes to mind.

	Heh.  I was kind of wondering too, which is why I said I'd have
to see details.
 
> They throw in some acronyms b/c no security system is complete w/o acronyms.
> [Expert Encryption Standard (XES) and Appropriate Key Management (AKM)]
> neither one really says anything either, what exactly is appropriate key
> management, is that like not storing your key in a file named 'secret
> encryption key here'? And expert encryption system has a nice sound to it.
> If you do a google on it you get nothing, so no papers about it, that's a
> big warning sign. Same with "Appropriate Key Management". 

	Yeah -- I did the same searches and came up empty too.  It
sounded more like marketing speak than definite snake oil to me, but
then again I've seen some really sound products killed by bad marketing.
The concerns that they raise about DES, AES, and PKI are often voiced in
the crypto community, but there are tradeoffs for almost anything.
Almost nobody uses plain old DES anymore for anything they intend to
remain secure, though triple-DES (3DES) is still in wide use.  AES
hasn't really hit the mainstream yet.  And yes, PKI can be complex and
difficult to deploy, but it all depends on what you're doing with it.**

	**The difficulty of PKI is mostly in managing keys and building
a web of trust -- how do you know for sure that nobody but Jane has
access to Jane's private key?  Does she store it on a server?  What if
that server is hacked and someone else gets her key?  How do I know that
Sandra's public key that I downloaded from a keyserver is really hers,
and not Malicious Hacker Liah's?  Things like that.    
 
	Acronyms are good for dazzling (or sometimes mazing) management,
but you can make up an acronym for anything.  I Think My Server Is
Secure -- I'm using the ITMSES standard now!  See how easy it is?
[grin]  Digging into the underlying grit of the protocols and algorithms
is what you really need to do to know whether the product is any good.
This is why it's hard to trust closed source and proprietary crypto
algorithms.  You're at the mercy of the vendor; you have no way of
seeing for yourself whether it sucks or not.  In my opinion, the best
crypto setups are the ones where everyone knows the algorithm and
implementation details, and still can't break it.  If it's stood the
test of time for mathematicians and computer scientists worldwide for
years, odds are good that it's a stable crypto setup.

> After looking at their website I did find some papers:
> http://www.chantilley.com/html/papers.htm, if you're interested they aren't
> long. I don't really know enough math to evaluate them so I won't. 

	I hadn't found that -- thanks.  I'll check them out in my
Copious Spare Time.  [grin]
 
> it looks like the idea of one-time pads plays heavily in their algorithm and
> its also looks like they are using a pseudo-random number generator to
> create the one-time pads. Which is suspect in my book. The paper that I
> looked at about the generator implies that its showing a 'dumbed-down'
> version though.

	Also, the randomness of pseudo-random number generators is a
common avenue for attack -- if the seed you're starting with isn't
really random then it's a lot easier to predict the subsequent
happenings.  There have been several attacks on TCP sequence numbers
that were predictable, etc, because of this sort of problem.  And if you
can predict and guess the sequence numbers, it's a lot easier to hijack
the session...

	One time pads in general are good, but you have to worry about
the storage and generation of them.  If that's not secure they're not
either.  
 
> Also the ITU citing references a facsimile protocol, and I don't generally
> think of faxes as needing a high degree of security and I also wouldn't want
> a heavy-duty algorithm for that purpose b/c it would increase the price of
> the fax machine too much and decrease performance. You need a processor
> powerful enough to encrypt and decrypt on-the-fly, and even then it still
> takes some time.

	Depends on who you are -- I certainly wouldn't have a use for
that, but the Army might.  I am wondering about what fax protocols have
to do with computer-based crypto, though.  I suppose I'll have to read
the white papers to find out.
 
> -- this is meaningless. DES has been out of date for at least the last ten
> years and really more like twenty. They do mention AES but there is not
> enough info there to really make any conclusions one way or another, but
> I'll put my $ on Rjindael(AES [Advanced Encryption Standard] -- the
> replacement for DES), at least that's been looked at by crypto researchers
> the world over and vetted by the NSA. Plus there are solid implementations
> of Rjindael out there in C and a few other programming languages (for
> example foxpro has an implementation, its really just a wrapper around the C
> code though.)

	Also, I wouldn't take the word of an algorithm's developer that
it takes X years to break.  Let the crypto community at large have a
crack at it -- all it takes is one person to think of a novel and
creative approach, and bam, ten billion years becomes four hours.  It
might be that this product is so new that it hasn't had a chance to be
vetted by the community yet (in which case I wouldn't trust it yet).
 
> As a general rule, if the main source of info about an encryption system is
> a press release I take it with a big, huge grain of salt. *like really big*
> ;)

	Heh.  Yah.  Thanks for all the intelligent commentary, Cyn.

Cheers,
Raven
 
"Do you know where the RSA t-shirt is?"
"No." 
"Well, I need the algorithm, so I'm doing laundry."
  -- me and RavenBlack