Cryptography-Digest Digest #53, Volume #12 Sat, 17 Jun 00 23:13:00 EDT
Contents:
Re: Encoding 56 bit data ---HELP--- (Nicol So)
Re: MDS theory? ("Paulo S. L. M. Barreto")
Re: small subgroups in Blum Blum Shub (David A. Wagner)
Re: Extending LFSR...... (Joaquim Southby)
Re: small subgroups in Blum Blum Shub (David A. Wagner)
Re: Extending LFSR...... (tomstd)
Re: Encoding 56 bit data ---HELP--- (Sundial Services)
Re: Cipher design a fading field? (wtshaw)
Re: How RSA SecurID tokens work? (Vin McLellan)
Re: Flattening of frequency distributions (wtshaw)
Re: Flattening of frequency distributions (wtshaw)
Re: Flattening of frequency distributions (wtshaw)
Re: I Will Make ANY Software for Anybody (wtshaw)
Re: MD5 Expansion (S. T. L.)
Re: MD5 Expansion (tomstd)
Re: Cryptographic voting (zzapzing)
Re: MD5 Expansion (Mark Wooding)
Re: quantum cryptography at nytimes.com (zzapzing)
Re: quantum cryptography at nytimes.com (zzapzing)
Re: MD5 Expansion (tomstd)
Re: GeekPress: Will Cyber Criminals Run the World? (zzapzing)
Re: MD5 Expansion (David A Molnar)
Re: MD5 Expansion (Mark Wooding)
Re: Evidence Eliminator Dis-Information Center ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: Nicol So <[EMAIL PROTECTED]>
Subject: Re: Encoding 56 bit data ---HELP---
Date: Sat, 17 Jun 2000 20:16:08 -0400
Reply-To: see.signature
Andrew Bortz wrote:
>
> ... However, public-key encryption by its very
> nature allows for trial encryptions of arbitrary plaintexts. Therefore,
> if this were using a public-key system, using a public key larger than
> the data would simply force an attacker to brute force the plaintext.
You seem to have an implicit assumption that no attack better than
exhaustive search is available, which is not generally true (or
generally not true).
--
Nicol So, CISSP // paranoid 'at' engineer 'dot' com
Disclaimer: Views expressed here are casual comments and should
not be relied upon as the basis for decisions of consequence.
------------------------------
Date: Sat, 17 Jun 2000 21:10:27 -0300
From: "Paulo S. L. M. Barreto" <[EMAIL PROTECTED]>
Subject: Re: MDS theory?
tomstd wrote:
> I can't get to [Vincent Rijmen's] site because of his anti-ms ego trip. So if
> anyone has direct links to his papers I would appreciate it.
Why don't you send him mail and request that he grant access to people
visiting via msie? <mailto:[EMAIL PROTECTED]>
> What I got from Vaudenays analysis of multipermutations is that
> a (r + n)-multipermutation is a permutation from Zr to Zn (Z is
> a alphabet) such that any two pairs in the form (x, f(x)) cannot
> collide in r positions.
>
> Where the pair (x, f(x)) is the input and output. So if you had
> a 4x4 code each would be eight bytes. If you had a (4 + 4)-
> Multipermutation (is that possible?) that means any two pairs
> will not share (collide) in four bytes (in/output).
I don't think I understand it, but if all you can do with that
construction is that any two (distinct) pairs won't collide in *four*
bytes, then the diffusion is clearly inferior to an MDS code (where any
two distinct pairs won't collide in at least *five* bytes). This is
because a difference in the first four bytes (i.e. in x) will affect
only three bytes of f(x), not all four of them. Maybe I'm missing
something here, though.
Paulo.
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: small subgroups in Blum Blum Shub
Date: 17 Jun 2000 17:34:22 -0700
In article <[EMAIL PROTECTED]>, Terry Ritter <[EMAIL PROTECTED]> wrote:
> >Take a look at:
> >http://x61.deja.com/[ST_rn=ps]/getdoc.xp?AN=572282072
>
> I saw that when it came out, and a short summary is:
>
> "it follows from the RSA assumption that finding short cycles is
> impossible, for moduli large enough that factorization is
> intractable."
>
> and
>
> "The advice to choose moduli with guaranteed long cycles, and to
> choose seeds that way, is completely useless."
>
> Oddly for useless advice, the last 2/3 of the BB&S published article
> concerns just this issue. [...]
> Now, did Blum, Blum and Shub simply get carried away with their own
> math abilities? Shall we assume that they were they so unaware of
> their first results that they simply did not understand that 2/3 of
> their work was "useless"?
>
> The world gasps at such arrogance.
Well, now I'm curious. What was wrong with the old article at
the URL above? It looked correct to me. What am I missing?
I'd love to hear a technical refutation, if there is one...
------------------------------
From: Joaquim Southby <[EMAIL PROTECTED]>
Subject: Re: Extending LFSR......
Date: 18 Jun 2000 00:44:33 GMT
In article <[EMAIL PROTECTED]> tomstd,
[EMAIL PROTECTED] writes:
>This is all wrong mathematically. Now I must caution I am new
>here too.
>
Sorry, Tom, it's not wrong; it's just not the way you look at it. I'm
not new to LFSR's -- I've been designing things with them for close to
ten years.
>But LFSRs are not based on "tap sequences" they are based on
>primitive elements in GF(2^n) (n is the size of the lfsr in
>bits).
>
Perhaps you should look at things from the application side rather than
the theory side. Tap sequences are the list of bits in the shift
register that are used as part of the feedback function. It's a pretty
common term, so I don't see what you're driving at here. Look at Applied
Cryptography, Section 16.2 for a definition of the term.
>
>One thing that confuses me is that x^4 + x + 1 is a 4-bit lfsr
>(let's say it is...) what is the degree of the modulus? x^5? I
>always thought that polynomials in GF(2^n) could have a degree
>of at most (n-1) for example in sboxes of x^-1 mod p in GF(2^n)
>the maximum degree of any element of the sbox is (n-1).
>
>This would mean that 4 bit lfsr either have a degree of upto 3
>or it's in GF(2^5)? i am loss.
>
There might be some confusion in how terms are used. For a maximal
period LFSR, the polynomial formed from the tap sequence plus 1 is a
primitive polynomial. The degree of the polynomial is the length of the
shift register. For the polynomial you gave, the shift register is 4
bits long, so the degree of the polynomial is 4.
I'm not sure how you're using the term modulus. Given the polynomial X^4
+ X^3 + 1 mod 2, would you consider the modulus to be 2?
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: small subgroups in Blum Blum Shub
Date: 17 Jun 2000 17:41:09 -0700
In article <[EMAIL PROTECTED]>, Terry Ritter <[EMAIL PROTECTED]> wrote:
> In practice,
> selecting a short cycle would indeed be very, very unlikely. But
> "unlikely" is *not* the same as "impossible."
>
> Instead, the discussion here is about the concept of "proof" itself:
> I claim that if it is *POSSIBLE* to select a short cycle, it should be
> self-evident that any *proof* of security must be false.
Well, personally, I think you're wrong here.
You can never prevent the adversary from winning if he can make a lucky guess.
All you can do is make it exceedingly unlikely that the adversary wins.
For instance, clearly it is *POSSIBLE* for the adversary to guess a
factor of N just by dumb luck, and then you've broken BBS, but such a
lucky guess is extremely unlikely to happen. You might as well worry
about getting struck by lightning over and over again.
Fortunately, the definitions of what it means to be secure don't require
us to do the impossible. Thus, a proof of security roughly means that
we can bound the success probability as the adversary by a extremely small
quantity, so small that it can be essentially ignored in practice.
Absolute perfection here is neither required not attainable.
------------------------------
Subject: Re: Extending LFSR......
From: tomstd <[EMAIL PROTECTED]>
Date: Sat, 17 Jun 2000 17:49:10 -0700
Joaquim Southby <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]> tomstd,
>[EMAIL PROTECTED] writes:
>>This is all wrong mathematically. Now I must caution I am new
>>here too.
>>
>Sorry, Tom, it's not wrong; it's just not the way you look at
it. I'm
>not new to LFSR's -- I've been designing things with them for
close to
>ten years.
>
>>But LFSRs are not based on "tap sequences" they are based on
>>primitive elements in GF(2^n) (n is the size of the lfsr in
>>bits).
>>
>Perhaps you should look at things from the application side
rather than
>the theory side. Tap sequences are the list of bits in the
shift
>register that are used as part of the feedback function. It's
a pretty
>common term, so I don't see what you're driving at here. Look
at Applied
>Cryptography, Section 16.2 for a definition of the term.
>
>>
>>One thing that confuses me is that x^4 + x + 1 is a 4-bit lfsr
>>(let's say it is...) what is the degree of the modulus? x^5? I
>>always thought that polynomials in GF(2^n) could have a degree
>>of at most (n-1) for example in sboxes of x^-1 mod p in GF(2^n)
>>the maximum degree of any element of the sbox is (n-1).
>>
>>This would mean that 4 bit lfsr either have a degree of upto 3
>>or it's in GF(2^5)? i am loss.
>>
>There might be some confusion in how terms are used. For a
maximal
>period LFSR, the polynomial formed from the tap sequence plus 1
is a
>primitive polynomial. The degree of the polynomial is the
length of the
>shift register. For the polynomial you gave, the shift
register is 4
>bits long, so the degree of the polynomial is 4.
That isn't right because you really have
x^4 + x^2 + x + 1 = 1x^4 + 0x^3 + 1x^2 + 1x^1 + 1x^0 or 10111
which is a five bit digit. A 4 bit LFSR must have a modulus of
degree 4 but a primitive element of degree 3.
Tom
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
Date: Sat, 17 Jun 2000 18:20:42 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Encoding 56 bit data ---HELP---
Most encryption systems routinely compress the data before they encrypt
it, so the plaintext can be assumed to be something on the order of "a
PKZip'd {may PK rest in peace, BTW} file."
Now, that is assumed to be an acceptable thing -- something that would
hide the plaintext well -- but my experiments with breaking KZip's own
built-in stream cipher suggest that this might actually be a weakness.
Compressed text actually has some very observable characteristics.
For instance, in the first few hundred bytes of a compressed file, it's
very likely that about 50% of the bits will be ones, and about 50% of
the bits will be zeroes. There are various statistical metrics that you
can use and understand that I am simplifying the whole thing for sake of
argument, but the fact remains that the frequency distribution of bits
(as well as the run-length of bit sequences and so on) in compressed
files is actually very predictable.
I was able to break some PKZip stream-ciphers using what amounts to a
"no known plaintext attack" based only on the knowledge of (a) bit
distribution characteristics of the input plaintext; and (b)
distribution of bits in the text that is being masked by the cipher
output. (The cipher generates what amounts to noise, injected upon a
stream of bits that are not-noise, which makes the characteristics of
the noise-stream itself "stand out.")
So... WHAT IF the attacker did "brute force the plaintext?"
> > the data would simply force an attacker to brute force the
> >plaintext.
>
> You seem to have an implicit assumption that no attack better than
> exhaustive search is available, which is not generally true (or
> generally not true).
>
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Cipher design a fading field?
Date: Sat, 17 Jun 2000 18:30:48 -0600
In article <[EMAIL PROTECTED]>, "John A. Malley"
<[EMAIL PROTECTED]> wrote:
> And this brings out the eerie truth that when the plaintext comes from a
> non-Turing-recognizable language, even when one gets the plaintext and
> its ciphertext there is NO algorithm able to decide which instance of
> the decryption (and thus the key) produced the correct decryption
> (candidate plaintext equal to the original plaintext.)
>
> John A. Malley
> [EMAIL PROTECTED]
Figure that a person with a gut instinct that leads to a solution is a
part of an implemented algorithm that he decides to use. If you dismiss
this etherial ingredient as nonessential in your discssion, you support
the loss of the warm art of cryptanalysis.
--
Some Turkeys can fly, for short distances. If you are to depend on
birds for communication, if it's with turkeys, consider the
discussions that might occur while feasting on one.
------------------------------
From: Vin McLellan <[EMAIL PROTECTED]>
Subject: Re: How RSA SecurID tokens work?
Date: Sat, 17 Jun 2000 21:44:23 -0400
Roger Schlafly wrote:
> > .> Or find some weakness in the pseudorandom number generator
> > .> in which info about the secret is leaked in the 6-digit codes
> > .> that are transmitted.
Vin McLellan wrote:
> > There is no PRN generator. The token-specific keys embedded in each
> > SecurID are true random numbers, generated by a radioactive-trace
> > hardware device.
> > ... As I noted, each SecurIDs generates the series of 6-8 digit token-codes
> > -- continually displayed on an LCD on the face of the token, and each
Mr. Schlafly replied:
> The latter is the PRN generator to which I was referring. That is
> what the SecurID token is -- a PRN generator. Maybe the seed is
> truly random, but all subsequent token-codes are PRNs.
You are right, of course.
Thank you for the gentle correction.
_Vin
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Flattening of frequency distributions
Date: Sat, 17 Jun 2000 18:46:25 -0600
In article <8igfu8$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Guy
Macon) wrote:
> In my opinion, one who is conservative in matters of security
> should assume that the attacker has full access to everything
> except the plaintext and key. He has your algorithms, he can
> mount man in the middle attacks, chosen plaintext attacks, etc.
>
> Thus the attacker knows your frequency distribution flattening
> algorithm and reverses it right before he exploits his knowledge
> of the frequency distributions of plaintexts. You gain very little.
But, if you have a good frequency manipulating algorithm, it can have keys
as well as the the algorithm yielding prior ciphertext. Having gone
through this all before in which I demonstrated the ability to apply an
algorithm that would skew any ciphertext to a target profile, adding a
little to the amount of the data seems highly useful.
Using the same technique, it seems usefull to even produce a deceptive
profile as a defence. And, no, just knowing what is happening in general
does not mean that you can easily, if at all, recover the added keys.
--
Some Turkeys can fly, for short distances. If you are to depend on
birds for communication, if it's with turkeys, consider the
discussions that might occur while feasting on one.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Flattening of frequency distributions
Date: Sat, 17 Jun 2000 18:50:25 -0600
In article <[EMAIL PROTECTED]>, zzapzing
<[EMAIL PROTECTED]> wrote:
> I absolutely agree but someone will probably
> start screaming "Bandwidth, Bandwidth".
>
Bless their pointed heads. Effective security always has its costs; how
much can be done effectively with reasonable latitude is another question.
--
Some Turkeys can fly, for short distances. If you are to depend on
birds for communication, if it's with turkeys, consider the
discussions that might occur while feasting on one.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Flattening of frequency distributions
Date: Sat, 17 Jun 2000 18:52:20 -0600
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
> A normal compression algorithm doesn't have a secret key, thus
> the opponent can decompress just as well as the legitimate
> receiver....
Normal is not a reason, merely an excuse for doing things poorly.
--
Some Turkeys can fly, for short distances. If you are to depend on
birds for communication, if it's with turkeys, consider the
discussions that might occur while feasting on one.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: I Will Make ANY Software for Anybody
Date: Sat, 17 Jun 2000 19:00:03 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (TradersNYC) wrote:
> Hi,
>
> I manage a VAST number of programmers with a wide spectrum of skills covering
> virtually all aspects of software development. I can help you develop any
> software that you can imagine at an extremely low cost. If you have an idea of
> software you would like to develop or are currently developing, I can help you
> develop it with extreme efficiency of both time and money (No project is too
> small, or too large to develop). Anything from state of the art web sites, to
> handling part of your workflow (orders), to developing GPS software. . .
> anything can be developed in a short period of time at an extremely low cost.
>
> Please email me with your ideas/projects, and I will shortly respond with a
> time frame and a price quote for the development of your software.
Wanted: A good system and supporting programs for the wintel platform that
is entirely open to the understanding and dictates of the user and is
incorruptable by
external machines.
Delivery date?
--
Some Turkeys can fly, for short distances. If you are to depend on
birds for communication, if it's with turkeys, consider the
discussions that might occur while feasting on one.
------------------------------
From: [EMAIL PROTECTED] (S. T. L.)
Subject: Re: MD5 Expansion
Date: 18 Jun 2000 02:02:23 GMT
MD5 is on its last legs, right? Use SHA-1.
-*---*-------
S.T.L. My Quotes Page * http://quote.cjb.net * leads to my NEW site.
Pages up: 395 Quotes, 14 reviews of 165 science books, and a review of
the Foundation series. COMING UP: more science book reviews!
------------------------------
Subject: Re: MD5 Expansion
From: tomstd <[EMAIL PROTECTED]>
Date: Sat, 17 Jun 2000 19:02:50 -0700
[EMAIL PROTECTED] (S. T. L.) wrote:
>MD5 is on its last legs, right? Use SHA-1.
I don't see how you came to that conclusion.
Tom
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
Subject: Re: Cryptographic voting
From: zzapzing <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Date: Sat, 17 Jun 2000 19:17:42 -0700
Sundial Services <[EMAIL PROTECTED]> wrote:
>Ask any European who remembers World War II what he would think
about
>"relaxing" requirement #2.
>
>It is necessary to identify who has voted in order to correlate
counts
>of ballots with counts of voters who supposedly cast them. It
is also
>necessary that the ballot and the voter cannot be correlated.
>
>The root cause of the problem with electronic voting is that in
the end
>the records will be magnetic or optical -- with no physical
object to
>back them up. And it is a simple fact that magnetic or optical
records
>can be falsified or altered after the fact, much more easily
than can be
>a warehouse full of paper.
>
>Implicit in any electronic system is that the electronic system
has not
>been intentionally altered, tampered-with, or compromised by a
cunning
>individual. But let's face it, in the matters of voting and
political
>power, "How many millions [of dollars] do you require? Name
your price,
>two, five ten ... and no one will ever know. Really. Just do
it - we
>all make lots of money and you get more than your fair
share...." Yes,
>there are plenty of people who would consider that kind of
exchange to
>be ordinary business. A voting system has to withstand that.
>
>
>
>>zzapzing wrote:
>>
>> >1. It must be secret ballot
>> >2. Voters cannot be identified (by law)
>> >3. Voters cannot be deduced from the votes
>> >4. Votes must be verifiable (not altered) by anyone
>> >5. Voters cannot vote more than once
>> >6. The system requires no trust of anyone
>> >
>>
>> I agree but I would relax requirement #2.
>
>I think we are actually agreeing with each other.
When you "relax" a requirement *not* to identify
voters, it means that voters will be identified.
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: MD5 Expansion
Date: 18 Jun 2000 02:12:06 GMT
tomstd <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (S. T. L.) wrote:
> >MD5 is on its last legs, right? Use SHA-1.
>
> I don't see how you came to that conclusion.
Something to do with Dobbertin finding pseudocollisions in the
compression function, I think. And the hash output being too small.
(Then again, SHA has the same problem, just to a lesser extent.)
-- [mdw]
------------------------------
Subject: Re: quantum cryptography at nytimes.com
From: zzapzing <[EMAIL PROTECTED]>
Date: Sat, 17 Jun 2000 19:26:46 -0700
Roger Schlafly <[EMAIL PROTECTED]> wrote:
(snip)
> The beauty of the system is that two branches of a bank, say,
do not
> actually have to send the record of a transaction itself. The
two
>branches
> simply work up a long string of random numbers known only to
them,
Actually, I think my bank does this already ! :-)
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
Subject: Re: quantum cryptography at nytimes.com
From: zzapzing <[EMAIL PROTECTED]>
Date: Sat, 17 Jun 2000 19:36:40 -0700
<sarcasm>
Oh, yeah, and it would be Sooo much less expensive
to build a quantum cryptography line than it would
be to generate and store enough OTP bits for the
next 3 million years !
</sarcasm>
But perhaps quantum "cryptography" will find an
application in tamper/intruder detection.
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
Subject: Re: MD5 Expansion
From: tomstd <[EMAIL PROTECTED]>
Date: Sat, 17 Jun 2000 19:40:04 -0700
[EMAIL PROTECTED] (Mark Wooding) wrote:
>tomstd <[EMAIL PROTECTED]> wrote:
>> [EMAIL PROTECTED] (S. T. L.) wrote:
>> >MD5 is on its last legs, right? Use SHA-1.
>>
>> I don't see how you came to that conclusion.
>
>Something to do with Dobbertin finding pseudocollisions in the
>compression function, I think. And the hash output being too
small.
>(Then again, SHA has the same problem, just to a lesser extent.)
>
Dobbertin did not break the full MD5. Simmilarly Chabuad and
Joux found collisions in SHA-0.
I could argue that SHA-1 is in risk of compromise because of
this, just like you could argue that MD5 is in risk because of
the collision in MD5's compression.
At anyrate I would use TIGER/192 just to spite both arguments.
Tom
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
Subject: Re: GeekPress: Will Cyber Criminals Run the World?
From: zzapzing <[EMAIL PROTECTED]>
Date: Sat, 17 Jun 2000 19:45:56 -0700
Hmmm ... Maybe I don't quite understand the
pricing schedule. Are you saying it is 10k
for 2000 chips? Actually I only needed about
three chips. I would have to Ebay the rest.
Do you think there would be a market?
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: MD5 Expansion
Date: 18 Jun 2000 02:55:54 GMT
tomstd <[EMAIL PROTECTED]> wrote:
> At anyrate I would use TIGER/192 just to spite both arguments.
what about RIPE-MD ?
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: MD5 Expansion
Date: 18 Jun 2000 02:52:22 GMT
tomstd <[EMAIL PROTECTED]> wrote:
> Dobbertin did not break the full MD5.
I never claimed that he did, and you'd do well not to try implying that
I did. He found pseudocollisions in the compression function, just as I
said.
> Simmilarly Chabuad and Joux found collisions in SHA-0.
>
> I could argue that SHA-1 is in risk of compromise because of
> this, just like you could argue that MD5 is in risk because of
> the collision in MD5's compression.
You could do. The difference is that the NSA fixed SHA, *before* the
vulnerability was noticed (and indeed Cahbaud and Joux were prompted by
the change to try to find the weakness), while MD5 has not been fixed at
all.
Note also that RSA Security Inc. have been recommending against the use
of MD5 in new applications for years now.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To:
alt.privacy,alt.privacy.anon-server,alt.security.pgp,comp.security.firewalls
Subject: Re: Evidence Eliminator Dis-Information Center
Date: Sat, 17 Jun 2000 20:06:03 -0700
If format is so effective, how come there are so many unformat utilities?
They work very well (at least Norton's does). Insta-stuff back. I always
thought only fdisk does a true HD wipe, but (sigh), not even that is true.
Thanks (or no thanks, as the case may be) to programs such as Powerquest
Lost&Found, even a partitioned HD can be unpartitioned with all the contents
intact.
So there!
"tomstd" <[EMAIL PROTECTED]> wrote:
> >What you may or may not believe has no relationship to what is
> >true. Format will not wipe a fixed disk.
> For what *i* need format is perfectly fine.
------------------------------
** 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 (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
