Re: Passphrase and swapfile (David Picón Álvarez)

Leigh S. Jones, KR6X
Thu Jun 6 21:00:02 2002

----- Original Message -----
From: "Adrian 'Dagurashibanipal' von Bidder" <>
To: "Leigh S. Jones" <>; "David Picón Álvarez"
Cc: <>
Sent: Thursday, June 06, 2002 06:54
Subject: Re: Passphrase and swapfile (David Picón Álvarez)

> On Thu, 2002-06-06 at 15:31, Leigh S. Jones wrote:
> > Passphrase and swapfileDon't be to worried about your passphrase
> > appearing in the swap file.  In a Gb of random
> > data being updated every hour or so it's fairly
> > likely that your passphrase will appear
> > randomly a few times a day too, unless you
> > have a whale of a passphrase.
> I don't think it's likely for the passphrase to appear randomly: the
> swapfile does not contain random data, but only text or program code
> that is loaded - and a sequence of ascii chars is not too frequent in
> program code, and if the passphrase appears 'just so' in normal text,
> it's not too good anyway.
> To the original problem: any disk editor will do it. Use google. (Of
> course, there is always the possibility of switching to a decent
> operating system :-)
> Also, there was discussion on gnupg-devel recently on exactly this
> problem and possible solutions. You may want to search the archives
> (didn't follow the thread, don't know what the conclusion was).
> cheers
> -- vbi
> --
> secure email with gpg   key id 0x92082481
>                            key id 0x5E4B731F

Imagine yourself acting from the attackers point of view.  The passphrase
might, and might not appear within the last overwrite of the swap file.  The
directory shows which sectors the swap file occupies.  A complete
replication of the swap file is achieved in Windows.  The encrypted
messages and the secret key file are in hand.  You, as the attacker, do
not know where in the swap file the password might exist.  You decide to
limit your search to strings in which bit 7 is not set.  Even though the
swap file contains both program and string data, the programs contain
large quantities of embedded strings.  It's difficult to map which bytes
may be the beginning of a password, although one might imagine that
the final byte will be a NULL.  Approximately 50% of the swap file contains
possible password strings, and the swap file is appropriately sized for a
512Mb RAM, so it may be a Gb long.   How many different permutations
of the swap file contents are possible choices for testing.

We are talking 1Gb of swap file here.  If you find a 20 character long
sequence enclosed by NULL characters, will you only try to use all 20
characters?  Or must you try many permutations?  Perhaps the last
11 characters?  Perhaps the last 9? Remember, an extensive dictionary
for an English dictionary search type attack is about perhaps 140K bytes,
and the permutations for that are already worked out in advance.  We're
talking about a swap file that presents a lot of permutations here.  If you
have a dictionary search tool for breaking the password, then will you
choose to try the dictionary search tool before you try cracking the
password out of the swap file?  The dictionary search might not produce
a match, but you have no way of knowing for sure that the swap file
will, either.  Suddenly the dictionary search starts to look like a pretty
good thing to try first.  Next, since you've already succeeded at
burglarizing this computer, will you begin to consider alternatives to
cracking the password from the swap file, such as trapping keystrokes
over the course of weeks with a tiny program you've added?  Let's face
it, a skillful attacker has many alternatives, and would prefer to use one
that yields consistent results.  Is the most recent overwrite of the swap
file really the greater risk to your security?  Isn't a brute force password
crack likely to be in the arsenal of the attacker?  Wouldn't the attacker
be equipped for that, too?