Cryptography-Digest Digest #857, Volume #13 Sat, 10 Mar 01 23:13:01 EST
Contents:
Re: Text of Applied Cryptography .. do not feed the trolls (SCOTT19U.ZIP_GUY)
OverWrite: best wipe software? (Anthony Stephen Szopa)
Re: Noninvertible encryption ("Trevor L. Jackson, III")
Re: => FBI easily cracks encryption ...? (Phil Zimmerman)
Re: Noninvertible encryption (SCOTT19U.ZIP_GUY)
Re: Text of Applied Cryptography .. do not feed the trolls ("Tom St Denis")
Re: The Foolish Dozen or so in This News Group (Anthony Stephen Szopa)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: Text of Applied Cryptography .. do not feed the trolls
Date: 11 Mar 2001 03:02:27 GMT
[EMAIL PROTECTED] (Tom St Denis) wrote in
<CFAq6.9449$[EMAIL PROTECTED]>:
>
>"Dan Beale" <[EMAIL PROTECTED]> wrote in
>message news:ZCAq6.1295$Q7.26476@stones...
>>
>> "Sundial Services" <[EMAIL PROTECTED]> wrote in message
>> news:[EMAIL PROTECTED]...
>> > Do not feed the trolls, Tom. They love to eat and make noise.
>> >
>> >
>> > Tom St Denis wrote:
>> > >
>> > > "Ryan M. McConahy" <[EMAIL PROTECTED]> wrote in message
>> > > news:3aa9594e$0$62146$[EMAIL PROTECTED]...
>> > > > I am _not_ a troll! If I can't find it from you, I'll find it
>> somewhere
>> > > > else.
>> > >
>> > > What? Applied Crypto is not free so why ask here?
>> > >
>> > > Tom
>> >
>>
>> people may not agree with giving away the (possibly pirated) text, but
>> how about the source code, which (last time I checked) was not
>> available to non-Americans.
>
>I dunno who wrote the code in the back of Applied crypto BUT IT SUCKS!.
>It's the most sloppiest poorly written code I have ever seen. My blind
>dog with only three legs (that we call "tripod") can write better code
>by randomly typing keys on the keyboard.
I don't know but from your comments maybe its some code I wrote.
If it works it could be mine.
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: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: OverWrite: best wipe software?
Date: Sat, 10 Mar 2001 19:19:35 -0800
OverWrite: best wipe software?
I think I have made Ciphile Software's OverWrite Security Utility
Version 1.2 perhaps the best wipe utility available for Windows.
Read below and you tell me. Now available for direct download at
www.ciphile.com
In addition to the prior instructions here are the new
recommendations and facilities. What have I forgotten?
"NOTE: For best results this program should be used only with
Windows OSs and there should be no other programs running while this
program is running. Maximum security from using this software
results when overwriting files that are stored on 1.44MB floppy disks.
Therefore, your most sensitive files should be written directly to
1.44MB floppy disks if you must be as absolutely sure as possible
that this data is as nearly impossible as possible to recover once
overwritten using this software. SCSI hard drives are not
recommended. Nor are compressed drives. I use this software to
overwrite files on my own IDE hard drives.
RECOMMENDATIONS: You are probably familiar with MS Word. Start a
new composition then save it. Then close the file. Now open it
again. You will notice that a swap file has been created:
~$Doc1.doc if you saved the file as Doc1.doc. When you are through
and close this file the swap file ~$Doc1.doc is deleted. But the
~$Doc1.doc data is still on your hard drive. So if you decide later
to overwrite the Doc1.doc file you will not be overwriting previously
removed ~$Doc1.doc data that is still on your hard drive. But take
notice that even MS Word creates this swap file in the directory
where the current document is stored.
If you are serious about making sure that any data that has been
saved to your hard drive is removed when you overwrite it using
Ciphile Software's OverWrite Security Utility program then you
should follow these specific recommendations.
You should create a hard drive partition dedicated to storing and
processing sensitive data. All sensitive data that you create or
save or process with your computer should be done only in this
dedicated hard drive partition.
Now here is how you use this dedicated hard drive partition. For
example purposes, make the dedicated hard drive partition at least
and about 18,144,000 bytes long. Let's say your system calls this
partition hard drive H:\. Now save 14 files of 1,296,000 bytes each
called TFile1, TFile2, TFile3, and so on to hard drive H:\. Now use
the OS delete function to remove only TFile2 through TFile13 from
H:\. Got it? Now use this freed space available on H:\ for all of
your secure data processing, etc.
What does this do for you? Primarily it does two things. First it
pretty much assures you that any processing you do on this dedicated
hard drive H:\ will be confined to drive H:\. Not only is the data
processing confined to drive H:\ but it is confined to the free space
where you deleted TFiles 2 - 13. So you know where any writes are
being made to your hard drive: only on drive H:\ and only within
the free space made available from the deletion of TFiles 2 - 13.
Remember the MS Word example? As long as you are using IDE hard
drives in a non RAID set up I am unaware of any programs as simple
as OverWrite that will go to another hard drive to carry on
processing when you originate the executable program from and save
to this one dedicated drive H:\. If other simple programs do go to
other hard drives they are most likely going to require the
configuration to be specifically set up to do this. In other words,
you will have to set this up beforehand. Just don't do this with
drive H:\
Secondly, by dedicating drive H:\ as described above, you insure the
best chances of all of your data being thoroughly overwritten when
using Ciphile Software's OverWrite Security Utility program. Here
is why. You are confining where the OS can process your confidential
data to just the area freed up on drive H:\. For a tighter example,
instead of deleting TFiles 2 - 13 just delete TFile8. This will free
up only 1,296,000 bytes of space on H:\ whereas all the other space
will be taken up by the other 13 TFiles. The OS is confined to this
one relatively small area of 1,296,000 bytes on drive H:\ to do all
its processing. This helps insure that the file you intend to
overwrite is being properly overwritten with regard to OS and
hardware optimization. To make completely sure that your file on
the hard drive is the specific area being overwritten as you intend,
you can either append into the file you were writing in and bring
the byte count of this file up to the remaining available space in
H:\ or you can use the OS delete function and delete the file you
want to overwrite. Then write the TFile8 back to H:\. Then use the
OverWrite program to overwrite this TFile8. There is no other place
to go when overwriting TFile8 because all the remaining space on H:\
is taken up by the other 13 TFiles. And since the space TFile8 now
occupies includes the space where your file was written, your file
space is necessarily overwritten when TFile8 is overwritten.
Periodically, you may just want to overwrite the entire H:\ partition.
Simply delete all the files in H:\. Then write a MixFile.otp file of
18,144,000 bytes to H:\. This will occupy the entire H:\ partition.
Then use the OverWrite program to overwrite this MixFile.otp. The OS
has no place to go except to overwrite the entire partition.
As you may have noticed much of this discussion has been making an
underlying assumption that because of OS and hardware optimization
that sometimes and in some circumstances the actual overwrite may not
be taking place exactly as thought and intended. You have noticed
that I have described a procedure that will make sure that the
overwrite does take place as desired. But there have been some
additional improvements to Version 1.2 of OverWrite.
Here they are in a nutshell fast and furious: in each of the 27
passes of the overwrite process there is an fopen, overwrite,
fflush, fclose, and ProcessMessages command. Each time, these are
followed by a sleep command that suspends program operation for a
specified number of seconds and this allows the OS to take over.
This amount of time can be anywhere from 2 to 120 seconds and is
user determined. This should provide the OS and hardware with more
than enough time to commit and effect an overwrite. On my two
systems a sleep(4) seems like enough. This is your decision to
make. I look at the hard drive indicator light and listen to the
hard drive and even feel the hard drive bay for indications that
the write is physically taking place.
Where do you get the TFiles and MixFile.otp? You can generate these
using Ciphile Software's OAP-L3 or OAR-L3 software available from
www.ciphile.com from the Downloads Currently Available web page.
Also, you can generate files of any length by being creative with
the Utility files included with these two software programs.
If you follow the above recommendations it leaves very little if
any wiggle room for the OS or hardware to forestall any overwrite
operation or not to overwrite your intended file.
Here is how you input the sleep parameter in seconds: Use NotePad
or WordPad and create a file called VarDur.txt and place it into your
H:\ drive or into the drive / folder / directory where the file is
you want to overwrite. Write no more than three digit characters
into this file. This will be how many seconds you want the program
to suspend using the sleep function between each of the 27 overwrite
passes. The default is 2 seconds. 2 seconds will be used if the
number you enter in VarDur.txt is less than 2 or if the file does
not exist. The maximum three digit value is 120 seconds. If you
enter three digits greater than 120 then 120 will be used. Only
three characters will be read from the VarDur.txt file and only
digits will be accepted. All other characters will be ignored.
You will see improvements in the program user interface with
OverWrite Version 1.2. There is a progressbar, a percentage label,
a pass label and a sleep duration label all to indicate to the user
the parameters and progress of the overwrite process. See below
for other instructions.
I know that I could have made a better interface and written better
instructions but this is freeware and I have limited time. But I
think you all now have maybe the best overwrite program available
if used properly.
Take as much care as you think you should."
Let's see you get out of this box.
------------------------------
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Noninvertible encryption
Date: Sun, 11 Mar 2001 03:19:59 GMT
Paul Lutus wrote:
> "John R Ramsden" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
>
> > > The idea of modern cryptographic methods is to make it *impractical*
> > > to decode the message by direct, naive attack. It still must be
> > > possible for the intended recipient to decode the message.
> >
> > Mind you, there's no reason why the sender of a text message couldn't
> > start by running a program to intersperse short sequences of random
> > letters all through the message such that the overall frequencies of
> > letters and letter groups would be made unpredictable, while at the
> > same time the recipient could still interpret the decrypted message
> > "semantically" and isolate the meaningful text from the extra noise.
>
> The problem with this approach is that anyone could extract the message by
> looking for the words immersed in the random letter sequences (or using a
> computer program to locate identifiable dictionary words). In other words,
> the role played by a password would not be present.
It would even be possible to use a tool such as CorrectText(tm), a grammar
corrector from HMCO, to filter out words formed by accident. This would still
be syntax filtering rather than semantic filtering, but I'd bet it would be
quite effective.
------------------------------
Subject: Re: => FBI easily cracks encryption ...?
From: Phil Zimmerman <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,talk.politics.crypto
Date: Sun, 11 Mar 2001 03:16:00 GMT
What encryption was Hansen using that it was so easily cracked?
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To: sci.math
Subject: Re: Noninvertible encryption
Date: 11 Mar 2001 03:11:02 GMT
[EMAIL PROTECTED] (Fred Galvin) wrote in
<[EMAIL PROTECTED]>:
>On Sat, 10 Mar 2001, John R Ramsden wrote:
>
>> Mind you, there's no reason why the sender of a text message
>> couldn't start by running a program to intersperse short sequences
>> of random letters all through the message such that the overall
>> frequencies of letters and letter groups would be made
>> unpredictable,
>
>Isn't that what compression coding does? Turn a normal message into
>something that approximates a random sequence of bits?
>
>> while at the same time the recipient could still interpret the
>> decrypted message "semantically" and isolate the meaningful text
>> from the extra noise.
>>
>> I guess the main disadvantage of this would be to increase the
>> message length, and introduce the possibility of ambiguity or
>> misinterpretation especially if the original text itself included
>> "random" letters such as vehicle licence plates.
>
>I guess compression codes are supposed to be invertible, and (as their
>name suggests) decrease the message length. But I haven't had lesson
>one in the subject either.
>
I think compression with encryption following is a greatly over
looked topic. Compression should help before encryption. But many
compression methods actually add information to a file so that it
can in theory make it weaker. Check out my website for compression
and pointers to compression software that would be useful for compression
as a pass before encryption.
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: "Tom St Denis" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: Text of Applied Cryptography .. do not feed the trolls
Date: Sun, 11 Mar 2001 03:29:13 GMT
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] (Tom St Denis) wrote in
> <CFAq6.9449$[EMAIL PROTECTED]>:
>
> >
> >"Dan Beale" <[EMAIL PROTECTED]> wrote in
> >message news:ZCAq6.1295$Q7.26476@stones...
> >>
> >> "Sundial Services" <[EMAIL PROTECTED]> wrote in message
> >> news:[EMAIL PROTECTED]...
> >> > Do not feed the trolls, Tom. They love to eat and make noise.
> >> >
> >> >
> >> > Tom St Denis wrote:
> >> > >
> >> > > "Ryan M. McConahy" <[EMAIL PROTECTED]> wrote in message
> >> > > news:3aa9594e$0$62146$[EMAIL PROTECTED]...
> >> > > > I am _not_ a troll! If I can't find it from you, I'll find it
> >> somewhere
> >> > > > else.
> >> > >
> >> > > What? Applied Crypto is not free so why ask here?
> >> > >
> >> > > Tom
> >> >
> >>
> >> people may not agree with giving away the (possibly pirated) text, but
> >> how about the source code, which (last time I checked) was not
> >> available to non-Americans.
> >
> >I dunno who wrote the code in the back of Applied crypto BUT IT SUCKS!.
> >It's the most sloppiest poorly written code I have ever seen. My blind
> >dog with only three legs (that we call "tripod") can write better code
> >by randomly typing keys on the keyboard.
>
> I don't know but from your comments maybe its some code I wrote.
> If it works it could be mine.
Um have you even picked up a copy of applied crypto?
Tom
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Date: Sat, 10 Mar 2001 19:36:08 -0800
Benjamin Goldberg wrote:
>
> Anthony Stephen Szopa wrote:
> >
> > Benjamin Goldberg wrote:
> > >
> > > Anthony Stephen Szopa wrote:
> > > >
> > > > Scott Fluhrer wrote:
> > > > >
> > > > > It is written "Argue not with a fool, lest you be like him".
> > > > > Here I go again ignoring that excellent advise...
> > > > >
> > > > > Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote in message
> > > > > news:[EMAIL PROTECTED]...
> > > > > > Scott Fluhrer wrote:
> > > > > > >
> > > > > > > Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote in message
> > > > > > > <SNIP BIGTIME>
> > >
> > >
> > > --
> > > The difference between theory and practice is that in theory, theory
> > > and practice are identical, but in practice, they are not.
> >
> > You've taken your first quote out of context. I has meaning when you
> > include the two immediately following sentences.
>
> *I*'m taking stuff out of context? You're the one doing megasnips.
>
> > "A file can be written to one place on a hard drive then read into
> > cache. Processed then written to a completely different place on
> > the hard drive. And this process can continue I suppose until the
> > entire hard drive has been written over once and no bit locations
> > have been overwritten."
>
> This is entirely 100% true. In fact, in a transaction based system,
> this is quite close to what actually happens.
>
> > File is opened in "r+b" mode.
>
> That has little to do with anything.
>
> > A block is loaded into cache not a sector. Block sizes vary.
>
> Block sizes are file system artifacts, sectors are disk artifacts.
>
> > I believe that there are plenty of statistics available that prove
> > the accuracy, reliability and predictability of computer technology.
> > And most bad sectors have been previously identified and are
> > routinely avoided where they will not cause runtime errors in write
> > / read operations.
>
> Regardless, they *can* happen. You, the defender, assume they won't
> ever. I, the attacker, assume they will, at least some of the time.
>
> > I don't believe that the entire block (not sector) from cache is
> > rewritten back to the hard drive. This would be inefficient. I am
> > quite sure that at most only the updated file is rewritten to the
> > hard drive. But a good point of focus.
>
> This is your belief. Do you have evidence one way or another?
>
> > Most likely when the overwrite program is the only program running
> > and the only program accessing the hard drive that the drive heads
> > will remain where they last read / wrote from / to the hard drive.
>
> Where the drive heads are is much less important than what's in the
> hdd's onboard cache.
>
> > As well, there are most likely other blocks on both sides of the
> > block / file to be rewritten to the hard drive and this location
> > will be closest and I would think most likely that the rewrite will
> > most likely take place at the original file location.
>
> Not sure what you're saying, and not sure I agree with you if it is what
> I think you might be saying.
>
> > The OS and hardware cannot ignore a coded instruction indefinitely.
>
> It never ignores instructions. Later instructions can cancel earlier
> ones. Where you get off calling buffering "ignoring" instructions I
> don't know.
>
> > This is the reasoning behind my updating the OverWrite program. If
> > the OS and hardware is given enough time it will carry out the write
> > operation.
> >
> > Are you arguing otherwise?
>
> It's not the time it takes for the operation to take place. OS Buffers
> stick around until something forces them out (things going into new
> buffers, or a timer, or shutdown). How long things stay in hdd buffers
> I don't know, but I 'spect it's the same.
>
> > Compressed files: This was another point raised. Wouldn't you agree
> > that the user is intending to overwrite the file as it exists. How
> > it got to be the file it is is not the concern of the OverWrite
> > program. This may be a concern of the user.
>
> I'm not talking about "compressed files" I'm talking about the hdd or
> the OS compressing things for you. Some of these do, ya know.
>
> Suppose you have a file which, originally, is 10kb of the ascii letter
> "a" repeated many many times. Further, suppose your hard drive does
> automatic compression. To the user, or even to the OS, this will LOOK
> like the letter "a" repeated x times. The hdd, however, has compressed
> it down to one sector. Now you want to write 10kb of random data in its
> place (since you see it as a 10kb file). The hdd says, ack, I've been
> pretending this one sector is x 100 blocks, but now someone's trying to
> write x 100 REAL sectors of data there... I guess I have to write it to
> x 100 actual sectors. Now where can I find x 100 contiguous sectors...
> here we go (and add old, one sector, to list of free sectors). Get the
> idea?
>
> > "I think that by now, everyone [except Szopa] is able to see that his
> > algorithm is not guaranteed to properly overwrite an arbitrary file."
> >
> > I guess I struck a cord for you to jump to such a conclusion in light
> > of my just made point, no?
>
> No, I had made that conclusion a while ago, after you had repeatedly
> said many many stupid things.
>
> > I do not believe that debate is about winning at all costs. I believe
> > it is about getting to the truth of an issue.
>
> Yes, absolutely right.
>
> > When a person lies or tries to deceive then the debate has
> > gone off topic but not necessarily void of enlightenment.
>
> You attempt to decieve us into beliving that your algorithm is
> wonderful, fantastic. We attempt to present the facts, and thus
> enlighten you. I have learned from some of the other people things
> which I hadn't known, and thus am enlightened. What have you learned
> from our responses to your lies?
>
> > Defragmented disks: again, OverWrite is not responsible for multiple
> > file copies. It is only tasked with overwriting the file you tell it
> > to.
>
> Ok, I accept this response. It's a decent excuse for not handling the
> problem.
>
> > Transactioning: Same as above. What you might want to do is write a
> > file large enough to cover your entire hard drive then use OverWrite
> > to overwrite your entire damned hard drive ;-)
>
> This is... half decent. You should have your program attempt to
> determine what file system is actually in use, and DETECT if it's a
> transactional system, and EXIT with an error message, if it is.
>
> > Raid disks: if you have multiple copies of a file that you want to
> > overwrite then you must tell the OverWrite program to overwrite each
> > and every one of them.
>
> Clearly, you do not understand what RAID disks are. Go reread whatever
> you can find on them, and then come back and answer.
>
> > It sounds like what you are proposing is that I upgrade the OverWrite
> > program to also scan your entire hard drive byte by byte for any
> > partial strings that are sub strings of the file you are intending to
> > overwrite as well and over write these as well. Good idea. I'll
> > keep it in mind.
>
> That would be one (bad) way to deal with the defrag issue. However, a
> better way would be to compile a list of all free hdd sectors, and then
> write over them with random data. Of course, your would probably have
> to make this functionality part of your disk defragmentor itself, since
> it is handling free blocks... if you try it some other way, things can
> get messy.
>
> > But for now, the OverWrite program is a simple overwrite utility.
> > Tell it to overwrite one file and I believe it does it and I have
> > told you why.
>
> You are free to believe what you want. Just don't expect us to agree
> with your beliefs.
>
> --
> The difference between theory and practice is that in theory, theory and
> practice are identical, but in practice, they are not.
I think my new post will be of much interest to you: OverWrite:
best...
------------------------------
** 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
******************************
