Cryptography-Digest Digest #990, Volume #11 Fri, 9 Jun 00 16:13:01 EDT
Contents:
Re: PK analogue for passwords ([EMAIL PROTECTED])
Re: My lastest paper on Block Ciphers (Runu Knips)
Re: How did Mr. Schneier calcuate this figure? (John Myre)
Re: Extending the size of polyalphabetic substitution tables
([EMAIL PROTECTED])
Re: Multiple encryptions (James Felling)
Re: Random IV Generation (David A. Wagner)
Re: RIP Bill 3rd Reading in Parliament TODAY 8th May (David Swarbrick)
Re: Thoughts on an encryption protocol? (John Myre)
Double Encryption Illegal? (Crypto-Boy)
encoding of passwords ("Wouter")
Re: Random IV Generation (John Myre)
Re: help for rc5 cryptanalysis (James Felling)
Re: Random IV Generation (David A. Wagner)
Re: My lastest paper on Block Ciphers (Simon Johnson)
Re: randomness tests ("John Feth")
Re: encoding of passwords (Custer)
Re: encoding of passwords (Custer)
Re: OT: Starmath font (tomstd)
Re: My lastest paper on Block Ciphers (tomstd)
Re: My lastest paper on Block Ciphers (tomstd)
Re: My lastest paper on Block Ciphers (tomstd)
Re: Encoding 56 bit data ---HELP--- (tomstd)
Updated: Evidence Eliminator Dis-Information Center (Includes info on false SPAM
accusations) (EE Support)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.security.misc
Subject: Re: PK analogue for passwords
Date: Fri, 09 Jun 2000 16:57:03 GMT
[sigh. sorry for formatting. I am too lazy to fix it today.]
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> In article <8hoq4f$cuo$[EMAIL PROTECTED]>, wrote:
> > if one is using twonz to keep their
> > financialinstitution.com password secret, they would enter their pad
in
> > one text field, and financialinstition.com in the second text field,
and
> > the program would run the inputs through a hash function (probably
md5
> > since it is widely available on free unices) and then base64 encode
the
> > result, so one could type the whole thing without too much effort.
:)
>
> That sounds like a variation on the RFC1938 OTP scheme (perhaps it IS
> RFC1938, if we don't take "base64 encode" literally).
>
> I've seen a couple of implementations for that, but never heard of
anyone
> actually using it before.
Well, the twonz program does indeed base64. The program is GPL, so what
the heck, lets post it! ;)
This points out though that I was wrong -- SHA-1 instead of md5. :) I
think the substitutions at the end remove spaces, newlines, etc, and
truncates the result to 8 chars. It looks trivial to get more characters
out of it, but since it is SHA-1, the max is probably around 22
characters. (Although the inputs to the system are probably less than 22
bytes of entropy!)
I found it here: http://www.interlog.com/~gray/twonz/twonz
#!/usr/bin/perl
#
# twonz is copyright (C) 1999 Vengeance Software
# released under the terms of the GNU GPL v2.0+
# written by Graydon Hoare <[EMAIL PROTECTED]>
#
use Tk;
use SHA;
use MIME::Base64;
my $main = new MainWindow;
my $context = new SHA;
$hashval = '';
$padval = '';
$literalval = '';
my $pe = $main->Entry( show => '*', width => 25 , relief => 'sunken',
textvariable => \$padval);
my $le = $main->Entry( width => 25 , relief=> 'sunken', textvariable =>
\$literalval);
my $he = $main->Entry( width => 25, state => 'disabled' , relief=>
'groove', textvariable => \$hashval);
$pe->pack(anchor=>"w");
$le->pack(anchor=>"w");
$he->pack(anchor=>"w");
$main->bind('<KeyPress>', \&digest);
MainLoop;
sub digest {
$context->reset();
$context->add($padval);
$context->add($literalval);
$hashval = encode_base64($context->digest());
$hashval =~ s/\W//g;
$hashval =~ s/(\w{8}).*/$1/g;
}
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Fri, 09 Jun 2000 19:08:08 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: My lastest paper on Block Ciphers
Simon Johnson wrote:
> Well, rather than moaning about trival portibility issues, i downloaded
> word view from softseek.com.
Useless. I've Word97 anyway here at work. And the font doesn't work :-(
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: How did Mr. Schneier calcuate this figure?
Date: Fri, 09 Jun 2000 11:09:37 -0600
(In reference to IDEA,)
Jeff Moser wrote:
>
> On page 323 of Applied Cryptography 2nd Edition, 3/4 of the way down the
> page. Schneier explains that weak keys are (in hex)
>
> 0000, 0000, 0x00, 0000, 0000, 000x, xxxx, x000
>
> To me, this seems like a total of up to 28 bits (7 * 4). Therefore, the
> likelihood of getting one seems to be 2^28/2^128 = 1/2^100, however the
> books says 1 in 2^96. Could somehow tell me where I'm making a mistake?
Joan Daemen's paper on IDEA's weak keys actually gives examples of
several classes of weak keys. So I think the above pattern is only
one kind of weak key. Indeed, Schneier says "For example, a weak key
is" the pattern above. So you have to combine the various classes
to get the right probability.
As to whether 2^96 is the correct figure, I don't understand the
paper well enough to tell, but I think it must be taken as too
simple, at least. The last section of the paper mentions a different
class of weak keys, that takes more work to check, and that has 2^51
keys in the class. So the probability of getting a weak key depends
on your definition of which keys you take as weak.
John M
P.S.
You can find some of Daemen's papers at
http://www.esat.kuleuven.ac.be/~rijmen/daemen.html
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Extending the size of polyalphabetic substitution tables
Date: Fri, 09 Jun 2000 17:23:07 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> But if you have the same high quality S-boxes, wouldn't it be
> better if you could use more of them?? (In the original context
> I was discussing using a larger substitution tabl, nothing more.
> There was no implication that enlarging the table is necessarily
> coupled with a degradation of the quality of the individual column
> of the table. There is in fact no such coupling.)
I have never designed S-Boxes, but the good people at IBM spent a very
long time designed the Lucifer and DES S-Boxes, at which time the people
at the NSA helped tweak the S-Boxes to make them more resistant to
attacks not known at IBM. It seems to me that designing good S-Boxes
takes time, and to double both dimensions of S-Boxes will make it more
than four times as difficult to make good S-Boxes. So, a degredation of
quality would not be unreasonable. If one has resources to devote to
making S-Boxes both large and well-tuned, all the better. :)
> I wonder how you got the association with OTP at all in this thread.
> A classical polyalalphabetical substitution has by itself nothing to
> do with OTP. In fact OTP was invented much much later than that.
> There is of course on the other hand no exclusion in usage of the
> two, i.e. you can use both in combination. But that is not relevant
> here, isn't it?
Well, no, not relevant to the S-Box case (afaik) -- however,
polyalphabetic substitution is *exactly* like OTP, iff one ensures the
key does not repeat. If the key does repeat (based on a reading of
Gaines this is how most were used), no matter the size of the
polyalphabetic substition tables, I can deduce an equivalent OTP given
only the key and the tables. Thus, (in the classical polyalphabetic
usage!) it is equivalent to the OTP. (Well, heck -- even if the key does
not repeat, given the key and the tables I can devise an equivalent OTP.
If the key repeats, a cryptographer could trivially retrieve plaintext
and (a) key without knowledge of tables, key, or plaintext.)
> But in my original post the only thing I wrote relating to PRNG was
> use of pseudo-random numbers. (Note that not even the term
> PRNG occured there.) It is understood that these numbers must
> come from some PRNG and that those who actually do what I said
> there will naturally take care to choose one appropriately. Please
> tell me why I should have recommended any specific PRNG there, even
> if BBS or another one were my most favourite PRNG. If you are
> convinced of the superiority of BBS, I don't have any objection. But
> to bring out the issue that BBS is good is not relevant for the
> present thread in my humble view. You could warn that, if one uses
> pseudo-random numbers (the 3rd alternative in my original post) then
> one should take care to use a crypto strong one. That would be o.k.
> (Suppose the topic were about getting stuffs print out from computer.
> I would suggest using a laser printer. The analogy of your BBS above
> would be your saying using a HP Laser Jet. Do you see my point?)
Ok, this makes sense. However, I was working under the assumption that
you intended to use this thing to secure your data; in that light, I
hope you can understand why I suggested a particularly strong PRNG.
:)
regards
seth
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: Multiple encryptions
Date: Fri, 09 Jun 2000 12:43:58 -0500
AllanW wrote:
> We have some encryption program E, and we use it whenever
> we send messages to each other. E is meant to take any
> plaintext (even non-printable data) and encrypt it, to
> transmit it safely to other sites. E identifies the
> encrypted data with a brief cleartext message at the
> start of it's output, to allow the decryption engine to
> avoid trying to decrypt data that never was encrypted.
> Therefore, anyone that can intercept our messages already
> knows we use encryption program E.
>
> Secretly, we also have another encryption program D. It
> isn't public knowledge, but what we really do is take our
> data files and encrypt them with D. Then we take the D
> output and feed that into E. Programs D and E know
> nothing of each other; each is meant to be used as a
> stand-alone encryption engine. D also appends some
> cleartext at the beginning of it's output, but of course
> E encrypts that so our use of D is *mostly* a secret.
>
> I've heard that this hypothetical case is a bad idea, and
> not just because of any false sense of security. Someone I
> respect tells me that the result is actually LESS secure
> than using either D or E alone.
>
> How can this be?
As a rule unless D and E are some how related this is at least as strong
as the stronger of D and E, and may well be stronger than that.
However, to using lame examples it can be shown that if D and E are
related the potential of compromise exists.
i.e. if D= N*Message mod P, and E= X* Message Mod P, then D(E(Message))
is as secure as D or E except when N*X mod P =1 in which
D(E(message))=Message. so the system is no stronger, and can be weaker.
So long as D and E do not work by similar mechanisms there will be
little risk of this occuring though -- effectively 0 if you choose D
and E with care.
>
>
> Let's say that word leaks out that we're using D before we
> use E. Someone uses this knowledge to come up with
> frequency distribution or some other pattern for D's
> output. Perhaps it gives them a minor leg up on what output
> to expect from E. But can the result actually be easier to
> crack than cracking D or E alone?
>
> If you can explain why the answer is YES, then I have
> another related question:
>
> Suppose that D is a home-grown "security by obscurity"
> encryption engine that was never released to the public.
> Therefore it was never given public scrutiny, and it may in
> fact have one or more extreme weaknesses that anyone
> familiar with encryption (except the author) could have
> easily detect, if they got a chance to review the code
> and/or analyze the output. But, the source code is held by
> a few trusted individuals and the "encrypted" output is
> never retained after it's been fed to program E or returned
> out of program E, so there's no way to do frequency analysis
> or anything similar. Does your explanation to the first case
> still fit the second case?
>
> Obviously these cases are all hypothetical and I'm not
> advocating anyone actually doing this. I appreciate any
> explanations you can give me.
>
> --
> [EMAIL PROTECTED] is a "Spam Magnet," never read.
> Please reply in newsgroups only, sorry.
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: Random IV Generation
Date: 9 Jun 2000 11:00:43 -0700
In article <[EMAIL PROTECTED]>, Terry Ritter <[EMAIL PROTECTED]> wrote:
> There *is* a reason to keep an IV secret: With CBC an exposed IV
> allows an opponent to change the recovered plaintext for the first
> block at will.
I suppose that's a plausible reason, but it's much better
to just MAC everything (the IV and the ciphertext), so I'm
not sure it's a very *good* reason.
------------------------------
From: David Swarbrick <[EMAIL PROTECTED]>
Crossposted-To: uk.media.newspapers,uk.legal,alt.security.pgp
Subject: Re: RIP Bill 3rd Reading in Parliament TODAY 8th May
Date: Fri, 9 Jun 2000 07:42:51 +0100
In article <8hm984$g15$[EMAIL PROTECTED]>, zapzing <[EMAIL PROTECTED]>
writes
>
>It occurs to me that there are other protocols
>for authentication that do not rely on anything
>like a key. One of them has to do, I think, with
>graph isomorphism. I remember reading about it
>somewhere.
A key is defined very widely - as whatever will allow the message to be
converted back into plaintext.
--
David Swarbrick, Solicitor. Computer and Internet Law and Contracts
[EMAIL PROTECTED] T: +44(0)1484 722531 F: +44(0)1484 716617
Law-index of 11,100+ case summaries at www.swarb.co.uk
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Thoughts on an encryption protocol?
Date: Fri, 09 Jun 2000 12:10:08 -0600
Dido Sevilla wrote:
>
<snip>
>
> Basically, some high-ranking person will go to each terminal, swipe a
> special card across its barcode swipe reader, punch in a password, and
> then punch in the new start key. This would be done every three months.
I seem to recall you specifying two 256-bit keys. You might have to
work on the encoding method a while to make it reasonable to type that
much information in. Also, be careful of the pieces of paper from which
the high ranking person types...
John M
------------------------------
From: Crypto-Boy <[EMAIL PROTECTED]>
Crossposted-To: comp.databases.oracle
Subject: Double Encryption Illegal?
Date: Fri, 09 Jun 2000 18:09:04 GMT
On page 10-10 and 10-14 of the Oracle Advanced Security Administrator's
Guide (from release 8.1.6 December 1999), it says the following (in bold
no less):
"Warning: You can use SSL encryption in combination with another Oracle
Advanced Security authentication method. When you do this, you must
disable any non-SSL encryption to comply with government regulations
prohibiting double encryption."
Since when is it illegal to double encrypt in the US? I don't believe
this is true.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Wouter" <[EMAIL PROTECTED]>
Subject: encoding of passwords
Date: Fri, 9 Jun 2000 20:34:24 +0200
I want to know how the encoding of password occurs in Unix / Linux -systems
(the /etc/passwd file).
I know that it uses DES, and I understand how a block of 64 bits (and a key
of 64 bits) can be encrypted using DES, which results in a block of 64 bits
of encrypted data. I suppose the password is the original data that will be
encrypted, but then what's the key which is also needed for the encryption?
Does this have something to do with the 'salt'? And what if the password is
smaller than 8 characters (64 bits)? The encrypted password is 13 characters
(13x7 = 91 bits). How is this possible?
I hope someone can help me. I've been looking on the Internet and found a
lot of information about DES, but I cannot find answers to this question.
Thanks in advance.
Wouter
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Random IV Generation
Date: Fri, 09 Jun 2000 12:35:41 -0600
"David A. Wagner" wrote:
>
<snip details>
>
> Use random, unpredictable IV's. Non-random IV's are risky.
Would it be sufficient to use the encryption of the counter
as the IV? It's only predictable if you know the key, and I
assume our encryption algorithm withstands known plaintext.
I like the idea of only using one primitive.
If you don't want to encrypt the counter separately to define
the IV, you could prefix your message with the counter and then
encrypt with a zero IV (or prefix with zero and use the counter
as the IV). The reciever would operate the same in any case.
John M
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: help for rc5 cryptanalysis
Date: Fri, 09 Jun 2000 13:45:11 -0500
Stanley wrote:
> Hi
> I know there are many experts in this group. Could anyone help me out on
> cryptanalysis of rc5, with just 8 rounds without any rotations? A hint of
> how to break it will be great. Thanks in advance.
>
> Stanley
First off assume the S's are completely random. Your mission is to retrieve
all such S's ( or at least S's that produce an identical encryption)
Then the out put of the nth round is (L^R) +S(2n), (L^R) +S(2n+1), look at
the last bit of this -- this should allow you to identify traits of
Watch the last bit of this output. This will give you information in re: The
parity of this round, and of the previous round. Remember on a bitwise scale
0+0=1+1=0, and 0+1=1+0=1, .( Very XOR like, huh). Watch the XOR's through
the cypher. One known plaintext will allow you to determine the last bit
parity of all 8 rounds. ( This is left as an exercise for the student). Then
examine bit 1 of the output pair, remembering that if the bit 0 parity is
odd, then this is XOR, and if even then it is either XOR( iff both bit 0's
are 0, or XNOR if both are 1). One plaintext will provide tons of info.
This will give you a good start.
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: Random IV Generation
Date: 9 Jun 2000 12:05:06 -0700
In article <[EMAIL PROTECTED]>, John Myre <[EMAIL PROTECTED]> wrote:
> "David A. Wagner" wrote:
> > Use random, unpredictable IV's. Non-random IV's are risky.
>
> Would it be sufficient to use the encryption of the counter
> as the IV?
I don't know of any problems with it. It's probably ok, but I'd feel
much better about it if I had a proof.
Here's one reason to be cautious. If you instead use the _decryption_
of a counter as the IV, things are not ok. The problem in such a case
is that you're using the same key for both IV generation and message
encryption.
The key reuse makes it hard to prove that your proposal is safe; and,
as the decryption example illustrates, it might even cause weaknesses
in some cases, so this might not be just a theoretical concern (maybe).
If you were to use an independent key for IV generation, then it
would be "obviously safe" (I think). (The outputs of counter mode are
indistinguishable from random if the block cipher is.)
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: My lastest paper on Block Ciphers
Date: Fri, 09 Jun 2000 19:02:27 GMT
In article <[EMAIL PROTECTED]>,
Paul Koning <[EMAIL PROTECTED]> wrote:
> tomstd wrote:
> >
> > I have just finished the Draft of my latest paper. It's called
> >
> > "On Cryptographically Strong F Functions"
> >
> > And is available (sorry) only in Word97 format at
>
> You're going to find it much easier to get people interested
> in looking at things if you post PDF files. Or even PS files.
> PDF files you can do easily, though it may cost you a small
> sum to get the needed software. (Or perhaps not anymore?).
> PS you can do with Word at no charge, just install the PostScript
> printer driver.
>
> paul
>
Hi, I know this is a cryptography forum, but i've been looking for some
post-script viewers for windows.
Could you direct me to some.
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "John Feth" <[EMAIL PROTECTED]>
Subject: Re: randomness tests
Date: 9 Jun 2000 18:53:50 GMT
The Allan Deviation is an excellent test. It shows any correlation between
all string lengths up to N/2, N being the number of digits in the
putatively random string. Best to look at strings a few thousand, or
better, a few hundred thousand digits long. Lots is written about this
test and available from NIST in Boulder Colorado.
Regards
John Feth
------------------------------
From: Custer <[EMAIL PROTECTED]>
Subject: Re: encoding of passwords
Date: Fri, 09 Jun 2000 14:56:36 -0400
"Wouter" <[EMAIL PROTECTED]> wrote:
>I want to know how the encoding of password occurs in Unix / Linux -systems
>(the /etc/passwd file).
>I know that it uses DES, and I understand how a block of 64 bits (and a key
>of 64 bits) can be encrypted using DES, which results in a block of 64 bits
>of encrypted data. I suppose the password is the original data that will be
>encrypted, but then what's the key which is also needed for the encryption?
>Does this have something to do with the 'salt'? And what if the password is
>smaller than 8 characters (64 bits)? The encrypted password is 13 characters
>(13x7 = 91 bits). How is this possible?
>
>I hope someone can help me. I've been looking on the Internet and found a
>lot of information about DES, but I cannot find answers to this question.
>Thanks in advance.
>
>Wouter
>
>
Each character in the file /etc/passd is encoded with 6 bits. That
makes 64 characters, all printable.
The algorithm is a variation on DES; in fact, there are 4096
variations, and the variation used is indicated by the first 2
characters of the encrypted password. These two characters are called
"salt ".
The password is used as the key to encrypt the value 00000000 (8 times
zero). DES keys are 56 bits, each character is 7 bits.
Contrary to DES, there is not 16 turns but 400 (in the lastest
version). The result of these 400 turns is a word of 64 bits cut in 10
pieces of 6 bits and 1 piece of 4 bits which is 11 characters. Plus
the salt = 13 characters.
------------------------------
From: Custer <[EMAIL PROTECTED]>
Subject: Re: encoding of passwords
Date: Fri, 09 Jun 2000 15:15:38 -0400
...
>The password is used as the key to encrypt the value 00000000 (8 times
>zero).
Correction: the value is 64 bits set to zero, not 8 times the
character zero.
------------------------------
Subject: Re: OT: Starmath font
From: tomstd <[EMAIL PROTECTED]>
Date: Fri, 09 Jun 2000 12:24:16 -0700
In article <[EMAIL PROTECTED]>, Runu Knips
<[EMAIL PROTECTED]> wrote:
>tomstd wrote:
>> You can get the starmath True Type Font off my website at
>> http://tomstdenis.com/files/starmath.ttf
>
>Thank you, but my Windows says its corrupted :-(
Hmm just pick up the ps copy of the paper then
http://tomstdenis.com/ffunctions.ps.gz
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
Subject: Re: My lastest paper on Block Ciphers
From: tomstd <[EMAIL PROTECTED]>
Date: Fri, 09 Jun 2000 12:24:42 -0700
There is a PS copy at
http://tomstdenis.com/ffunctions.ps.gz
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
Subject: Re: My lastest paper on Block Ciphers
From: tomstd <[EMAIL PROTECTED]>
Date: Fri, 09 Jun 2000 12:25:38 -0700
I will try to use the latex tools in the future.
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
Subject: Re: My lastest paper on Block Ciphers
From: tomstd <[EMAIL PROTECTED]>
Date: Fri, 09 Jun 2000 12:27:22 -0700
Check out
http://tomstdenis.com/ffunctions.ps.gz
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
Subject: Re: Encoding 56 bit data ---HELP---
From: tomstd <[EMAIL PROTECTED]>
Date: Fri, 09 Jun 2000 12:30:27 -0700
In article <8hr2kq$2ii$[EMAIL PROTECTED]>, sarnold_intertrust@my-
deja.com wrote:
>In article <[EMAIL PROTECTED]>,
> tomstd <[EMAIL PROTECTED]> wrote:
>> In article <8hqpm1$r94$[EMAIL PROTECTED]>, dexMilano
>> <[EMAIL PROTECTED]> wrote:
>> >Is there some good algorithm coding 7 byte in 7 byte using a
>> masterkey.
>
>> May I ask why you want to encode only 7 bytes with only a 7
byte
>> key? It seems for most purposes a 7 byte key is too small...
>
>This brings to mind a question I have had for some time now; is
there
>any point in using a key larger than the data to be encrypted?
If there
>is danger in brute-force-searching the key, why not brute-force
search
>the plain-text instead? :)
Did you think that through at all? I hope not.
You can brute force a key offline, you can't do the same against
plaintext.
Also brute forcing a key is more practical then the plaintext
simply because I don't want to give you *any* ciphertext at all,
why would I give 2^64 or 2^128 blocks?
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: EE Support <[EMAIL PROTECTED]>
Crossposted-To:
alt.security.pgp,comp.security.firewalls,alt.privacy.anon-server,alt.privacy
Subject: Updated: Evidence Eliminator Dis-Information Center (Includes info on false
SPAM accusations)
Date: Fri, 09 Jun 2000 20:45:50 +0100
Reply-To: [EMAIL PROTECTED]
Hi all,
Our news input feed at evidence-eliminator.com has been out for a week
due to a dud satellite. We haven't been able to correct this weeks
dis-information posts against our software directly, but:
We have seen some posts coming on deja and remarq including false
"spam" accusations, etc, etc.
We don't "SPAM" but we strongly believe in our right to dispute and
counter the hundreds of "SPAMMING" false messages posted to security
newsgroups about our software. It has become commonly said by posters
to these newsgroups that the ones posting the "anti-Evidence
Eliminator" messages in all their disguises, are wearing badges and
intend to compromise your privacy and security, by stopping you
downloading a free Evidence Eliminator.
This week's false messages appear to span several newsgroups listed in
the header of this msg and this post is to counter those false rumors.
Our updated Dis-Information centre URL is:
http://www.evidence-eliminator.com/dis-information.shtml
Hope this helps,
--
Regards,
EE Support
[EMAIL PROTECTED] (remove NO_SP_AM for e-mail)
http://www.evidence-eliminator.com/
------------------------------
** 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
******************************
