Cryptography-Digest Digest #479, Volume #11 Mon, 3 Apr 00 20:13:01 EDT
Contents:
Re: I will make ANY software for ANYBODY (Paul Schlyter)
Re: Magnetic Remenance on hard drives. (was: Re: Evidence Eliminator - Who is trying
to silence our program? It's not working...) (EE Support)
Re: Magnetic Remenance on hard drives. (was: Re: Evidence Eliminator - Who is
trying to silence our program? It's not working...) (EE Support)
Re: Magnetic Remenance on hard drives. (was: Re: Evidence Eliminator - Who is trying
to silence our program? It's not working...) (EE Support)
Re: I will make ANY software for ANYBODY (Jerry Coffin)
Re: Key exchange using Secret Key Encryption (John Savard)
Re: Key exchange using Secret Key Encryption (John Savard)
Re: new Echelon article ([EMAIL PROTECTED])
Keeping numbers small in RSA ([EMAIL PROTECTED])
Re: Q: Entropy ("Joseph Ashwood")
Re: novice in crypting ("Joseph Ashwood")
Re: Magnetic Remenance on hard drives. (was: Re: Evidence Eliminator - Who is trying
to silence our program? It's not working...) (Andrew Carol)
Re: novice in crypting (Tom St Denis)
Simple authentication protocol: any good? (David S. Harrison)
Re: Hysteresis? (Alan Gottschald)
Re: Keeping numbers small in RSA (Tom St Denis)
Re: Magnetic Remenance on hard drives. (was: Re: Evidence Eliminator - (Tom St
Denis)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: I will make ANY software for ANYBODY
Date: 3 Apr 2000 22:23:45 +0200
In article <[EMAIL PROTECTED]>,
Jerry Coffin <[EMAIL PROTECTED]> wrote:
> In article <8c8hvc$pnm$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> says...
>
> [ ... ]
>
>> Thanks. I'd like the Windows-2000 operating system ported to the
>> ENIAC. I'd like it to be finished the day after tomorrow, and this
>> project should cost no more than $2. I request it to be delivered on
>> ENIAC-readable paper tape. No bugs will be tolerated.
>
> I'll be happy to take this on. Of course, you have to supply the
> working ENIAC, its staff of full-time technicians to keep it running,
> and (of course) getting my house wired to power it... <G> Just to
> make sure the staff is up to speed, we'll need an EDSAC, an EDVAC and
> a Mark I for a month ahead of time as well...
While the original hardware for these probably aren't in working order,
there may very well be emulators for these somewhere on the Web, It
shouldn't be harder to emulate an ENIAC than an Enigma....
Are you willing to make Windows-2000 run on an ENIAC emulator?
If so, by writing new ENIAC emulator on other computers (e.g. the
PalmPilot or the HP-48/49) one would get Windows-2000 ported to
these machines as well.... :-)))))
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: EE Support <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy,alt.security.pgp
Subject: Re: Magnetic Remenance on hard drives. (was: Re: Evidence Eliminator - Who is
trying to silence our program? It's not working...)
Date: Mon, 03 Apr 2000 23:32:05 +0100
Reply-To: [EMAIL PROTECTED]
On Wed, 15 Mar 2000 22:15:17 +0000, Withheld <[EMAIL PROTECTED]>
wrote:
>[cut]
>>I fantasize that your data is stored on hard disk tracks for a long time
>>before it gets wiped (esp. with new users of your still improving
>>software). So the magnetic data will leak over to the surface area next
>>to the track. Then you overwrite with zero's once! That leaves traces of
>>the previous data next to the track. Above a certain treshold the data
>>will have been 1 and below it will have been 0. Not very commercially
>>intesting until your product apeared, but it doesn't sound difficult to
>>recover IMO.
>>
>>Better would be to steal the random data collection from the source of
>>pgp 6.5.1i or use Jarrow from counterpane to generate some
>>cryptographically strong random data and use it to overwrite previous
>>data on the harddisk. It doesn't have to be 10Gig strong for a 10Gig
>>harddrive, but hashing the initial random value a few times should do
>>the job. At no loss of speed (maybe 0.01% due to the hashing) you now
>>overwrite the previous data more securely than just by overwritting with
>>zero's only. That would be great.
>>
>>Maybe the area close to the written track will still get magnetized by
>>the previous data, but you can't just set a treshold. You'll have to set
>>at least three treshold. One for going from 0->0 (very low magnetic
>>treshold), 0->1 (higher), 1->0 (still higher depending on time of last
>>wipe) and 1-1 (highest).
>
>I hope I'm not being ignorant here, but is a stream of random data
>entirely necessary? Given you are trying to mask residues from previous
>data, wouldn't a succession of alternating patterns 101010101010...
>followed by 0101010101... do the same thing - blur any residues until it
>was meaningless. Using memory blocks you could define this pattern and
>then dump it into disk blocks wherever you wanted. Once this pattern had
>been followed a suitable number of times it could all be overwritten
>with 00000000 to clear the disk.
>
>Unless I've misunderstood the point, this would result in so many
>possible thresholds for what was there before the multiple wipe passes
>that it would be impossible to get anything meaningful from it at all?
>
>[cut]
Hi
A problem is RLL and encoding etc.
The data sent to the disk isn't the same as the data physically
written.
Disks use encoding systems to maximise the on/off states available to
the heads at a certain speed.
What goes to the disk as
010101010101010101010101010
Is magnetically saved more like
000000011111100000111111111
We still think secure software overwriting trashes the data and nobody
has found a practical way to beat our Evidence Eliminator software
yet.
--
Regards,
EE Support
[EMAIL PROTECTED] (remove NO_SP_AM for e-mail)
http://www.evidence-eliminator.com/
------------------------------
From: EE Support <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy,alt.security.pgp
Subject: Re: Magnetic Remenance on hard drives. (was: Re: Evidence Eliminator - Who
is trying to silence our program? It's not working...)
Date: Mon, 03 Apr 2000 23:32:07 +0100
Reply-To: [EMAIL PROTECTED]
On Sun, 02 Apr 2000 22:49:02 GMT, [EMAIL PROTECTED] (Svend Olaf
Mikkelsen) wrote:
>Thor Arne Johansen <[EMAIL PROTECTED]> wrote:
>
>>I would challenge anyone to produce evidence that overwritten data, can
>>be recovered. There seem to be some sort of consensus that reading
>>overwritten data can easily be recovered. Most of the descriptions on
>>how to do this is quasi-science at the best, and mindless techno-ranting
>>at the worst.
We concur. There is no evidence that properly overwritten data is
practially recoverable.
It is on this principle that we made the Evidence Eliminator.
We challenge anybody to beat our software and will take pleasure in
upgrading it to defeat their efforts.
--
Regards,
EE Support
[EMAIL PROTECTED] (remove NO_SP_AM for e-mail)
http://www.evidence-eliminator.com/
------------------------------
From: EE Support <[EMAIL PROTECTED]>
Subject: Re: Magnetic Remenance on hard drives. (was: Re: Evidence Eliminator - Who is
trying to silence our program? It's not working...)
Date: Mon, 03 Apr 2000 23:32:08 +0100
Reply-To: [EMAIL PROTECTED]
Hi, good debate.....
--
On 02 Apr 2000 19:27:58 EDT, [EMAIL PROTECTED] (Guy Macon) wrote:
>In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Thor Arne Johansen) wrote:
>>
>>I would challenge anyone to produce evidence that overwritten data, can
>>be recovered. There seem to be some sort of consensus that reading
>>overwritten data can easily be recovered. Most of the descriptions on
>>how to do this is quasi-science at the best, and mindless techno-ranting
>>at the worst.
<EE Support>
That's correct.
(Guy Macon) wrote:
>
>Absense of evidence is not evidence of absense.
>
<EE Support>
Sorry but we disagree. Absense of evidence is evidence of absense of
evidence.
(Guy Macon) wrote:
>There is good reason to believe that the evidence you seek is classified.
>
<EE Support>
What good reason? Please, impress us.
(Thor Arne Johansen) wrote:
>>Mr. Gutmans paper is the best description of secure deletion I've seen
>>so far (even though I still think overwriting is a secure way to erase
>>data from magnetic media). However the paper is not a writeup on
>>successful recovery of overwritten data, it is merely describing some of
>>the processes and techniques to consider.
>>
>>Why recovering overwritten data is almost impossible:
>>NONLINEARITY, Spindle Jitter, Clock Jitter, PRML encoding, poor signal
>>to noise, correlated noise.
>
<EE Support>
NONLINEARITY. Do you refer to the unevenness of the magnetic media?
(Guy Macon) wrote:
>These effects, when they happen during the original writing or the
>attempted overwriting, make it *easier* to recover data. If the
>overwriting bit is off center and only partially covers the original
>bit, the job of recovery is made simpler.
>
>These techniqes do not apply if you use the methods detailed by Peter
>Gutmann in [ http://www.cs.auckland.ac.nz/~pgut001/secure_del.html ].
>Magnetic force microscopy lacks nonlinearity, Spindle Jitter, Clock
>Jitter, PRML encoding, poor signal to noise, and correlated noise.
>
<EE Support>
We disagree. Magnetic force microscopy recovers all that was written
including all faults and irregularities.
(Thor Arne Johansen) wrote:
>>Now, this could also be judged as techno ranting :), but if you look
>>into it, these things makes it incredibly hard (almost impossible), to
>>recover overwritten data.
>
<EE Support>
We agree.
We maintain it's not possible and challenge anybody to prove in a
repeatable manner they can defeat our Evidence Eliminator software.
(Guy Macon) wrote:
>I have a lot of obsolete and partially related experience in this area
>as an engineer who has worked with the original 30MB/30MB Winchester
>mainframe disk drives, 9 track mainframe tape drives, timelapse video
>recorders, phillips cassette data recorders, spacebourn data recorders
>for the space shuttle,
<EE Support>
Sorry, who's your boss again?
and most recently DVD-RAMs. None of this
>experience is with modern disk drives, but I understand the basics,
>and have recovered "erased" data from these various recoding devices
>using fine iron powder and a good microscope. I have also failed to
>recover the data many times. This opsolete technique wouldn't work
>withy modern disk drives, of course - a quick calculation shows that
>the features are too small for that. It is important to realize that
>we had plenty of nonlinearity, Spindle Jitter, Clock Jitter, poor
>signal to noise, and correlated noise, and that this did not prevent
>recovery.
<EE Support>
Please, beat our Evidence Eliminator today and publish repeatable lab
test reports.
We'll give you a free copy if you can beat it. Hows that for a deal?
--
Regards,
EE Support
[EMAIL PROTECTED] (remove NO_SP_AM for e-mail)
http://www.evidence-eliminator.com/
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: I will make ANY software for ANYBODY
Date: Mon, 3 Apr 2000 16:35:07 -0600
In article <8caukh$52f$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
[ ... ]
> Are you willing to make Windows-2000 run on an ENIAC emulator?
No, of course not. It has to be the real thing... <G>
> If so, by writing new ENIAC emulator on other computers (e.g. the
> PalmPilot or the HP-48/49) one would get Windows-2000 ported to
> these machines as well.... :-)))))
Why start with such an overpowered machine as one of these? Maybe an
ENIAC emulator on my HP-41C would be worthwhile... <G>
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Key exchange using Secret Key Encryption
Date: Mon, 03 Apr 2000 22:54:54 GMT
[EMAIL PROTECTED] wrote, in part:
>I am looking for a method of key exchange that only involves secret key
>encryption. The method should also be immune to man-in-the-middle
>attack. The scenario I am looking at is described below.
>Alice and Bob are complete strangers and have only one channel of
>communication. The Channel being the Internet. They only have at their
>disposal a secret key encryption method. For the sake or argument, this
>method is Bob Schnier's Twofish. It can be assumed that Alice and Bob
>are both connected to the internet concurrently, so multiple pass
>protocals can be used. How can Alice and Bob start communicating and
>protect their messages.
That is a fair question to ask (at least from a novice), but as you
probably have seen from the replies, nobody knows a way to do this.
In fact, even _with_ public-key methods, to prevent a
man-in-the-middle attack the normal practice is to use another
channel, which does not have to be secret, but which has to be
resistant to tampering, to exchange key certificates: signed documents
from a trusted authority indicating that a given public key actually
belongs to a given party.
However, some protocols have been proposed that obtain resistance to a
man-in-the-middle attack in other ways than by using another channel
for certificates, so if you relax your conditions to allow public-key
techniques, there *might* be something that would meet your other
requirements. (The ones I remember seeing, though, only make MITM
harder, not impossible.)
If there were a way to do this, it would revolutionize cryptography,
but this is generally felt (although it has not been proven) to be
impossible in principle.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Key exchange using Secret Key Encryption
Date: Mon, 03 Apr 2000 22:56:18 GMT
[EMAIL PROTECTED] wrote, in part:
>Strangely enough, many "secure" connections, such as those used in
>browsers, completely ignore the man-in-the-middle problem.
Many do, but I wouldn't use browsers as an example, as they have
certificates built in.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To:
alt.politics.org.cia,alt.politics.org.nsa,alt.journalism.print,alt.journalism.newspapers
Subject: Re: new Echelon article
Reply-To: [EMAIL PROTECTED]
Date: Mon, 03 Apr 2000 22:22:36 GMT
Just a thought ...
Has anyone noticed that while the CIA and NSA are busy laughing and
claiming that the EU report on Echelon is full of it, they are
lobbying like gangbusters in the press and behind the scenes to thwart
the creation of an EU committee to investigate the allegations???
On Wed, 15 Mar 2000 00:19:02 GMT, [EMAIL PROTECTED] wrote:
>
>
>http://www.wired.com/news/politics/
>0,1283,34932,00.html
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Keeping numbers small in RSA
Date: Mon, 03 Apr 2000 22:48:30 GMT
I am having some trouble calculating result = A*B mod n as part of a
modular exponentiation. The tempory value for A*B gets too big too
store before the modular reduction. I am limited to 32 bit storage for
the tempory register.
Can anybody suggest a technique(s) or algorithm to reduce these
numbers, ideally to allow large A and B usage.
Thanks in advance.
Rick
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Q: Entropy
Date: Mon, 3 Apr 2000 15:47:57 -0000
> A further question: Does a normal English message have
entropy?
Yes, it typically has between 1 and 2 bits of entropy per
character, depending on who wrote it. It is quite easy to
establish that there must be some entropy, otherwise
different texts could not be written, establishing the
actual amount is quite difficult and includes computing the
odds of statements of a given length, and determining from
that the entropy of that length, then comparing several of
those lengths to create an estimate.
> Presumably yes. Now if I change some words but retain the
> grammatical structures, does the new (artificial) message
(that
> is not quite common) have a larger/smaller entropy? Or is
it rather
> the case that one has no exact methodology to deal with
that issue?
If there is a 1 to 1 relationship between your new language
and it's corresponding English version the entropy of the
new language message will be the same as the entropy of the
english version, if the translation is more complex it would
take more analysis to estimate the entropy. However the
language occurance would make for higher entropy of language
choice, for example, if it is known that I speak only
English (and it's slang variants), there is little inherent
entropy in my language choice. OTOH if I speak All variant
of english, chinese (yes all however many variants),
spanish, french, italian, hindi, COBOL, C, x86 assembly,
etc, etc etc. it becomes more difficult to determine the
language I will be speaking, making for some apparent
entropy that is not actually present in my speech.
Joe
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: novice in crypting
Date: Mon, 3 Apr 2000 15:56:26 -0000
Well if you can stand a huge amount of reading Counterpane
(http://www.counterpane.com) has an astonishingly huge list
of cryptography related papers at
http://www.counterpane.com/biblio/ have at it, there's 1339
papers there, and most of them are at least 20 pages. If
you're not up for all that, perhaps you'd like to be more
specific? Are you interested in encryption algorithm? Hash
Algorithms? Public Key? Private Key? Attacking algorithms?
Protocol development? Protocol Attacking? etc, etc etc. Many
of us are more than willing to help, but I don't think
there's a single person here that has read and can remember
everything in all 1300+ papers on counterpane's site.
Joe
"Lionel Firmery" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Hi every body!!!
>
> I'm a novice in the great domain of crypting. Can someone
give me sites
> for helping me in starting?? I'm currently making a
crypting program (in
> C), but i don't know very far the XOR usage...
>
> many thanks!!
>
------------------------------
From: Andrew Carol <[EMAIL PROTECTED]>
Subject: Re: Magnetic Remenance on hard drives. (was: Re: Evidence Eliminator - Who is
trying to silence our program? It's not working...)
Date: Mon, 03 Apr 2000 16:12:00 -0700
In article <[EMAIL PROTECTED]>, EE Support
<[EMAIL PROTECTED]> wrote:
> (Guy Macon) wrote:
> >
> >Absense of evidence is not evidence of absense.
> >
>
> <EE Support>
> Sorry but we disagree. Absense of evidence is evidence of absense of
> evidence.
That's not the same thing.
The original comment "Absense of evidence is not evidence of absense."
means that just because we've never seen the thing doesn't mean that
the thing does not exist.
Your comment "Absense of evidence is evidence of absense of evidence."
means that the fact we can't see the thing is evidence that we can't
see the thing. That's a tautology. It means nothing. It says nothing
about whether or not the thing exists.
That said, the very people who are likely to really know are not
talking. I am sure that when I worked with classified harddrives in
the military there were VERY strict rules about declassification, none
of which left the disk in a useable condition.
Oh well......
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: novice in crypting
Date: Mon, 03 Apr 2000 23:41:15 GMT
Lionel Firmery wrote:
>
> Hi every body!!!
>
> I'm a novice in the great domain of crypting. Can someone give me sites
> for helping me in starting?? I'm currently making a crypting program (in
> C), but i don't know very far the XOR usage...
A seriously good investment is "Applied Cryptography". It's about 50
bucks or so, but a really good book that will accelerate your learning
of the whole cryptography scene.
If you want example source code of a cryptographic library you can check
out my library at
http://24.42.86.123/cb.html
It has symmetric and asymmetric ciphers, random number generators,
hashes, and the whole nine yards. Best of all it's free and all the
spiffy source is there.
Tom
------------------------------
Subject: Simple authentication protocol: any good?
From: [EMAIL PROTECTED] (David S. Harrison)
Date: 03 Apr 2000 23:45:38 GMT
I have need for a simple authentication protocol that can be used
to insure that a client, speaking to a custom server, cannot be
easily emulated. Due to the nature of the connection between client
and server, I must assume that it is very easy to watch the traffic
between the two.
I have developed a simple protocol that I think is minimally secure.
The goal here is to make it non-trivial to break the authentication.
It doesn't have to be provably secure. I have not formally studied
cryptography, so I suspect my approach may have obvious flaws that
I haven't thought of. Without further preface, I will describe
the protocol below.
The protocol is challenge and response and its based upon the
idea of shared functions in the client and server. Both client
and server have implementations of a function, f(n), that computes
a reasonably obscure function of a 32-bit integer. When the client
first connects to the server, the server responds by sending
a pseudo-random integer computed via Knuth's linear congruential
algorithm that is seeded using the current time of day. The
client computes f(n) on this number and sends it back to the
server. The server compares its computation of f(n) with the
submission from the client. If they match, the client is
considered valid and the server proceeds to perform the function
requested by the client.
In my analysis, this protocol seems ok. It's primary weakness is
the shared function in the client and server. If an attacker can
deduce this function, then the protocol has been compromised and
is no longer useful. Since the connection is open between client
and server, an attacker can watch n,f(n) tuples go by as
valid client/server pairs conduct their business. Fortunately, in
this application, such connections are not frequent. Thus, I
don't expect an attacker would have very many samples to work
with to deduce the function. In high cryptography circles, I
am sure there are probably ways to deduce such functions given
a small number of samples. But for a causal attacker, I am
imagining this should be reasonably secure.
Now, what about the shared function? I imagine that this function
is itself a pseudo-random function. There are lots of possibilities.
One function might be to use the Knuth algorithm with a seed that
is computed from the xor of a fixed seed and the input number. Thus,
the actual shared component between the client and server is the
fixed seed. This should produce n,f(n) tuples that look random.
Given the description, am I on the right track or completely out
to lunch? Opinions gratefully accepted.
David S. Harrison
([EMAIL PROTECTED])
------------------------------
From: net.netscape@agottschald (Alan Gottschald)
Crossposted-To: alt.privacy,alt.security.pgp
Subject: Re: Hysteresis?
Date: Tue, 04 Apr 2000 00:00:09 GMT
I seem to remember in the good old days when sercurity was less of an
issue we had a nice little utility from Norton I think, I even wrote
one my self, that would write a random pattern over selected files or
even disks. Now I'm not saying that it is imposible to to read what
what's left but I suspect that is would be as good as.
Remember if you want to keep something secret don't put it on a
computer, don't write it down and don't tell anyone.
"Scotty" <[EMAIL PROTECTED]> wrote:
>
>G. R. Bricker wrote in message <01bf9d2d$df081040$4b06ebd0@default>...
>>I surmise that hysteresis effects would leave traces of the previous
>>condition of the "bit" on magnetic media. A bit which has been overwritten
>>once in its lifetime would probably have a measurable trace of residual
>>magnetism from its previous condition. However, how you would measure this
>>I don't know. The level would be pretty low. As for bits which have been
>>overwritten many times, I have absolutely no idea how each separate "write"
>>could be determined.
>> G.R. Bricker
>
>When a 1 overwrites a 1 you get about 1.05 and 0.95 when it overwrites a 0.
>The drive circuitry digitises that to give 1. That 10% difference is easy to
>measure if you sample it with an oscilloscope before the signal is processed
>by the drive circuitry. This is not rocket science.
>
>
>
>
>>
>>Thor Arne Johansen <[EMAIL PROTECTED]> wrote in article
>><[EMAIL PROTECTED]>...
>>> Hello all,
>>>
>>> "Thomas J. Boschloo" wrote:
>>> >
>>> > EE Support wrote:
>>> > >
>>> > > We contend it does not. Overwriting all zeros practically trashes
>>> > > files on the disk.
>>
>
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Keeping numbers small in RSA
Date: Tue, 04 Apr 2000 00:01:07 GMT
[EMAIL PROTECTED] wrote:
>
> I am having some trouble calculating result = A*B mod n as part of a
> modular exponentiation. The tempory value for A*B gets too big too
> store before the modular reduction. I am limited to 32 bit storage for
> the tempory register.
> Can anybody suggest a technique(s) or algorithm to reduce these
> numbers, ideally to allow large A and B usage.
> Thanks in advance.
Use a large number library such as MPI :-)
http://linguist.dartmouth.edu/~sting/mpi/
Generally both 'p' and 'q' in RSA have to be about 384 bits each to make
the algorithm secure. So they ain't gonna fit in a 32-bit register.
Tom
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy,alt.security.pgp
Subject: Re: Magnetic Remenance on hard drives. (was: Re: Evidence Eliminator -
Date: Tue, 04 Apr 2000 00:05:04 GMT
EE Support wrote:
>
> Hi
> A problem is RLL and encoding etc.
>
> The data sent to the disk isn't the same as the data physically
> written.
>
> Disks use encoding systems to maximise the on/off states available to
> the heads at a certain speed.
>
> What goes to the disk as
> 010101010101010101010101010
>
> Is magnetically saved more like
> 000000011111100000111111111
Technically interesting.
>
> We still think secure software overwriting trashes the data and nobody
> has found a practical way to beat our Evidence Eliminator software
> yet.
Because you sell your software, this is technically spamming the group.
Which is highly ironic since your email address has a 'anti-spam' filler
in it.
Try releasing a freeware version of your software with fully document
source code. Then you can talk about your software here.
BTW burning the hard disk at 1000c is still much more effective then any
software :-)
Tom
------------------------------
** 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
******************************
