From: rja14@cl.cam.ac.uk (Ross Anderson)
Subject: Re: IBM password
Reply-To: rja14@cl.cam.ac.uk (Ross Anderson)
Organization: U of Cambridge, England
Date: Sat, 10 Oct 1992 10:37:03 GMT

In article <1992Oct6.153908.1597@infodev.cam.ac.uk>, I wrote:

||> I looked at what a PC dealer said was the top-selling office automation
|> suite. It was called Da Vinci or something like that. Look, it's even
|> got DES encryption!
|> .................           It takes one password of up to eight
|> characters and produces a ciphertext file with visible eight-byte block
|> patterns - must be ECB (or something similar but homemade).
|>
|> Looks like a PC will be enough to do keysearch on this one: just encrypt
|> a null string with all the passwords in a dictionary, and sort the list.

In article <1992Oct08.185037.113247@watson.ibm.com>, a man from Big Blue
(inventors of DES) commented:

> Looks like that? OK, try to break it on your PC and post the result (:-).
> Now seriously - it's still unfeasible to break on your home PC,
> or on your business supercomputer. There still are those 2^56
> space for the key, though that stupid ECB mode definitely
> makes it easier for various attacks (and I thought that
> nobody is using ECB in the real world :-). Those
> patterns you spotted aren't going to help you
> much - in order to be able to apply those
> you'll have to have more than 2^40 of
> those 8-bytes blocks with known
> corresponding plaintext (:-).

In article <1992Oct9.144004.19367@infodev.cam.ac.uk> I rejoined:

|> Rubbish. I'm talking keysearch, not differential cryptanalysis! What is
|> the diversity of passwords that people choose? Experience with unix
|> password crackers shows that you can guess a fair number of them by
|> running through a dictionary. The key space is no longer anything like
|> 2^56 - it'll be somwhere between 2^10 and 2^20.

|> You check each guess by encrypting a string of blanks by each trial password
|> until you get the common pattern. In fact, you only have to do these
|> trial encryptions once, and sort and store the result; you can then see at
|> once if a ciphertext was created using any of these passwords by just
|> looking in your list for the common pattern.

In article <1992Oct09.184045.100568@watson.ibm.com>, the reply came:

> Oh, sure... And just how many of the trial ciphertexts are you going 
> to keep? (:-)

I'm going to take a dictionary of 50,000 words, encrypt a string of blanks
with each word, and sort the resulting ciphertexts. I will expect this to
solve at least 20% of encrypted files.

> And I fail to see, how using (silly, I agree) ECB mode helps
> you to reduce the number of trials to 2^20...
> Also I don't see how ECB (of CBC, or [CO]FB) mode affects
> the passwords users choose. Some users indeed choose very
> poor passwords, so what?  I can't grasp what you are
> complaining about: is it that ECB mode is
> vulnerable, or is it that the users
> are choosing poor passwords?

The use of ECB togther with a redundant file format facilitates a very fast
dictionary attack. I can see at once from any encrypted file what the 
ciphertext corresponding to `        ' is; I can look at once at my 
dictionary and see if the user used a password I know. If the Da Vinci 
designers had used CBC, then the job would be a bit harder; I would have to 
guess a plaintext block (and its position), and then run my through my 
dictionary testing the plaintext/ciphertext pair that this gives.

In other words, you only have to do the 50,000 encryptions once, rather than 
once for each guess you make at a plaintext block.

> Or should the system explicitely
> check each password against the dictionary it has
> and reject poor password? I think it's USER'S
> BUSINESS.

Guarding against poor password choice is indeed a separate issue, but I don't
agree it's the user's business. If your user is a banker or a diplomat, you
can't and don't expect him to have an MSc in computer security. You can and do
design the system so that he can be trained to operate it adequately.

This is one of the central problems with much of IBM's product range. The big
blue company tries to be all things to all men, and so their products leave
almost all the system design decisions to the customer.

By doing this, IBM designers in my view fail to take into account the ability
and expertise which it is reasonable to expect from a small mainframe site 
such as a typical US bank.

Compare the IBM designs with the rest of the industry: financial encryption
products from companies like Atalla, Racal and Eracom include a ready-made
cryptographic protocol with hierarchies of master and session keys, ATM and
network support, operations manuals, and everything thought out so that a 
programmer can implement a fairly secure system without having to acquire any 
crypto expertise.

A cynic might even say that IBM deliberately makes its products hard to use
in order to sell consultancy and system integration services, which in turn
become a lever to sell more hardware. The problem is that those customers
who don't buy the full gold-plated service can end up doing themselves a lot
of damage by building systems which don't work properly.

Ross


Newsgroups: alt.security