I agree with you entirely.
I think the real question is, how valuable is your data? For home use to
store paper documents/cash, you might have a heavy safe with a
combinition lock, but typically not a vault rigged with motion
detectors and guard dogs :-)
With all of the poeple working from home though, its not hard to imagine
a very small group of home users that might need something greater.
Peter Curran wrote:
>I am well aware of the literature (I am pretty sure Manuel is as well), I even
>have a copy of 'Cracking DES' that somebody gave me as a joke present a
>couple of years ago. The fact remains that you still can't buy a DES-cracker
>in CompUSA, Frys or equivalent.
>If I was managing security for a mega-corp with really sensitive and important
>data flying around (which is my day job on occasion) then I worry about
>whether to trust AES-256. For securing my home network, PLOD (PLain Old DES)
>is perfectly OK. If somebody has the knowledge and need to crack it, then
>they will find many easier ways of getting in.
>CISSP, CISM, CISA, CCSE
>On Tuesday 06 July 2004 18:25, Ryan Giobbi wrote:
>>"...a corporation willing to spend 10 million dollars to build a similar
>>device today might break DES dozens if not hundreds of times per hour."
>>I do not know of any more examples other than the few listed in the
>>article in 1999.
>>Peter Curran wrote:
>>>I think that there are 2 different issues here.
>>>1. PBKDF1 (and similar) algorithms (such as the one used by Kerberos -
>>>ISTR this is a different way of doing the same thing) are really designed
>>>at producing a good quality key with minimal entropy. The idea being
>>>that a simple brute-force attack on the whole key space is not
>>>'short-cuttable'. Whilst they may be successful in achieving that
>>>objective, they will not help if the user selecting the password chooses
>>>a weak example, such as a dictionary word, car registration number or
>>>similar. (I know that you made the caveat about 'usual precautions', but
>>>the reality is that these are broadly ignored/unenforceable).
>>>2. 56 bit DES tends to be dismissed as 'too weak'. Well, I don't know
>>>if you have any knowledge of anybody ever having any DES-encrypted data
>>>compromised by a brute force attack - I certainly don't. [password
>>>guessing, on the other hand, is sadly familiar]. As you say, a couple of
>>>PC's are not going to help much when it comes to attempting a brute-force
>>>attack on a 56-bit DES encryption. I think it is a shame that it has
>>>become received wisdom that anything with a key length < 128 bits is bad.
>>> For your average man in the street, 56-bit DES is perfectly adequate and
>>>likely to remain so for a few years yet. (I had this problem a few days
>>>ago when trying to explain to a company that using plain DES to support
>>>Windows/UNIX integration using Kerberos was OK). They just did not
>>>accept it! Why, because they had seen a TV programme where some pundit
>>>had explained that <128-bit == BAD CRYPTO!
>>>On Tuesday 06 July 2004 15:49, Manuel Kasper wrote:
>>>>On 06.07.2004 15:25 +0100, Peter Curran wrote:
>>>>>I think encyrption is intriguing as a solution to the
>>>>>confidentiality issues, but as they are using DES on the Netgear
>>>>>stuff I assume that you have to pre-configure all the devices with
>>>>>a shared key. As this tends to be derived from a passord it could
>>>>>be relatively easy to attack.
>>>>I did a little analysis of HomePlug powerline networking about a year
>>>>ago. The password hashing is done as per PBKDF1 - it involves using
>>>>MD5 1000 times, so with the usual password precautions in place, the
>>>>resulting 56-bit DES key should be good. Also, provided that the
>>>>implementation in HomePlug doesn't suffer from similar flaws as WEP,
>>>>56-bit encryption is IMHO enough for home users. I mean, it's not
>>>>like you can brute-force-search a 56-bit key in a useful amount of
>>>>time with only a few PCs at hand...
>>To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
>>For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch