[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ms-cryptoapi
Subject:    Re: Couple of Newbie Q's
From:       Dr Stephen Henson <shenson () BIGFOOT ! COM>
Date:       1998-06-25 12:10:43
[Download RAW message or body]


David Parkinson wrote:
>
> At 23:52 24/06/98 +0100, Dr Stephen N. Henson wrote:
> >At this point the mandatory warning that using stream ciphers
> >(e.g. RC4) is unwise.
>
> Would you care to elaborate on this throw-away comment?
> Did you make it in the context of your current thought processes?
> As a generic comment it is wrong - stream ciphers do have their
> place in this world and are not inherently unsound.
>

It was in the context of the original query. Specifically password based
encryption and a "Newbie" question. Since this is in a "Newbie" context
I'll give a bit of backround for those unfamiliar with stream ciphers
and their potential pitfalls (some would say gaping chasms!).

A stream cipher is effectively a deterministic algorithm for generating
random numbers based on a key: that is the same key always yields the
same stream of random numbers.

This is used for encryption by XORing (exclusive or'ing) the plaintext
with the random number stream to yield the ciphertext. It should be
apparent that XORing the ciphertext with the stream will also yield the
plaintext.

There is a third property that makes stream ciphers dangerous if not
used with caution. If you XOR the ciphertext with known plaintext you
can obtain the random number stream (or part of it).

If you then use the same key to secure different data (e.g. another
file) then its contents can be partly read because the random number
stream is partly known. This does not require any kind of password, just
ciphertext and known plaintext and other data "secured" with the same
key.

Let me give an example of how dangerous this is to the unwary. Suppose
you encrypt two PRIVATEKEYBLOBs with the same RC4 key one 512 bits and
the other 1024 bits.

The initial data in a PRIVATEKEYBLOB is an RSAPUBKEY structure followed
by the modulus: this information can be constructed from the public key.
You thus have a fair bit of known plaintext to play with. In the 1024
bit case the modulus is 128 bytes long.

This allows part of the random stream to be recovered which corresponds
to the modulus (64 bytes) and prime1 and prime2 (32 bytes each) of the
512 bit key. Anyone familiar with a PRIVATEKEYBLOBs data (or the PKCS#1
data it mirrors) and the RSA algorithm should realise that with the
public key and one of the primes (you have both in this case) and some
simple mathematics you can trivially recover the whole PRIVATEKEYBLOB
for the 512 bit key.

This means that the whole random number stream can be recovered for the
512 bit private key. You can then use this to decrypt enough of the 1024
bit private key to recover it too.

This has all been done without any guessing of passwords at all: it
works simply because a stream cipher has been used with the same key and
known plaintext. If this key is then used again you can get (does quick
calculation hoping it isn't wrong) the first 588 bytes of it with no
effort at all.

As should be apparent this can only be done if the same key is reused to
encrypt different data. If different keys are used each time (for
example by using a salt with the password) then this is avoided.

In the past several rather large companies encryption software has
fallen into the trap of re-using an RC4 key and some still do. Anyone
unsure who "rather large companies" refers to should use their
imagination :-)

Stream ciphers do indeed have their uses: they tend to be rather quicker
than other ciphers and are thus useful for SSL for example (browsers
typically use RC4). In this case the key is randomly created with each
session.

Now back to my original point. If a "Newbie" user isn't sure of the
dangers of using stream ciphers and reused keys then the simplest advice
to give is "don't use stream ciphers until you do understand their
problems" block ciphers generally don't suffer from this problem (though
it's still not a good idea to reuse the same key). It is all too easy
for the unwary to create very insecure software.

Steve.
--
Dr Stephen N. Henson.
UK based freelance Cryptographic Consultant. For info see homepage.
Homepage: http://www.drh-consultancy.demon.co.uk/
Email: shenson@bigfoot.com
PGP key: via homepage.

----------------------------------------------------------------
Users Guide http://www.microsoft.com/workshop/essentials/mail.asp
contains important info including how to unsubscribe.  Save time, search
the archives at http://microsoft.ease.lsoft.com/archives/index.html

[prev in list] [next in list] [prev in thread] [next in thread]