Cryptography-Digest Digest #665, Volume #13 Fri, 9 Feb 01 19:13:01 EST
Contents:
Re: Shortened signatures ("Joseph Ashwood")
Office / Excel encryption ("Ryan Moore")
Excel password ("Ryan Moore")
Re: Encrypting Predictable Files (David Hopwood)
Re: relative key strength private vs public key (Roger Schlafly)
Re: Office / Excel encryption (Paul Rubin)
Re: stateful modran: uniform distribution over [0,n) (Wei Dai)
Re: Encrypting Predictable Files (John Myre)
Re: Disk Overwriting ("Dopefish")
Re: Encrypting Predictable Files (SCOTT19U.ZIP_GUY)
Re: CipherText patent still pending (Mok-Kong Shen)
----------------------------------------------------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Shortened signatures
Date: Fri, 9 Feb 2001 13:19:41 -0800
I believe there's at least one signing algorithm in Cryptonessie that
creates signature the length of the hash, the name however escapes me at the
moment.
Joe
------------------------------
From: "Ryan Moore" <[EMAIL PROTECTED]>
Subject: Office / Excel encryption
Date: Fri, 9 Feb 2001 17:08:51 -0500
I am an idiot who encrypted an Excel file and forgot the password. I'm also
incredibly cheap (and poor), so I don't want to pay for a program to
crack(a.k.a. recover) the file passwords ($29.95 for guaranteed results).
My only saving graces may be that I like crypto, I can and am willing to
read, and I know enough programming and math to get by.
I'm looking for a pointer to any information on the encryption used by
Microsoft in the Office products, specifically Excel 97. I've read that
there are "significant enhancements" between O95 and O97 such that it is no
longer trivial to crack '97 passwords, but I can't find anything that
contains information as to what the original was or how it has been
improved.
According to the Elcom Advanced Office 97 Password Recovery tool (demo),
there are at least 4 possible different ways to password-protect an excel
file:
Write protection
Book protection
Shared book protection
Sheet protection
I haved searched Microsoft's site and the web for information about
encryption and password protection, but to no avail. There are many links
to Recovery Companies, but I haven't found any useful information. I want
to make my own cracker, let it brute-force for a month or whatever is
necessary.
I know somebody has this information. I only hope that A) That somebody is
willing to share and B) it's not proprietary/non-disclosure/we'll shoot you
if you tell anyone kind of stuff.
Anybody?
- Ryan Moore, [EMAIL PROTECTED]
------------------------------
From: "Ryan Moore" <[EMAIL PROTECTED]>
Subject: Excel password
Date: Fri, 9 Feb 2001 17:13:05 -0500
(apologies if there are lots of this message, seem to be having some
troubles with my newsreader...)
I am an idiot who encrypted an Excel file and forgot the password. I'm also
incredibly cheap (and poor), so I don't want to pay for a program to
crack(a.k.a. recover) the file passwords ($29.95 for guaranteed results).
My only saving graces may be that I like crypto, I can and am willing to
read, and I know enough programming and math to get by.
I'm looking for a pointer to any information on the encryption used by
Microsoft in the Office products, specifically Excel 97. I've read that
there are "significant enhancements" between O95 and O97 such that it is no
longer trivial to crack '97 passwords, but I can't find anything that
contains information as to what the original was or how it has been
improved.
According to the Elcom Advanced Office 97 Password Recovery tool (demo),
there are at least 4 possible different ways to password-protect an excel
file:
Write protection
Book protection
Shared book protection
Sheet protection
All but one can be found trivially, the one I need is one of the easy ones.
I haved searched Microsoft's site and the web for information about
encryption and password protection, but to no avail. There are many links
to Recovery Companies, but I haven't found any useful information. I want
to make my own cracker, let it brute-force for a month or whatever is
necessary.
I know somebody has this information. I only hope that A) That somebody is
willing to share and B) it's not proprietary/non-disclosure/we'll shoot you
if you tell anyone kind of stuff.
Anybody?
- Ryan Moore, [EMAIL PROTECTED]
------------------------------
Date: Fri, 09 Feb 2001 22:30:57 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Encrypting Predictable Files
=====BEGIN PGP SIGNED MESSAGE=====
Matt Timmermans wrote:
> If you want to have it out with David on the matter of bijective
> preprocessing before encryption, you have to understand the attack model
> it protects against, and then you can understand what he's actually saying
> below.
>
> If you have ciphertext, but _no_ knowledge of the plaintext, then attack
> is impossible if the transformation from PT to CT is bijective.
That's clearly incorrect. The identity function is bijective, for instance.
You might exclude that because it is unkeyed, but keyed functions can also
leak information about the plaintext, even when the attacker has zero
information about it a priori. An example is Vigenere: if the key length
is known (which must be assumed), then the XOR of plaintext characters
separated by the key length will be leaked.
I note that you say in another follow-up that you meant "ciphertext-only
attacks against the key". But this is such a restricted attack model, that
IMHO it does not say anything useful about the practical security of a
cipher.
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOoN6qzkCAxeYt5gVAQG1Owf/dqI0z7Iue2k1tLlJbfCh6FrepYy9GuP2
+o7mE9ZjljXRC3G2+mSdtHAQbSdNC7ETrcl+PSbij5XzYjeFSuKfhFz7gykScuTW
iABDgSAEvf8GmN19PTBbxb/wUxWR01edx1hV7FYv3PG7wBMM4dUoggJKSWN6oRUE
R8d6l2q+NTirCeK1GAdd6+hAgtVYA/GQ426QA9wdKBdoy32jmbDuHFCmq+1A3jf+
fJRU88iRHY3YyHqA716jKCoItL+OBTXKKFrbQ9fBMC7+KBH5Fq8yaqphPLjY6tpf
t+tD1phiSHCNxHLJHHp/UKsHdZkKEWDqi43UJMg8rXbZL/ykQbx6dw==
=Eois
=====END PGP SIGNATURE=====
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: relative key strength private vs public key
Date: Fri, 09 Feb 2001 14:57:18 -0800
"Douglas A. Gwyn" wrote:
> > I was thinking that since sieving primes becomes increasingly easier as the
> > key size increases (since the distance between primes also increases), at
> > some point in the future the ability of a consumer owned desktop machine to
> > create a "safe" prime might be in jeopardy.
> I don't know of any direct method of proving that or even of
> making it particularly plausible. Bob S?
Its really not a problem. The spacing between primes of size n
is roughly log(n), so there are lots of them at any size. You
could do RSA safely for keys sized at 1000s of bits, or even
millions of bits.
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Office / Excel encryption
Date: 09 Feb 2001 14:57:50 -0800
Try www.crak.com.
------------------------------
From: Wei Dai <[EMAIL PROTECTED]>
Subject: Re: stateful modran: uniform distribution over [0,n)
Date: Fri, 9 Feb 2001 14:59:40 -0800
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
> I have some problems of understanding:
>
> (1) Your algirithm seems never to terminate.
The loop terminates when y >= n and x < y - (y % n).
> (2) Do I understand correctly that rng.GenerateByte() provides
> an 8-bit chunk of a binary sequence that is uniform?
Yes, that's correct.
> (3) Have you compared your scheme with one proposed by
> Herman Rubin (see the thread "Question on biases in
> random-numbers & decompression" of ca. 20th Sep. 2000)?
I just looked at his proposal, at
http://x58.deja.com/threadmsg_ct.xp?AN=677979857. He is dealing with
the problem of generating a string of random numbers mod n where n is
fairly small (the example he used is 3). It doesn't really apply to
this problem where n is large and can change from call to call.
--
http://cryptopp.com - free C++ cryptography and compression library
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Encrypting Predictable Files
Date: Fri, 09 Feb 2001 16:15:27 -0700
David Hopwood wrote:
<snip>
> I note that you say in another follow-up that you meant "ciphertext-only
> attacks against the key". But this is such a restricted attack model, that
> IMHO it does not say anything useful about the practical security of a
> cipher.
<snip>
Careful definition of the attack model can be tricky. I
remember seeing the same problem in a security proof for
BEAR/LION. That is, the proof showed that the key could
not be compromised. I didn't find anything wrong with the
proof (I'm sure it is correct), but in a limiting case,
the plaintext would be compromised: the key was effectively
ignored.
JM
(For those who care about the details: BEAR/LION are "large
block" ciphers; they are intended to be used for encrypting,
say, an entire file as a single block. The mechanism divides
the block/file into two parts: L is a key-sized prefix, and R
is the rest. The security proofs require L to be a certain
size, but don't address R's size at all. If we let R be
small, perhaps even zero size, everything works mechanically
but the security vanishes. That is, you still can't find
the key, but you don't need it to discover the plaintext.
Of course this has essentially no bearing on the practical
security of BEAR/LION, since you wouldn't use them unless
R was large in the first place. It just goes to show that
it's easy to misinterpret security proofs.)
------------------------------
From: "Dopefish" <[EMAIL PROTECTED]>
Subject: Re: Disk Overwriting
Date: Fri, 9 Feb 2001 17:35:24 -0600
so i guess that the best way to get rid of data is to just go and put some
thermite on your disk?
fish
--
=====BEGIN GEEK CODE BLOCK=====
Version: 3.12
GO dpu s++:++ a---- C++++ U--->UL
P L+ E? W++ N+++ o+ K--- w+>w+++++
O--- M-- V? PS+++ PE Y-- PGP t 5--
X+ R tv b+ DI D+ G-- e- h! r z
======END GEEK CODE BLOCK======
(www.geekcode.com)
Albert P. Belle Isle <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Since, once again, we have posters authoritatively claiming either
>
> (1) "Disk data can be recovered from under any amount of overwriting,"
> or
> (2)"Just overwriting once with FF is sufficient to preclude recovery,"
>
> both of which statements are true, but only in context, it seems
> useful to once again post the following overview in an attempt to
> provide such context:
>
> Forensic disk data recovery attacks attempt to read "deleted" (or
> inadequately overwritten) magnetically stored data on your disk either
>
> (1) through its drive controller connector, using PC-hosted software;
> (2) through its drive heads, bypassing the disk's controller circuits;
> or
> (3) directly on each disk platter's recording surface in a clean-room.
>
> Class 1 attacks can be mounted directly with forensic software, hosted
> on your PC or on the attackers' PC. These software-based attack
> measures can be countered with software-based countermeasures; viz.,
> any kind of disk data overwriting (such as Clearing per DOD 5220.22-M)
> that is applied to _all_ sensitive plaintext on the disk.
>
> Class 2 attacks use special amplifiers and signal processing to
> extract previously recorded data from under subsequent overwrites.
> They rely on increased capabilities over the disk's on-board
> electronics. Sanitizing per DOD 5220.22-M was designed to counter such
> attacks by increasing the noise-to-signal ratio beyond their
> capabilities.
>
> Many (but not all) INFOSEC people believe that the increased
> signal-processing sophistication of the on-board controllers required
> to even read the last-written data has kept Sanitizing ahead in this
> particular measure/countermeasure race. However, most question the
> adequacy of Sanitizing in protecting older, lower-density disks
> (especially diskettes) against the most modern and sophisticated Class
> 2 attacks.
>
> Class 3 attacks (such as with magnetic force microscopy), are
> generally considered able to penetrate any software countermeasures,
> including _any_ kind of overwriting. They are very costly techniques
> to use to recover the complete image-as-it-used-to-be of an
> overwritten multi-gigabyte disk, as opposed to a few specifically
> targeted bytes.
>
> (Try getting a quote for recovery of overwritten data - not just
> "reformatted" drive contents.)
>
> Nevertheless, any data of sufficient value to intelligence services or
> comparably funded adversaries should not have its confidentiality rely
> upon overwriting countermeasures.
>
> The value of your data to the kinds of attackers who can use each
> class of techniques will determine whether you must counter that
> class.
>
> This is the basis for requiring defense contractors to use Clearing or
> Sanitizing per DOD 5220.22-M (for re-use or for disposal,
> respectively) of media containing data classified as Confidential or
> Secret, while requiring NSA-approved degaussing and destruction for
> Top Secret media.
>
> The armed services' standards for disk data overwriting are NAVSO
> P5239-26, AFSSI-5020 and AR 380-19, respectively.
>
> All of them meet or exceed the requirements of DOD5220.22-M (the
> latest ones, not the old 3-pass "character, complement and random"),
> and all of which require READ-BACK VERIFICATION - which most
> "overwriting software" neglects - to be sure that improper
> cache-flushing leaks haven't resulted in the kind of "fast
> overwriting" that never makes it to disk (like the PGP bug).
>
> For an overview of the use of forensic software for side channel
> attacks on Windows cryptosystems, and countermeasures to them, see the
> tutorials on the Cerberus Systems web-site in my signature block.
>
>
> Albert P. BELLE ISLE
> Cerberus Systems, Inc.
> ================================================
> ENCRYPTION SOFTWARE with
> Forensic Software Countermeasures
> http://www.CerberusSystems.com
> ================================================
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Encrypting Predictable Files
Date: 9 Feb 2001 23:32:36 GMT
[EMAIL PROTECTED] (David Hopwood) wrote in
<[EMAIL PROTECTED]>:
>-----BEGIN PGP SIGNED MESSAGE-----
>
>Matt Timmermans wrote:
>> If you want to have it out with David on the matter of bijective
>> preprocessing before encryption, you have to understand the attack
>> model it protects against, and then you can understand what he's
>> actually saying below.
>>
>> If you have ciphertext, but _no_ knowledge of the plaintext, then
>> attack is impossible if the transformation from PT to CT is bijective.
>
>That's clearly incorrect. The identity function is bijective, for
>instance. You might exclude that because it is unkeyed, but keyed
>functions can also leak information about the plaintext, even when the
>attacker has zero information about it a priori. An example is Vigenere:
>if the key length is known (which must be assumed), then the XOR of
>plaintext characters separated by the key length will be leaked.
Here again your assuming something about the underlying file
that was encrypted. If your file that was encrypted for the most
part looks white then even a XOR with a fixed key length would give
no information as to which file it was. If a person was known to have
encrpted say a standard word 6,0 microsoft document file then you have
information about the plaintext you could use.
>
>I note that you say in another follow-up that you meant "ciphertext-only
>attacks against the key". But this is such a restricted attack model,
>that IMHO it does not say anything useful about the practical security
>of a cipher.
Unfortunately in the real world you may only have cipher text to
use when one is breaking a file. If your lucky and have the NSA or
there Chinese counter parts working on breaking it. Then even if its
a random file. If it underwant compression and encryption there is at
most one key that would work in file in PGP for example even in the
non public key mode.
The point is you can use encryption where many keys come back to
a wrong solution. Or you can use crypto where only one key can give a
valid solution. I prefer one that the enemy has no idea if the key
he has goes to the correct solution or not. This is epecially true
if you chain ciphers together. Each layer would look random. Why
use bad nethods where the enemy can in isolation test if the key
is correct.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: CipherText patent still pending
Date: Sat, 10 Feb 2001 01:08:17 +0100
John Myre wrote:
>
> Mok-Kong Shen wrote:
> <snip>
> > So any pupil of crypto never gets to do an exercise of a
> > design and hence will also have zero chance of making
> > a good (or even half-good) one in his life and, as a
> > consequence, all good ciphers that exist today ultimately
> > die out (being no longer secure enough for the future
> > computing power and techniques) after the current
> > generation of crypto experts die out.
> <snip>
>
> You have consistently misinterpreted Bryan's posts, and
> the response above is bizzare. The point has always
> been that *analysis* is the truly valuable skill. It is,
> in fact, the very skill we need in order to design good
> ciphers.
>
> Bad cipher designs are easy, we have a lot of them, they
> are basically a waste of everyone's time. So how do we
> learn the difference between useful and useless ciphers?
> Through analysis. Therefore Bryan advocates an increase
> in efforts to understand analysis.
>
> It is rediculous exaggeration to extrapolate that opinion
> and predict that no new good ciphers would ever exist.
>
> Design without analysis does nothing useful. A design by
> a novice that is analyzed by an expert is nearly as bad.
> A novice that attempts analysis begins the process of
> converting that novice into an expert - the very thing we
> want.
The quote in question was the following:
Experts teaching writing say to write every day. I've never
heard an expert cryptologist recommend cipher design as an
exercise.
There is very good reason to stress the importance of
analysis. A student should well do exercises in analysis
before going to design. But that doesn't mean that the
teacher does not give the student design excercises at a
later stage to do, if he is to do his teaching job properly.
That's why I considered the above quoted to be misleading
and argued against correspondingly.
I am not sure it is clear that cipher design is easy.
If that were the case, the AES contest would be redundant.
With the advance of analysis techniques, the design
of secure cipher becomes more difficult. With better
ciphers, one needs to device better attacks. The same
applies to warfare, e.g. tanks and anti-tank guns.
Both types of capabilities and experiences are essential
and none would come up automatically for free in my view.
M. K. Shen
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
