[1175] in cryptography@c2.net mail archive
Re: Thoughts on the next target.
daemon@ATHENA.MIT.EDU (tamaster@technologist.com)
Tue Jul 8 13:37:26 1997
From: tamaster@technologist.com
Date: Tue, 8 Jul 1997 12:08:35 -0500 (CDT)
To: cryptography@c2.net
On Mon, 23 Jun 1997 15:46:47 -6, Peter Trei wrote:
>
>Inadequately encrypting commercial software.
>
> We got a lot of bang out of brute-forcing 40-bit RC4 in the
> export version of 'Netscape Navigator' a couple years ago,
> partly because there was an identifiable and well known
> target which *had* to respond to the crack (which Netscape
> did with speed and grace). We could do this again.
>
> I recently had cause to investigate the cryptography used in
> one of the applications of a very popular office suite, released
> this year. A password recovery specialist I spoke to claimed that
> the crypto used was 40-bit RC4! If this is true, it may apply to
> all of the applications of that suite, and thus the apps are
> susceptible to brute force attacks of quite modest scale - ones
> which may be undertaken in a small office in a relatively short
> time.
>
> Producing key search apps which can brute the crypto in this
> suite would force the manufacturer to answer as to why it chose
> such poor cryptography, and produce a stronger (albeit currently
> unexportable) version. It would also light a fire under the
> manufacturer to lend it's not inconsiderable weight in the
> export battle.
>
> The above are my personal thoughts which do not neccesarily
> represent those of any other person or any organization. I'd
> appreciate comments.
Then on Sun, 6 Jul 1997 20:16:16 -0400, Mark Rosen wrote:
>
>Microsoft Access uses 32-bit encryption (RC4 I assume... not sure).
>This is ripe for the picking! Giggle. Most large corporations use an
>Access database. Here's the KB article:
>
[much of Microsoft Knowledge Base Article ID # Q140406 elided, except:]
>
>When you encrypt a database, all objects (tables, forms, queries,
>indexes, and so on) are affected because encryption is implemented at
>the page-level and not at the data-level. Microsoft Access encrypts a
>database in 2K (kilobyte) pages, regardless of the data stored in a
>page. Each encrypted page is assigned a unique 32-bit key.
>
And if the "unique" key generation source material is as robust as the
encryption selection, this could even be EASIER than it already seems.
I note that the encryption is NOT on an object basis, so key generation
is most likely data neutral (for portability), however, if Access uses
defined headers in the 2K pages...
