General brute force attack question

Jean-David Beyer jeandavid8 at
Wed Jun 17 03:47:34 CEST 2015

Hash: SHA1

On 06/16/2015 06:28 PM, James Moe wrote:
> Hello, My understanding of en-/decryption is that there is no 
> indication of progress toward finding a successful key match of a 
> given encryption. Only when the key is exactly correct will the 
> encrypted data be revealed. I have seen numerous TV and movie 
> stories where someone is frantically attempting to decrypt 
> something and there is a progress meter to indicate the current 
> degree of success. Every time I see this I think "That is total BS!
> It is all or nothing." Related to this is the oft-repeated request
> to avoid identifiable information (initials, birth date, etc.) in a
> cryptographic key. I presume this gives an attacker a preferred set
> of characters to attempt before moving on to truly random
> combinations. Finally, a brute force attack requires potentially
> billions of attempts. Obviously this cannot be done by trying the
> usual log in screens or prompts; there are delays between attempts,
> and a limited number of attempts per some interval. How does an
> attacker then perform a brute force attack? Does he cadge a block
> of encrypted text and hammer on that until success?
> Is this a correct interpretation?

I do not know what people do now, but in the old days, the black hat
team obtained a copy of the password file, /etc/passwd in UNIX and
Linux systems. This file was owned by the super-user but had to be
readable by anyone else.

The password file did not and does not contain the passwords at all.
It contains a string that is obtained by using the password to encrypt
a constant string (typically a bunch of blanks) and the encrypted
result is stored in that file. This scheme was quite effective when
the bad guys were trying to dial up and login from outside. First of
all, it was slow to log in so you could not try that many passwords
per hour.
Furthermore, I had a system where the delay for a new prompt increased
with every failure, and even then after a while, the system hung up on
the attacker.

When it became possible to just export that file, he could do so, and
then work much faster on a faster dedicate machine. To get around
that, there was a shadow file (/etc/shadow) that could only be read or
written by the super user and no one else. It was sometimes hidden
somewhere else, but I doubt that helped security much. But that file
could not be taken except if actually present in the machine room.

My information on what is done these days ends about 1990, so they may
be more sophisticated now. For one thing, for Linux systems, one can
run SELinux, where even the super-user could have a difficult time
getting at that shadow file.

- -- 
  .~.  Jean-David Beyer          Registered Linux User 85642.
  /V\  PGP-Key:166D840A 0C610C8B Registered Machine  1935521.
 /( )\ Shrewsbury, New Jersey
 ^^-^^ 21:25:01 up 7 days, 19 min, 2 users, load average: 4.81, 4.91, 4.
Version: GnuPG v2.0.14 (GNU/Linux)


More information about the Gnupg-users mailing list