Cryptography-Digest Digest #817, Volume #13 Tue, 6 Mar 01 08:13:01 EST
Contents:
Re: The Foolish Dozen or so in This News Group (Anthony Stephen Szopa)
Any news on the KFB mode? (Volker Hetzer)
Re: The Foolish Dozen or so in This News Group (Anthony Stephen Szopa)
----------------------------------------------------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Date: Tue, 06 Mar 2001 05:03:59 -0800
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
> > > news:[EMAIL PROTECTED]...
> > > > The Foolish Dozen or so in This News Group
> > > >
> > > > Read below. It'll be just like being forced to look into a mirror.
> > > > You'll see who you all really are. Read it an weep.
> > > >
> > > > Here is why I think Ciphile Software's OverWrite program actually
> > > > <majorsnip>
> > >
> > > careful with your fopen() and your fclose() functions won't help you
> there
> > > either.
> > >
> > > --
> > > poncho
> >
> >
> > "...After all, it's in control of the file system... See,
> > logically..."
> >
> > What people fail to perceive quickly enough is that we are talking
> > to several sick minds.
> Of course, "sick minds" is being defined as "anyone with any technical
> experience that indicates that the problem might be somewhat less trivial
> than Anthony Szopa believes."
>
> >
> [Re: OS's buffering writes]
> > I guess what you say is true even if I am writing to the file in
> > append binary mode, I suppose? NOT!
> I suspect you meant writing the file in update mode, but in any case, of
> course the OS (and the disk driver, and the disk controller itself) can
> buffer writes.
>
> [Do any of you claim that any OS that you know of actually returns before
> actually writing the data to the disk]
> > "...known as Unix which as precisely this property..."
> >
> > You are slandering UNIX.
> Hardly. You may not be aware of this, but several jobs ago, a large part of
> my job was to maintain several versions of the Unix kernal. There was very
> little that the Unix kernel did that I was unaware of (it helped somewhat
> that, back in those days, the Unix kernel was considerably smaller). And, I
> can swear unequivocally that those versions of the Unix kernel did have
> precisely that property. If you disagree, may I ask after your
> qualifications as a Unix kernel hacker?
>
> In any case, I also mentioned (in a part you snipped) that I verified
> expirementally that Linux (a Unix work-alike) did in fact have that property
> (either that, or the disk on that computer spins at 384,000 RPM).
>
> > So, what you are saying is that everything goes on in cache and that
> > disk space is not under the operator's control. 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.
> Yes, at least in theory. And, according to Darren New, the Atari disk OS
> has pretty much this behavior. I'm glad to see we agree.
>
> >
> > I would think this is not likely because of the optimization you
> > claim to be expounding. The drive heads are already over these bit
> > locations. To wander all over the hard drive writing to no
> > predetermined fixed hard drive bit locations would be inefficient
> > and un-optimizing.
> For one, "unlikely" != "can't happen". The drive heads might not be "over
> these bit locations", as some other program may have forced the drive heads
> elsewhere. An OS might decide to write the sectors where the heads happen
> to be. I have already mentioned one case (disk compression) where
> relocating sectors is quite likely. Darren New mentioned another. An OS
> attempting to do on-the-fly disk optimization is a fourth conceivable
> example.
>
> >
> > With the reliability of computers these days most operations do take
> > place successfully. There is no reason for the write locations to
> > be moved around repeatedly. Give us a real world reason that happens
> > regularly. You have only given us a once in a blue moon possibility
> > that it might happen. What do you think, once in 100,000,000 writes?
> Actually, in my previous posting, I gave one real world reason ("disk
> compression"). Above, I gave three others.
>
> And, in any case, the "mapping around write defects dynamically" algorithm
> was not given as an example of relocating disks, it was a reason why write
> buffering may be a valid optimization, even if you have an imperfect disk
> (and, some systems have disks, such as SCSI, which claim to be perfect).
>
> >
> > Your hard drive was quiet because the heads did not move once they
> > were in position. Is that about 1GB with no head movement in 156
> > seconds? If you say so. This is not the point.
> Are you claiming that my disk really spins at 384,000 RPM? If not, how
> could it have possibly done one million writes to one sector in 156 seconds?
>
> >
> > The specific point is whether or not a write operation is actually
> > taking place in Ciphile Software's OverWrite Security program. I am
> > saying that it is by all my reasoning. The fclose() function with a
> > conditional statement seems to force a write but you are saying that
> > the head is wandering all over the hard drive and writing the
> > resultant files repeatedly all over the hard drive in binary append
> > mode.
> >
> > So what you are saying is that even if I just overwrite one character
> > in a file this entire file will be loaded into cache if it will fit
> > and this one character will be changed and then the entire file will
> > be written to some other location on the hard drive so that there
> > will be two files on the hard drive: the original file and this
> > newly written file. And your position is that this is your view of
> > optimization.
> >
> > Interesting.
> Yes. Do you engage in strawman arguments often?
>
> >
> > "...These things typically have no knowledge of the file system..."
> > You'll run to any length it is apparent to avoid the topic.
> The fact that the disk caching routines may be be informed of fclose's is
> irrelevant? I thought that fclose forcing writes was the basis of your
> argument, and so a disk caching routine not being informed about it would
> appear to be highly relevant. And, yes, some disk caches are ignorant of
> fclose's -- I know, because I wrote some.
>
> >
> > "...Another nasty problem arises if disk compression is in use...."
> > Run on. Run on.
> Actually, if I were you, I'd look at disk compression real closely -- it's a
> very sticky problem for file overwriters. For example, if a file originally
> took up 2000 physical sectors, and you overwrote it with data that
> compresses down to 500 sectors, why would you expect the OS to overwrite the
> 1500 remaining sectors?
>
> >
> > Has anyone seen the topic of this thread laying around here anywhere?
> I thought the topic was "Is the algorithm that Anthony Szopa gave guaranteed
> to properly overwite an arbitary file?". I claim that all the points I
> brought up was relevent to that.
>
> >
> > "...disk drives often write bits to parts of the drive without you
> > asking it to...."
> >
> > What does this mean: a bit here a bit there? Stopped running to
> > other topics to run off about who knows what this means: "...disk
> > drives often write bits to parts of the drive without you asking it
> > to...."
> Well, (at least, as reported earlier), disk drives often save data to hidden
> parts of the disk for various reasons. This is perfectly valid, because as
> long as the disk drive correctly performs the operations asked of it
> ("accept writes to sectors, and then give back that exact data when that
> sector is later read"), it can do anything it finds expedient. This is
> important to a disk overwriter, because writes may not overwrite this
> redundant storage.
>
> Other things that occur to me that a disk overwriter might need to worry
> about:
>
> - Disk optimizers -- run either at a user command, or as a background
> process. These routines shuffle files around so they can be accessed
> faster, usually by making them consecutive. I would claim that this is a
> problem for a disk overwriter, because after the disk overwriter has
> completed, there may still be copies of the file still remaining in the free
> list, and this violates the security guarantee that the overwriter ought to
> make.
>
> - Versioning file systems. These are out-of-favor currently, but they do
> exist.
>
> - Transactioning file systems. I'm not sure how these works, but I wouldn't
> be shocked to hear that they also move sectors around at times.
>
> - RAID disks. Again, I'm not sure if this is really a problem, but have you
> studied all the various RAID levels to verify that there isn't a problem
> lurking there somewhere?
>
> --
> poncho
You are another propagandist.
I have replied with detailed cogent points that have gotten the
better of most of you. At no time did I indicate that I thought
these were trivial points. So admit you are lying.
The fclose() flushes the buffers. So explain to us which buffers
are not flushed and why you think then that these are the ones that
are used by the conniving OS to conspire to not write to the hard
drive as the code instructions demand.
You once thought you knew all there was to UNIX and you were
admittedly wrong. It is better than even money that you don't
know any better now.
We don't agree. This is all off topic. This is a windows program,
not Atari. Stick with the thread and make a point if you have one
that can last more than its original posting.
Well, there you go again. You are making another hypothetical to
detract from the fact that you cannot stick with the thread.
This is a personal use program for windows. I think it is fair to
say this program is for and intended for a non multitasking
environment.
I've given you enough of my time.
Take a look at my floppy disk test results I just posted. They seem
to cramp everything pretty much all the detractors have been saying.
Let's see you come up with some more off topic hypothetical BS
refuting this floppy test.
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Any news on the KFB mode?
Date: Tue, 06 Mar 2001 14:16:03 +0100
Hi!
I just got the KFB paper in my hands and am thinking about whether
to use that mode.
As far as I understand it yet, it is some provably secure PRNG,
kinda like an alternative to BBS and possibly faster.
However, BBS was "proven" once too and later it turned out that
nevertheless it wasn't the perfect solution either. Has something
similar happened to the KFB mode too? Are there any references apart
from the original paper at http://csrc.nist.gov/encryption/modes/workshop1?
Greetings!
Volker
--
They laughed at Galileo. They laughed at Copernicus. They laughed at
Columbus. But remember, they also laughed at Bozo the Clown.
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Date: Tue, 06 Mar 2001 05:09:50 -0800
Eric Lee Green wrote:
>
> On Sun, 04 Mar 2001 05:04:46 -0800, Anthony Stephen Szopa <[EMAIL PROTECTED]
> > wrote:
> >"...known as Unix which as precisely this property..."
> >
> >You are slandering UNIX. If a conditional statement is coded then
> >even UNIX has enough common sense to confirm the outcome of that
> >condition before proceeding.
>
> I have been programming Unix since 1985. How long have you been programming
> Unix?
>
> The only time a write fails in Unix is if the hard drive is
> full. Period. Otherwise, the data is simply moved to a kernel buffer
> and scheduled for later writing. I can personally attest that this is
> what happens on Linux. But even older versions of Unix did this. I
> suggest that you start reading on page 101 of Maurice J. Bach's book
> "The Design of the Unix Operating System" (the copyright date on my
> copy says 1986). On page 102: "The write proceeds block by block, but
> the kernel uses a _delayed write_ (section 3.4) to write the data to
> disk, caching it in case another process should 'read' or 'write' it
> soon and avoiding extra disk operations." In other words, the block is
> cached in memory for a while prior to being written to the hard drive,
> and if another process (or even the same one) attempts to write to that
> block again before it has been flushed to disk, only the buffer is
> overwritten, not the disk.
>
> >with these sorts of flimsy smooth ridiculous lies.
>
> So you're saying that Maurice Bach, a researcher with AT&T Bell Labs,
> was lying to us?
>
> >So, what you are saying is that everything goes on in cache and that
> >disk space is not under the operator's control. 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.
>
> It could. You just described how the Reiser filesystem works on Linux.
> It is a transactional or "versioning" filesystem. Here is how a
> transactional file system works:
>
> 1) The transaction is started. A "transaction" is written to the
> transaction log, with "uncommitted" as its state, stating where
> the old block and new block shall be.
> 2) The new version of the block is written to an empty sector (i.e.,
> *NOT* back to the block where the old version lives!)
> 3) The old version is marked as "free".
> 4) The transaction is marked as "committed" in the transaction log.
>
> This obviously requires much modification of the traditional Unix-style
> buffer block management mechanism in order to maintain transactional
> integrity, and is why the Reiser filesystem was not standard in Linux
> until very recently. The Reiser filesystem relies upon strict ordering
> of the writes, which until recently was not done by the traditional
> Unix-style buffer block management mechanisms.
>
> However, under the traditional Unix-style buffer block management
> mechanism, as described by Dr. Bach, the block does get written back
> to the place from whence it came -- someday.
>
> >I would think this is not likely because of the optimization you
> >claim to be expounding. The drive heads are already over these bit
> >locations. To wander all over the hard drive writing to no
>
> You are assuming that other things are not happening in the
> background.
>
> >With the reliability of computers these days most operations do take
> >place successfully. There is no reason for the write locations to
> >be moved around repeatedly.
>
> Transactional logging filesystems. Most Unix systems have one. Windows
> 2000 may have one, I don't know. (Windows NT's NTFS filesystem was
> only semi-transactional -- it did the transactions only on the
> meta-data). By keeping the old data around until the new data is
> confirmed as being written to disk, you can always maintain the system
> in a consistent state. When you are talking terabyte-sized databases this
> is important.
>
> >saying that it is by all my reasoning. The fclose() function with a
> >conditional statement seems to force a write but you are saying that
>
> No, it is sending data to the operating systems' buffer cache. The
> operating system buffer cache then writes when it feels like. It may
> write to the same block, or may not, depending upon the filesystem.
> Older versions of Windows 95 did not have a buffer cache and your
> software may actually do as you think there. Windows NT and 2000 do have
> a buffer cache, and always have had one.
>
> >So what you are saying is that even if I just overwrite one character
> >in a file this entire file will be loaded into cache if it will fit
>
> Don't be ridiculous. The block with the changed data will be loaded into
> cache. Your 1 byte will overwrite the byte that you want to change. Then
> the block will be scheduled to be written back to disk. When it actually
> gets written back to disk, and where, is not under your control.
> If it is a "normal" Unix filesystem (i.e., Linux or an older
> Unix as described by the Bach Book), it will get written back to where
> it came from -- eventually. If it is a newer transactional (logging)
> filesystem, the changed block will be written elsewhere. This is the
> nature of the beast.
>
> >Like I said: What people fail to perceive quickly enough is that we
> >are talking to several sick minds.
>
> What, you're suffering from MPD (Multiple Personality Disorder)? As I
> said, I have been programming under Unix since 1985. How long have you
> been programming under Unix? How many books on Unix internals have you
> read? And how much Unix source code have you personally examined? The
> moment you start making grandiouse statements about how Unix obviously
> could not do things the way that it does, is the moment I know that
> you are either studiously ignorant, or a liar. I prefer to think of
> you as the former, because ignorant people can be educated, while
> liars, well, we knew what to do with liars back home in Lousiana. See
> my .signature file for the Internet version of what we do with liars
> back home in Louisiana. (Sorry, the redneck in me is coming out).
>
> The shame of it is that your product could be more useful, if you knew
> what the <bleep> you were doing. It's a shame that you don't. But at
> least you give us the information to make that decision on our own,
> unlike some people. Your software will work on Windows to prevent
> someone from just "undeleting" the file and reading it. It won't
> stop an FBI snoop with a full forensics kit though, not if it works
> the way that you've described it to us.
>
> --
> Eric Lee Green [EMAIL PROTECTED] http://www.badtux.org
> AVOID EVIDENCE ELIMINATOR -- for details, see
> http://badtux.org/eric/editorial/scumbags.html
>
> -----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
> http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
> -----== Over 80,000 Newsgroups - 16 Different Servers! =-----
Ciphile Software's OverWrite Security Utility is a windows program.
I should have known better than to say one word in response to any
off topic drivel.
Now you want to discuss who is the better expert of UNIZ. Why not
discuss the fact I cannot even spell UNIZ.
This thread is about the OverWrite program.
So, have you read my floppy disk test using the OverWrite program?
There is not much room for any of you to BS your way out of this
definitive test.
It clearly shows that all of you are completely wrong when if comes to
floppies.
I guess you will all have to say then that there is absolutely no
relationship in the way OverWrite operates with floppies and the
way it operates with the hard drive.
------------------------------
** 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
******************************
