Cryptography-Digest Digest #120, Volume #13 Wed, 8 Nov 00 08:13:00 EST
Contents:
Re: Updated XOR Software Utility (freeware) Version 1.1 from CiphileSoftware (CiPHER)
Re: XOR Software Utility (freeware) available from Ciphile Software (Lissi)
Re: MORE THAN FULLY BIJECTIVE ! (Tim Tyler)
Re: Hardware RNGs (Tim Tyler)
Re: CHAP security hole question (Vernon Schryver)
Re: hacker...beware (John Savard)
Re: XOR Software Utility (freeware) available from Ciphile Software (Tom St Denis)
Re: XOR Software Utility (freeware) available from Ciphile Software (Tom St Denis)
Re: Hardware RNGs (Paul Crowley)
Re: Updated XOR Software Utility (freeware) Version 1.1 from Ciphile Software (Tom
St Denis)
Re: Updated XOR Software Utility (freeware) Version 1.1 from Ciphile Software (Tom
St Denis)
Re: Whole file encryption (Tom St Denis)
Re: Updated XOR Software Utility (freeware) Version 1.1 from Ciphile Software
(CiPHER)
Re: Updated XOR Software Utility (freeware) Version 1.1 from Ciphile Software
(CiPHER)
Re: hacker...beware (Colin Watson)
Re: hacker...beware ("Carsten Bauer")
----------------------------------------------------------------------------
From: CiPHER <[EMAIL PROTECTED]>
Crossposted-To: alt.freespeech,talk.politics.misc,talk.politics.crypto
Subject: Re: Updated XOR Software Utility (freeware) Version 1.1 from CiphileSoftware
Date: Wed, 08 Nov 2000 09:55:17 GMT
In article <[EMAIL PROTECTED]>,
Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
> the GOOD will to get these fully functional products out to the
> public.
Your programs are vastly inferior in coding and capability to open
source programs already freely available to the market.
> If any of you were Gore supporters just think if you had given as
> much energy to his getting elected as you have squandered in my
> threads he might have won.
As much as I was a Gore supporter I would have found it very difficult
to (1) Change my nationality (2) Get to the US (3) Vote, presuming I'd
want to anyway.
--
Marcus
---
[ www.cybergoth.cjb.net ] [ alt.gothic.cybergoth ]
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Lissi <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.hacker,talk.politics.misc
Subject: Re: XOR Software Utility (freeware) available from Ciphile Software
Date: Wed, 08 Nov 2000 10:26:24 GMT
On 08.11.00, 05:16:58, the suspect Anthony Stephen Szopa=20
<[EMAIL PROTECTED]> answered when questioned about Re: XOR Software=20=
Utility (freeware) available from Ciphile Software:
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
[snip]
> > The really 'neat'? thing about this program is it is GROWING
> > between versions, and not shrinking. This program even with the
> > trash that windows forces you to add is way too large unless you
> > either have embeded images in the file, or some other code is
> > taging along.
> If you know what you are talking about then you must have resources
> to check the behavior of the software while it is running: such as
> a firewall or virus protection?
Wow, Anthony. If your knowledge about coding is as sound as
your knowledge about what firewalls or virus scanners are
for, your programs do everything, but not what you claim.
So better stop flaming.
Lissi
- --=20
Life ain't fair, but the root password helps.
-BOFH
PGP-Fingerprint:
F119 52A9 A520 B1C5 28B7 BDFE 2B72 9E38 479E 31CC
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>
iQA/AwUBOgkcMCtynjhHnjHMEQLteQCdFgjtfRQvcgRVUwzSEJkFXzinJJgAoPpY
+nFMKfb2y6OmFFe+IcjsEegf
=3DpmJi
=====END PGP SIGNATURE=====
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: MORE THAN FULLY BIJECTIVE !
Reply-To: [EMAIL PROTECTED]
Date: Wed, 8 Nov 2000 10:39:03 GMT
Matt Timmermans <[EMAIL PROTECTED]> wrote:
: Not particularly useful, you mean -- a fixed IV doesn't preserve all
: the nice properties of CBC mode. CBC after whitening is almost as
: good as CBC, though, except that an attacker can detect repeated
: messages sent with the same key [...]
...there are also some different error extension properties.
: David, in this message, says simply that a surjection would serve his
: purposes just as well, and so an IV can be supplied.
I can't see what the problem is with supplying a random IV, and tacking it
onto the front of the file.
Sure, many messages now decrypt to the same cyphertext - but if you
consider the set of all messages + IVs, and the set of all cyphertexts
with tacked on IVs, then there appears to be a bijection between them.
This is "the normal bijection" applied once for each IV.
David appeared to imply that there was some difficulty in doing this -
but I can't see what it is.
--
__________ http://alife.co.uk/ http://mandala.co.uk/
|im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Hardware RNGs
Reply-To: [EMAIL PROTECTED]
Date: Wed, 8 Nov 2000 10:49:23 GMT
Paul Crowley <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> AR:"Hashing does not increase entropy, whether one pass or multiple."
:>
:> PC:"No, of course not. However, at least it doesn't *reduce* entropy."
:>
:> In fact hashing 160 bits of entropy produces an output with a bit over 159
:> bits of entropy. Hashing *can* reduce entropy.
: What I actually said was "However, at least it doesn't *reduce* entropy
: until you already have enough for your state to be unguessable"
My apologies. I was quoting from a post by [EMAIL PROTECTED]
- where the subsequent material had already been snipped.
In fact, I don't think the subsequent material makes much difference.
A cryptographic hash can reduce entropy from the word go. It is true that
if you don't have much entropy, the chances of it being reduced in this
way are small, though.
--
__________ http://alife.co.uk/ http://mandala.co.uk/
|im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
------------------------------
From: [EMAIL PROTECTED] (Vernon Schryver)
Subject: Re: CHAP security hole question
Date: 7 Nov 2000 09:08:27 -0700
In article <[EMAIL PROTECTED]>,
Thomas Wu <[EMAIL PROTECTED]> wrote:
> ...
>You're right - it's difficult enough as it is to keep lots of passwords
>memorized. While it's nice to be able to think about smartcards that
>might help out, strong password technologies are something that can
>be deployed today, and they have the nice property that their security
>doesn't rely entirely on forcing users to pick harder-to-remember passwords,
>the way broken protocols like CHAP do.
That is still mostly false. As I've repeatedly pointed out, practically
no one remembers or knows their CHAP password. Thus, whether it is hard
for humans to remember is irrelevant and the significant complications of
a zero- knowledge protocol would be liabilities without benefits for PPP.
> ...
>> I'm assuming something obvious and simple, such as a DH exchange to get a
>> secure channel, authenticated with a side channel consisting of you
>> speaking on the phone to someone at the ISP. You would download a program
>> (if you wish, deal with authenticating the program). The guy at the ISP
>> would tell you to type a short string to the program that would let the
>> program on your PC and a matching program at the ISP exclude a man in the
>> middle. Then the two programs would do the usual stuff to generate a
>> random key that would be jammed into the Micrsoft PPP configuration stash
>> along with phone numbers, TCP windows and MRU, and other stuff.
>> No human would never know the authenticating secret, just as with
>> most PKI authenticating.
>
>You've described a complicated protocol that can be easily simplified
>with a strong password protocol. Hint: you can replace the long hex
>checksums with an out-of-band password. More human-friendly.
I said nothing about "long hex checksums". Since that hypothetical
protocol would be protected by the temporary DH key, it would use easy to
say and type authenticators.
> ...
>> >It is better to design an authentication system
>> >that acknowledges
>> >the limitations of human factors and takes them
>> >into account, rather than one
>> >that imposes significant inconvenience upon users
>> >in order to achieve security.
>>
>> Exactly. In today's world that means acknowledging that we all must
>> authenticate ourselves in literally dozens of independent contexts, and
>> that means passwords kept in human memories are largely irrelevant.
>
>Funny, I think the opposite conclusion is warranted - that forcing
>harder password choices on people is a loser's game.
I'm arguing from Thomas Wu's premise that "forcing harder password choices
on people is a loser's game" to the unavoidable conclusion that any common
authentication scheme involving passwords is "a loser's game," except
perhaps (but not necessarily) authenticating yourself to your smartcard
or personal computer.
>> Smartcards have all of those problems, but at least they have a hope
>> of working. Your own assumption that people cannot handle a single
>> good passphrase of a password implies that people cannot handle the
>> dozens of passwords that we all must use even if those dozens of
>> passwords are each 1 and 2 syllable words.
>
>I'm not sure this matches the current understanding of human factors.
>People have excellent long-term memories, but they just don't happen
>to be good at memorizing arbitrary strings or bits like a computer.
Thomas Wu surely knows that good, strong passwords today are not
hex strings, arbitrary strings, or bits, but passphrases or strings
of native language words chosen by the user to be as easily memorized
as possible. The set of all of the passwords each of us must
remember is harder to memorize than any passphrase, but passphrases
are too hard. Thus, passwords even with zero-knowledge protocols
are what Thomas Wu terms "a loser's game."
>> > ...
>> >> In other words, the current reality of dozens of
>> >passwords forces people
>> >
>> >Sites that force artificial "good password" rules
>> >on human users do this.
>> >Let's be clear on our assumptions.
>>
>> My assumption has nothing to do with 'forced artificial good passwords'.
>> I assume that it is a Very Bad Idea(tm) to use the same password, whether
>> good or not, with your banker, your employer, and your doctor. Evidently
>> you assme the opposite, that it is just fine to make it possible for a
>> clerk in your doctor's office to poke around your MasterCard account, or
>> vice versa.
>
>Once again, strong password technologies make these attacks difficult.
>If you were talking about, say, ssh or some other disclosing authentication
>method, you'd be right.
We all know that strong password protocols do not hinder naughtiness by
people with access to the secrets used in any authentication protocol....
or maybe not. A couple articls ago Thomas Wu implicitly claimed that
strong password protocols somehow protect passwords from people with access
to the files containing them and/or that packet sniffing is the primary
computer or network security problem.
Contrary to zero-knowledge advocates, dictionary attacks on passwords in
sniffed packets are not a major problem in the real world. Other than a
few incidents such as the infamous case at Stanford about 10 years ago,
few high profile cases have involved sniffing packets. The Stanford case
involved cleartext passwords, which no one advocates and which are the
main place where zero-knowledge password protocols have enough value to
offset their significant costs.
If other things were not so completely lame and insecure (e.g. PC
software), dictionary attacks on sniffed packets might matter. But the
universe is as it is. Claiming that zero knowledge protocols and
dictionary attacks on sniffed passwords are important and that inertia,
patents, real life security holes, and the requirements for dozens of
passwords don't matter is not healthy.
Zero-knowledge password are like TAP and IDENT. Several years ago, advocates
made lots of noise about those protocols. Instead of admitting the
weaknesses that made them at most mildly useful but quite unreliable even
to operators running servers, their advocates shouted about laziness,
inertia, and evil standards committee conspiracies among those who
disagreed. After IDENT implementations became almost universal and the
limitations of completely insecure, easily spoofed authentication protocol
undeniable, the advocates moved on to new obsessions, and those who care
about keeping their SMTP servers from bogging down waiting for IDENT add
"define(`confTO_IDENT',0)" to their .mc files.
SMTP AUTH is another example of the syndrome. Only a few years ago
advocates claimed that adding authentication to SMTP would end spam. When
it appeared in sendmail, the result was what everyone sane and honest had
predicted. Spam was unaffected.
Vernon Schryver [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Crossposted-To:
alt.lang.basic,alt.permaculture,alt.surfing,alt.surfing.europe.uk,aus.computers.linux,comp.os.linux.setup
Subject: Re: hacker...beware
Date: Wed, 08 Nov 2000 11:57:13 GMT
On Wed, 8 Nov 2000 19:27:58 +1000, yogi <[EMAIL PROTECTED]> wrote, in
part:
>The best thing to do is just chill out... System administrators turn off the
>monitoring facility of firewalls once they are satisfied their rules work...
One is never sure that a firewall always works: monitoring is used to
find out what has happened in case an attack is ever successful. And
fewer computers would be hacked, the more deterrence existed for
attempts to make unauthorized use of them.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.hacker,talk.politics.misc
Subject: Re: XOR Software Utility (freeware) available from Ciphile Software
Date: Wed, 08 Nov 2000 12:03:37 GMT
In article <[EMAIL PROTECTED]>,
Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
> If you downloaded OAP-L3 and checked it out, you would have found
> that there are tutorials that test every aspect of the encryption
> software. You are also at liberty to design your own files to test
> the various processes.
>
> You can be sure that OAP-L3 performs exactly as described and you
> can prove it to yourself.
No offense, but I don't really consider "homebrew" cryptography with
the highest regard. I am not likely to try your program ever.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.hacker,talk.politics.misc
Subject: Re: XOR Software Utility (freeware) available from Ciphile Software
Date: Wed, 08 Nov 2000 12:02:28 GMT
In article <[EMAIL PROTECTED]>,
Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
> Someone else already answered your question.
I think it's big cuz there is a backdoor... my XOR program is only
9kb ... and has source ... so there!
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: Hardware RNGs
Date: Wed, 08 Nov 2000 12:12:09 GMT
Tim Tyler wrote:
> : What I actually said was "However, at least it doesn't *reduce* entropy
> : until you already have enough for your state to be unguessable"
[snip]
> A cryptographic hash can reduce entropy from the word go. It is true that
> if you don't have much entropy, the chances of it being reduced in this
> way are small, though.
I guess I should have said "hardly reduces entropy". If n is the number
of bits in the hash, and r is the entropy of your current state, then
when r is a few bits smaller than n a quick back-of-the-envelope
calculation tells me that the entropy lost by a hashing step is roughly
2^(r-n). So if you've got 128 bits of entropy (enough to be unguessable
in anyone's book) you'll lose 2^-32 bits by hashing with SHA-1. I
wouldn't lose sleep over it.
(Caveat: I'm not 100% happy with the way I worked this out, though I
don't think I can be *that* far off. If anyone can point at a canonical
formula for entropy loss through hashing I'd be interested to know.)
I think the participants in this thread mostly now agree. If anyone is
still arguing againt the use of Yarrow-like hashing for your sources of
cryptographic randomness, please make this clear...
--
__
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Crossposted-To: alt.freespeech,talk.politics.misc,talk.politics.crypto
Subject: Re: Updated XOR Software Utility (freeware) Version 1.1 from Ciphile Software
Date: Wed, 08 Nov 2000 12:09:48 GMT
In article <8ub7p4$7hm$[EMAIL PROTECTED]>,
CiPHER <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
>
> > Have you provided something of real use to any of us, besides your
> > opinions?
>
> Well, have you? A shitty coded XOR program, that is inherently
> pointless and even more obviously badly coded?
>
> I mean, _I_ could even write a more useful cross-platform XOR program
in
> Java if I had the time and didn't have to spend it making stupid
> maze-solving programs.
That was MY original point. That sure it's a neat program, but it's
useless.
In about the same time it took me to write the xor program I wrote a
simple commandline utility (ANSI C) that uses SHA-256/RC4 to parse
passwords+IV and encrypt/decrypt files. That program compiles to 14kb
and is way more practical then the XOR program. (if anyone wants the
source or exe to the SHA/RC4 program email me at [EMAIL PROTECTED])
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Crossposted-To: alt.freespeech,talk.politics.misc,talk.politics.crypto
Subject: Re: Updated XOR Software Utility (freeware) Version 1.1 from Ciphile Software
Date: Wed, 08 Nov 2000 12:07:49 GMT
In article <[EMAIL PROTECTED]>,
Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
>
> You seem to be an expert on most matters.
>
> Have you provided something of real use to any of us, besides your
> opinions?
Sure these are the sources/things I have posted in the last six months.
The peekboo v2.01 program, the cryptobag API, the Tiger/PRNG API, the
password generator, the ciphers TC1 to TC7, my revision of Twofish, my
two revisions of Blowfish, my SHA-256 source code, my sbox generator
(new release soon btw), my affine transorm code, my "nyberg sbox" code,
my new serpent and gost sboxes, GOST source code and my observation on
the suboptimality of Matsui sboxes.
What have you done?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Whole file encryption
Date: Wed, 08 Nov 2000 12:12:05 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>
> Benjamin Goldberg wrote:
> >
> > The following is a simple idea for whole file encryption.
> > sbox is actually a keyed sbox.
> >
> > encrypt_r( data, length, sbox )
> > tmp1 = length, tmp2 = tmp1/2, tmp3 = tmp1-tmp2
> > ptr1 = &data[0], ptr2 = &data[tmp3]
> > for( i = 0; i < tmp2; ++i, ++ptr1, ++ptr2 )
> > *ptr1 += sbox[*ptr2]
> > *ptr2 += sbox[*ptr1]
> > *ptr1 += sbox[*ptr2]
> > if( tmp2 != tmp3 )
> > *ptr1 = sbox[*ptr1]
> > if( tmp2 > 0 )
> > encrypt_r( data, tmp2, sbox )
> > if( tmp3 > 0 )
> > encrypt_r( ptr1, tmp3, sbox )
> >
> > encrypt( data, length, sbox )
> > encrypt_r( data, length, sbox )
> > encrypt_r( data, length, sbox )
>
> I don't see why you have
>
> *ptr1 += sbox[*ptr2]
> *ptr2 += sbox[*ptr1]
> *ptr1 += sbox[*ptr2]
>
> and don't have simply the first two statements. (Compare
> a normal Feistel cipher).
Because the Luby-Rackoff proofs of construction only hold when there
are at least three rounds.
> Does
>
> encrypt( data, length, sbox )
> encrypt_r( data, length, sbox )
> encrypt_r( data, length, sbox )
>
> simply mean that you want to repeat encrypt_r exactly
> two times? If yes, why?
>
> If I understand correctly, what you do in encrypt_r
> is equivalent to doing a permutation of the elements
> of the array data (or segments of that array in the
> recursive calls) thru bringing those at some distance
> away to become neighbours and then perform a normal
> Feistel cycle. There is some similarity to an idea I
> posted recently in the thread 'On block encrpytion
> processing with intermediate permutations' (25th Sep),
> the difference being that I use pseudo-random
> permutations, while you employ special permutations,
> if I don't err.
>
> It may be of interest to note that, if the file, i.e.
> the array data, has 2^m elements, then one way of
> applying a Feistel cipher is doing recursion, i.e.
> first dividing the whole into two halves for Feistel
> processing which is itself done by subdivision and so
> on. See the thread 'On higher order Feistel schemes'
> posted by me on 13th May.
That was my design in TC5, and Matt Blazes idea for Turtle, this is
nothing new!!!!
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: CiPHER <[EMAIL PROTECTED]>
Crossposted-To: alt.freespeech,talk.politics.misc,talk.politics.crypto
Subject: Re: Updated XOR Software Utility (freeware) Version 1.1 from Ciphile Software
Date: Wed, 08 Nov 2000 12:40:50 GMT
In article <8ubfq9$d6t$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
> In about the same time it took me to write the xor program I wrote a
> simple commandline utility (ANSI C) that uses SHA-256/RC4 to parse
> passwords+IV and encrypt/decrypt files. That program compiles to 14kb
> and is way more practical then the XOR program. (if anyone wants the
> source or exe to the SHA/RC4 program email me at [EMAIL PROTECTED])
>
> Tom
Damn right a SHA implementation is more practical. The comparison in
strength and/or literal point to XOR is actually... welll...
incomparable.
Producing an XOR program is like producing a Substitution program for
encrypting text and proudly displaying it on a 'company' webpage for all
to see.
// SIDE NOTE
It makes me wonder why this guy posts at all. Sure there's a theory that
all publicity is good publicity, and it works as far as getting hits to
a webpage goes... but I have to question how this is doing any favours
to the takeup of his product?
He may have avoided all this negative, and quite damning, attention if
he hadn't posted to cryptography newsgroups in the first place. People
would have happily d/led his stupid programs without knowing of the
gaping errors in his logic.
He also may have avoided all this if he had simply operated open-
source. He could accept the problems, fix his simple, badly coded
programs and maybe get some actual support for what he was doing.
--
Marcus
---
[ www.cybergoth.cjb.net ] [ alt.gothic.cybergoth ]
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: CiPHER <[EMAIL PROTECTED]>
Crossposted-To: alt.freespeech,talk.politics.misc,talk.politics.crypto
Subject: Re: Updated XOR Software Utility (freeware) Version 1.1 from Ciphile Software
Date: Wed, 08 Nov 2000 12:39:57 GMT
In article <8ubfq9$d6t$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
> In about the same time it took me to write the xor program I wrote a
> simple commandline utility (ANSI C) that uses SHA-256/RC4 to parse
> passwords+IV and encrypt/decrypt files. That program compiles to 14kb
> and is way more practical then the XOR program. (if anyone wants the
> source or exe to the SHA/RC4 program email me at [EMAIL PROTECTED])
>
> Tom
Damn right a SHA implementation is more practical. The comparison in
strength and/or literal point to XOR is actually... welll...
incomparable.
Producing an XOR program is like producing a Substitution program for
encrypting text and proudly displaying it on a 'company' webpage for all
to see.
// SIDE NOTE
It makes me wonder why this guy posts at all. Sure there's a theory that
all publicity is good publicity, and it works as far as getting hits to
a webpage goes... but I have to question how this is doing any favours
to the takeup of his product?
He may have avoided all this negative, and quite damning, attention if
he hadn't posted to cryptography newsgroups in the first place. People
would have happily d/led his stupid programs without knowing of the
gaping errors in his logic.
He also may have avoided all this if he had simply operated open-
source. He could accept the problems, fix his simple, badly coded
programs and maybe get some actual support for what he was doing.
--
Marcus
---
[ www.cybergoth.cjb.net ] [ alt.gothic.cybergoth ]
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Colin Watson)
Crossposted-To:
alt.lang.basic,alt.permaculture,alt.surfing,alt.surfing.europe.uk,aus.computers.linux,comp.os.linux.setup
Subject: Re: hacker...beware
Date: 8 Nov 2000 12:54:36 GMT
John Savard <[EMAIL PROTECTED]> wrote:
>On Wed, 8 Nov 2000 19:27:58 +1000, yogi <[EMAIL PROTECTED]> wrote, in
>part:
>>The best thing to do is just chill out... System administrators turn
>>off the monitoring facility of firewalls once they are satisfied their
>>rules work...
>
>One is never sure that a firewall always works: monitoring is used to
>find out what has happened in case an attack is ever successful. And
>fewer computers would be hacked, the more deterrence existed for
>attempts to make unauthorized use of them.
True, but not every access is malicious. The original poster just
asserted that his firewall had detected a cracking attempt, but gave no
details. For all we know it could be somebody telnetting to port 80.
Without more evidence I'm sceptical; people who panic to Usenet about
every portscan obviously haven't run an Internet-connected firewall for
long.
Er, followups somewhere else. To poster will do.
--
Colin Watson [[EMAIL PROTECTED]]
"And I forgot the next verse / Oh well, I guess it pays to rehearse
The music sheet's so hard to find / What are the words? Oh nevermind"
- "Smells Like Nirvana", Weird Al
------------------------------
From: "Carsten Bauer" <[EMAIL PROTECTED]>
Subject: Re: hacker...beware
Date: Wed, 08 Nov 2000 21:01:17 +0800
Crossposted-To:
alt.lang.basic,alt.permaculture,alt.surfing,alt.surfing.europe.uk,aus.computers.linux,comp.os.linux.setup
In article <3a0884ad$0$19405$[EMAIL PROTECTED]>, "Gary"
<[EMAIL PROTECTED]> wrote:
> The following person (who posts on the above newsgroups)has been
> detected by my firewall as attempting to hack into my system. He/she has
> been reported to the isp concerned and details are as follows.
>
> Name E-mail address Date Thread Newsgroup Vic Drastik
> [EMAIL PROTECTED] 00/04/20 comp.lang.basic.misc Mongolian Horde
> [EMAIL PROTECTED] 00/01/05 alt.surfing
> *Lauren* [EMAIL PROTECTED] 99/11/06 alt.music.moffatts
> Mongolian Horde [EMAIL PROTECTED] 99/11/05 alt.surfing Mongolian
> Horde [EMAIL PROTECTED] 99/11/05 Location of 203.101.94.94:
> Country = Australia Region = New South Wales City =
> Sydney
> Standard network info
> [ nslookup (1): ip=203.101.94.94,
> hostname=async93-wol-isp-1.nas.one.net.au]
Most likely a skript kiddy trying to look cool.
Can you paste your logfile on here, as i'm interested in knowing what
exactly this "hacker/cracker" did.
--
Carsten Bauer
[EMAIL PROTECTED]
PGP Key - http://members.dingoblue.net.au/~numloxx/pgp.asc
------------------------------
** 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
******************************
