LinuxSA Mailing list archives

  From: Net Media Solutions <john@vodka.lynx.net.au>
  To  : Mark Newton <newton@atdot.dotat.org>
  Date: Wed, 15 Sep 1999 14:03:51 +0930 (CST)

Re: Encryption (was Re: Linux Console Security)y

> What are you smoking?  Go visit the crypto newsgroups and read them for
> a while;  it's no longer a matter of debate that the US Government finds
> 128 bit keys well within its reach.

	Hmmm. Perhaps you might suggest such a list?
 
> Anyway, by the time you get to 128-bit keys it starts to be easier to
> attack the algorithm through other methods.  For example, where are you
> going to find a source of randomness with 128 bits of entropy on your 
> Linux box?  If you can't, it's far simpler to attack the random number
> generator that builds session keys than it is to attack the algorithm 
> itself.

	If you conceive a better method of cryptanalysis (ie if the algorithm
	is flawed) then increasing the keysize to 256 bits won't necessarily 
	provide you with any more security, will it?
	As for entropy in a linux box, try /dev/urandom. It's a 
	cryptographically (reasonably) secure RNG that takes input from 
	interrupts and the like.
	And don't even dare mention [s]rand().

> Incidentally, what upper bound are you placing on "significant advances
> in hardware manufacturing"?

	We'll stop just short of quantum cryptography, I think.
 
>  > 	56-bit ciphers such as DES have been shown to be ineffectual since the 
>  > 	80s (the EFF's massively parallel DES-cracker was postulated a couple 
>  > 	of years ago, but was never actually built).
> 
> Yes it was.  It was used to solve the RSA 56-bit DES Challenge II in
> less than 3 days.  It was later coupled with an rc5des client which
> enabled the Challenge-III to be solved in approximately six and a half
> hours. 

	Mea culpa. That sentence was poorly worded. Such massively
	parallel cracking machines had been conceived in the past, but not
	built until just recently. (Ie in the past, people had had the idea,
	but had not actually built one until the EFF did not-too-long-ago).

>  > 	...And 128-bits will "only" therefore take 4700000000000000000000
>  > 	 hours (give or take) :)
> 
> With present technology.  And ignoring the fact that "deep crack" is
> inherently scalable, leading to reasonably trivial power-of-two increases
> in its capacity by adding additional gate-array modules.  And ignoring
> the fact that the NSA has doubtless had machines just like it for years,
> with a virtually unlimited budget.

	Let us not forget Moore's law, shall we? 
	And the NSA's budget *is* limited (large, but still limitted),
	and they have more than just cracking machines to spend it on
	(satellites, for a start). If it's a brute force attack we're talking
	about (AFAIK, there has been little by way of productive cryptanalysis
	against ciphers like IDEA, blowfish, etc), then even if the NSA
	is 10 years ahead of everyone else, you are still requiring 
	an exceedingly large amount of hardware  to get the times taken
	to crack arbitrary encryption down to a reasonable period.

> You might like you reassess your time estimates.

	Actually, no. Although if Sandia pull something funky out of
	the quantum cryptography field, all bets are off.
	(I'm not sure how well block ciphers fit quantum theory in any case.
	I know it looks very promising against elliptic curve crypto, and
	publickey crypto ...).

Jb
 

-- 
Check out the LinuxSA web pages at http://www.linuxsa.org.au/
To unsubscribe from the LinuxSA list:
  mail linuxsa-request@linuxsa.org.au with "unsubscribe" as the subject