Cryptography-Digest Digest #803, Volume #13 Mon, 5 Mar 01 03:13:01 EST
Contents:
Re: Super strong crypto (wtshaw)
Re: The Foolish Dozen or so in This News Group ("Douglas A. Gwyn")
Re: The Foolish Dozen or so in This News Group ("Douglas A. Gwyn")
Re: OverWrite freeware completely removes unwanted files fromharddrive ("Douglas A.
Gwyn")
Re: OverWrite freeware completely removes unwanted files fromharddrive ("Douglas A.
Gwyn")
Re: The Foolish Dozen or so in This News Group (Eric Lee Green)
Re: Dummy question about DES ("Douglas A. Gwyn")
Re: => FBI easily cracks encryption ...? (Fogbottom)
Re: Why do people continue to reply to Szopa? ("Douglas A. Gwyn")
Re: super strong crypto, phase 3 (John Savard)
Re: super strong crypto, phase 3 ("Douglas A. Gwyn")
Re: OT: Legitimacy of Governmental Power (Was: Re: => FBI easily crack ...?)
(Vince Adams)
Re: The Foolish Dozen or so in This News Group (Eric Lee Green)
Re: sci.crypt? ("John A. Malley")
Re: Re: => FBI easily cracks encryption ...? ("Benjamin T. Moore, Jr.")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Super strong crypto
Date: Sun, 04 Mar 2001 23:15:08 -0600
In article <t5yo6.1$Ke4.73@interramp>, "nospam"@"nonsuch.org" ("Bryan
Olson") wrote:
> ...we do not know any "natural" point to change
> keys for modern ciphers; for example there are no practical
> attacks known for AES, or with recommended key sizes, RC4 or
> RSA. (In the case of public key ciphers, changing keys does
> nothing to restrict the availability of plaintext/ciphertext
> pairs.)
>
These ideas for security involved are in different approaches, both of
which shold be considered. The problem should be what algorithms exhibit
both lots of ciphertext needed for a reasonable attack, and have a
mathematical burden that is not reasonable any attack.
--
Better to pardon hundreds of guilty people than execute one
that is innocent.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Date: Mon, 05 Mar 2001 06:11:58 GMT
Anthony Stephen Szopa wrote:
> How can we consider your less than considered opinion when you
> clearly ignore the very post you are responding to: "in binary
> append mode."
In append mode you are *clearly* not overwriting existing data.
I was trying to help you understand what you need to do to ensure
the best shot at getting actual disk overwriting.
> Secondly, the 156 sec 1GB overwrite does not pertain since he did
> not even tell us anything about the code that was written that
> carried out this operation.
> Yet you seem to give his account all credibility not even knowing
> this information.
I don't need to know the details, since it was obvious from his
post what was going on, namely caching.
> And no, it wasn't the point. His exercise in futility is not the
> point of this thread.
> The point is whether or not Ciphile Software's OverWrite Security
> program makes the 27 overwrites as claimed.
If this thread had a recent point, it was that it is not as easy
as you think to guarantee real overwrite of data sectors on disk.
> Close but not quite. It is "r+b" What do you perceive now?
Sorry, that's what I meant ("r+w" is not a standard mode).
> Talk about refusing to listen? Geeeze.
? I was explaining what needs to be done to maximize the chance
that real overwriting would occur. If that supports your cause,
fine. I never *said* you didn't do that. What have you done to
ensure that system block buffers get flushed to disk between
overwrites?
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: The Foolish Dozen or so in This News Group
Date: Mon, 05 Mar 2001 06:16:02 GMT
Anthony Stephen Szopa wrote:
> But his mind is so twisted and he is so hell bent to disagree with me
> and find fault with me that he doesn't even see it. Ergo his post.
Actually I don't particularly care if your software does what is
advertised or not. But I do care that people understand the real
issues involved in trying to overwrite disk data so that they don't
try to use a naive approach that works in the model but not in the
actual implementation.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: OverWrite freeware completely removes unwanted files fromharddrive
Date: Mon, 05 Mar 2001 06:26:26 GMT
Anthony Stephen Szopa wrote:
> Darren New wrote:
> > Anthony Stephen Szopa wrote:
> > > "Closing a file does not mean that the cache has been written to
> > > disk." Is this your profound penultimate position upon which your
> > > world rests? FUD!
> > Uh, from the UNIX manual pages...
> No one ever said that the fclose() function writes anything to disk.
So when do you think the buffered data gets put onto the disk?
Certainly not when a function like fwrite or putc is called.
The obvious candidates are fflush, fseek, and fclose. The point
that people have been trying to make to you is that not even these
functions force the data to be written to disk at that time; it
can remain buried in kernel in-memory buffers for a considerable
length of time, *and* it is entirely possible that when the OS
finally gets around to trying to write the disk, an error might
occur -- in which case it is far too late to report that back to
the original application. This issue is well known to database
implementors, and indeed was raised recently with respect to a
proposed revised design for Plan 9's fundamental "file" access
protocol. If you don't properly address it, then you have not
come close to guaranteeing multiple overwrites of the disk data.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: OverWrite freeware completely removes unwanted files fromharddrive
Date: Mon, 05 Mar 2001 06:29:28 GMT
Anthony Stephen Szopa wrote:
> "... System-allocated buffers are released when the stream is closed.
> Buffers assigned by the user with setbuf and setvbuf are not
> automatically released."
It is evident from the contrast with setbuf that the buffers being
mentioned are the stdio library implementation's own buffers, not
those of the underlying block I/O subsystem of the operating system.
------------------------------
From: [EMAIL PROTECTED] (Eric Lee Green)
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Reply-To: [EMAIL PROTECTED]
Date: 5 Mar 2001 00:23:29 -0600
On Sat, 03 Mar 2001 20:50:32 -0800, Anthony Stephen Szopa <[EMAIL PROTECTED]
> wrote:
>2) If the file opens properly then it is overwritten.
>I understand your optimization explanations and those given in the
>few documents I have read. I was also familiar with the fact that a
>block of data is read and stored into the cache and the reasons for
>this. I believe that the assumption in the documentation and in your
>casts of doubt was that the opened file that is repeatedly written to
>is never instructed to be closed. In other words, a seek to the
Closing a file has nothing to do with it. All a close does is tell the
filesystem functions to remove the association between a filehandle
and a file on disk. The buffer cache layer writes out the buffer
whenever it feels like it, or when told to by an 'fsync' call. If you
open and write that same file again it makes no difference as far as
the buffer cache layer is concerned.
In addition, there is an additional buffer cache that you must
consider, and this is the buffer cache that is actually inside the
hard drive. This is especially true for SCSI hard drives with
disconnect capability. These hard drives have their own internal
scheduler that you have absolutely no control over at the OS level. If
you have sixteen writes, what happens is that those sixteen writes get
transferred to the hard drive's buffer cache. If those sixteen writes
are all to the same sector, the hard drive has the option to throw away
the first fifteen writes. This is part of the T-10 SCSI-3 standards
(see http://www.t10.org/drafts.htm ).
>operation. If the return value is NULL then the fclose() has failed.
>And if the fclose() succeeds then the return value is zero. This is
And as I mentioned, fclose() has absolutely nothing to do with things.
fclose() is a "C" library function. It flushes any internal buffers that
it has associated with the filehandle, then calls the low level OS function
to actually remove the association between filehandle and file on disk.
None of this affects the buffer cache on disk.
>carried out. To optimize as you all have been claiming in Ciphile
>Software's OverWrite program, the OS would have to LIE that it had
>successfully closed the file in order to proceed to carry out a
First of all, as I mention, 'fclose()' is not an operating system function.
It is a "C" library function. The definition for 'fclose()' in the "C"
standard specifically states that fclose() *MAY* return an error if
the underlying operating system function fails -- but does not state
that it *MUST* return an error if the underlying OS functions fail.
Again: fclose() is *NOT* an operating system function! It does *NOT* do
anything other than flush the "C" library's internal buffers -- it does
*NOT* flush the underlying operating system's disk buffer cache!
>Do any of you claim that any OS that you know of actually fudges and
>outright LIES when an instruction is given to carry out a function()
Calls like fclose() know only what they are told by the underlying operating
system. And the "C" standard does not require them to report anything
told to them by the underlying operating system.
>successfully when the OS has no way of knowing this until the
>function has actually physically been carried out just so as to
>optimize its resources? The specific functions we are talking about
>here are the fclose() and fopen() functions. Can't get more basic
>than these.
Err, fclose() and fopen() are *NOT* operating system functions. They are
"C" library functions. They do *NOT* control the underlying operating system
buffer cache. They do *NOT* control the underlying SCSI hard drive cache,
which has its *OWN* built in optimizer.
>I hear that LSD and DMT are great therapies for narrowing the gaps
>in one's conceptual continuity.
Ah. So that is your problem. You got too much LSD. Okay.
So let me spell it out to you:
*I WRITE LOW LEVEL SCSI CODE*. That is my job. You can verify that this
is my job very easily by going to http://mtx.sourceforge.net .
And that's only a subset of what I do at the SCSI level. The T-10
manuals are my friend, my bible, my well-thumbed three-inch-thick glob
of paper.
In other words, I have first-hand experience with how SCSI schedulers
work at the OS level on Linux, FreeBSD, and Unix. Granted, this is not
with Windows NT, but I seriously doubt that NT's SCSI scheduler does
differently, because out-of-order writes and optimizations are the
fastest way to do the job. I do know that Windows NT has benchmarked
faster than Linux on some benchmarks, so if anything they probably
MORE HIGHLY schedule their SCSI writes.
>(I only get a good laugh like this once in about three months.)
I'm not laughing. It's a pity you're so ignorant of how modern
operating systems and modern hard drive hardware work internally. I
know that not everybody can be smart enough to understand buffer cache
mechanisms, elevator algorithms, and T-10 SCSI manuals, but when you
then claim that your ignorance of how this works means that your
software works, (shrug). I can think of ways to make your software work,
but fopen() and fclose() definitely won't do it -- you'll have to go
down to the raw SCSI level. Read the T-10 manuals, please, before you
further make a fool of yourself.
--
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! ======
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Dummy question about DES
Date: Mon, 05 Mar 2001 06:37:49 GMT
John Savard wrote:
> DES is believed to be resistant to chosen-plaintext attacks.
Well, no, what is believed is that there is no practical, published
known- or chosen-plaintext attack against DES that is significantly
more effective than brute-force key search. It is not at all known
that no such attack is possible. In fact, I was working on that
a couple of years ago, after checking with the Agency to see if it
would be a waste of time, but due to lack of funds I had to put the
project on the back burner. It is possible that someone has made
progress since then, or will in the near future. Thus my interest
in methods to protect systems against unknown cryptanalytic attacks.
------------------------------
Date: 5 Mar 2001 06:39:33 -0000
From: [EMAIL PROTECTED] (Fogbottom)
Subject: Re: => FBI easily cracks encryption ...?
Crossposted-To: alt.security.pgp,talk.politics.crypto
In article <[EMAIL PROTECTED]>
[EMAIL PROTECTED] (Free-man) wrote:
> >I don't want police & intelligence services reading my email
or files. But
> >I do want them to read the communications of people who might
plant a bomb
> >on the next plane I take.
>
> There is a better way to prevent terrorism. There is an
alternative
> to the police-state.
History indicates otherwise.
> Governments such as the US, China, Russia, etc.
> should stop dropping bombs. Stop stomping on people. Stop
their
> systematic violations of human rights and freedom.
You'll have to wait for the "Second Coming" or whatever your
particular creation myth promises.
> There are many
> angry people on this planet who have very good reasons for
being
> angry.
There are also many angry people on this planet who have no good
reason for being angry.
> And many of them want to retaliate.
>
> Even governments that don't drop bombs engage in the widespread
> use of violence and coercion against peaceful people. More
freedom
> is the solution to most violence. Free people produce peace
and
> prosperity.
Good luck.
In the meantime...
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: Why do people continue to reply to Szopa?
Date: Mon, 05 Mar 2001 06:42:24 GMT
Paul Crowley wrote:
> Can someone explain this to me? I've never written an article that
> addressed Szopa directly, and I never plan to; he's clearly a loon who
> will never learn anything. The only reason to post a followup to
> something he's written is to warn off newcomers who might otherwise
> believe some outlandish claim or other. Yet many highly intelligent
> and knowledgable people waste a great deal of effort trying to explain
> basic facts about computer security to a man who is clearly unable to
> grasp them. Why?
I can't speak for others, but my own interest is in an open-forum
discussion of genuine issues that arise as side effects, such as
what steps must be taken to genuinely overwrite disk data. The
topic can be interesting even if its originator is a pain. This
has also arisen with regard to D.Scott's postings, although he
has become more civil in most of his recent postings. There have
been some good ideas and issues worthy of discussion, if one has
the patience to dig them out and dodge the $#!+-flinging.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: super strong crypto, phase 3
Date: Mon, 05 Mar 2001 04:22:10 GMT
On Mon, 05 Mar 2001 03:12:22 GMT, [EMAIL PROTECTED]
(John Savard) wrote, in part:
>On Sun, 04 Mar 2001 16:07:00 GMT, [EMAIL PROTECTED]
>(John Savard) wrote, in part:
>
>>E(P2, KA2), where P2 is composed of 896 bits of plaintext sent in this
>>block, XOR M1, and K3, a 128-bit random vector.
>
>Might as well do XOR M2 instead of XOR M1. Why use the mask without
>the extra layer of encryption the first time?
And in this form, I've added a diagram of this to my web page at
http://home.ecn.ab.ca/~jsavard/crypto/mi060901.htm
and the diagram might be easier to follow than this discussion.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: super strong crypto, phase 3
Date: Mon, 05 Mar 2001 06:54:19 GMT
Steve Portly wrote:
> A brute force attack is theoretically possible.
Yes, that is a common characteristic for such systems.
However, I'm concerned only with practical security,
which always involves establishing a threshold of
acceptable risk. Using estimated upper bounds for
computational capability, from the key size and cost
per encryption one can readily calculate the actual
risk against a brute-force attack. (That's how my
suggested key size was selected.) One thing phase 3
accomplishes is that it rules out successful brute-
force attack against a single block even for infinite
computational capability, meaning that of the (2^128)
possible 448-bit PTs, assessment of their relative
likelihoods would be identical to those assigned
before the CT had been received.
I should also have pointed out earlier that another
general class of attacks is ruled out, namely depth
reading of the first block of multiple messages (the
only ones for which there is a significant chance
that the same key was used).
The general principle is to avoid detailed analysis
of specific special attacks, and concentrate instead
on protection against important general methods of
attack. If all of these can be defeated then the
result would merit the appellation "super strong".
------------------------------
From: Vince Adams <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: OT: Legitimacy of Governmental Power (Was: Re: => FBI easily crack ...?)
Date: Mon, 05 Mar 2001 07:06:34 GMT
In article <[EMAIL PROTECTED]>, sideband@DELETE-
ITbtinternet.com says...
: On 4 Mar 2001 10:50:24 -0000, [EMAIL PROTECTED] ([EMAIL PROTECTED])
: wrote:
:
: >Even though there was a lot of dirty bottom-dealing involved, each step
: >along the way of Hitler's rise to power was legal. Dirty, but legal.
:
: Rings a bell! I know: just like George W Bush.
:
:
Hey guys... Who is this flaming UK asshole 'Jim D'. Must be some
trolling perv. Prez Clanton did more to erode personal freedom in the USA
than any other US president in history.
How do you say it in the UK? Go bugger yourself wanker <g>.
------------------------------
From: [EMAIL PROTECTED] (Eric Lee Green)
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Reply-To: [EMAIL PROTECTED]
Date: 5 Mar 2001 01:05:04 -0600
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! ======
------------------------------
From: "John A. Malley" <[EMAIL PROTECTED]>
Subject: Re: sci.crypt?
Date: Sun, 04 Mar 2001 23:20:42 -0800
David A Molnar wrote:
> there's some discussion here which is of scientific merit. it comes and goes.
> most recently, I've been skimming the discussion of Rabin's new scheme.
> almost all of it is civil, and most of it is thoughtful. I haven't had the
> time to read other threads.
Tom's original post doesn't show up on my service provider's News server
so I can't directly reply to him -
but I agree with David Molnar - there is some discussion here of
scientific merit.
Check out the "Super-Strong Crypto" threads from Douglas Gwyn. There's
a serious analysis and design dialogue going on. People are applying
collective knowledge to an interesting proposal.
John A. Malley
[EMAIL PROTECTED]
------------------------------
From: "Benjamin T. Moore, Jr." <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: Re: => FBI easily cracks encryption ...?
Reply-To: <[EMAIL PROTECTED]>
Date: Mon, 05 Mar 2001 07:42:39 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
On Sun, 4 Mar 2001 12:44:32 +1000, on the subject, "Re: => FBI easily
cracks encryption ...?," "Mark Livingstone" <[EMAIL PROTECTED]>
wrote:
>"Free-man" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>
>> No. Most of what law enforcement does is a violation of individual
>> rights. Most of the laws that they enforce are unjust, bullshit
>> laws that criminalize honest trade and peaceful behavior. Many
>> cops are nothing but enforcement goons for the government mafias.
>> They
>> enforce monopolies on drugs, guns, gambling, etc. They commit
>> more crimes than the bad guys.
>
>True. I remember reading somewhere that on a number per hundred
>thousand basis, more crimes are committed by cops than CCW holders.
>
>I guess this must be true to some degree or Police Dept's would not
>have to have Internal Affairs Dept's.
In the past 3 or 4 years... here locally, we've had 1 cop tried and
convicted of rape, with the allegation - 20 or so others came forward -
that he had done this to as many as 30 or more women. Interestingly
enough... he was fired from the force, told to leave the State and not
return. They do deal a bit differently with their own don't they? We had
another cop tried and convicted of rape. His "MO" was to pull "dancers"
over as they were leaving work early in the morning, run them for parking
tickets or anything he could find. If he got a hit, he'd give them a
choice, service him or go to jail. One unfortunate he actually drove down
to the "lock-up," showed her the intake doors, prior to her agreeing to
"service" him.
We've had cops charged with drunken driving while driving a marked squad
car. We've had weapons come up missing from the police armory and property
room. We've had cops charged and convicted of domestic abuse - pulling
their service revolver on their wives - The local Sheriff caught drinking
on duty and I could go on and on... haven't even mentioned all the police
action shootings of unarmed civilians... :-) Nope... don't think I'll be
trusting the cops anytime soon... :-)
- --
Benjamin T. Moore, Jr. - <[EMAIL PROTECTED]> ICQ UIN - 8159114
*The Price of Freedom is Self-Reliance! The Cost is Education!*
*Home Page: http://ind.cioe.com/~btmoore
*Page me on the WWW at: http://wwp.mirabilis.com/8159114
Use your Web Browser to get my PGP Public Keys from:
http://ind.cioe.com/~btmoore/_private/MyKeysDSSRSA.txt
=====BEGIN PGP SIGNATURE=====
Version: 6.5.8ckt http://www.ipgpp.com/
iQA/AwUBOqNDYXDnKKP6IdMiEQIkyACgvUQCdfDRAcP5pIEU0+oyPZgUaRkAoKS+
lOTPUpdpnDuDlJEFAJZ1guoA
=ASHQ
=====END PGP SIGNATURE=====
------------------------------
** 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
******************************
