Cryptography-Digest Digest #996, Volume #13 Sun, 25 Mar 01 17:13:01 EST
Contents:
Re: Best encryption program for laptop? (Albert P. Belle Isle)
Re: compression ratio as a predicter of cipher strength ("John A. Malley")
Re: compression ratio as a predicter of cipher strength (Frank Gerlach)
Re: New PGP Flaw Verified By Phil Zimmerman, Allows Signatures to be Forged (Bill
Unruh)
Re: compression ratio as a predicter of cipher strength ("Scott Fluhrer")
Re: 64 versus 128 (or bigger) bits cipher data block (Terry Ritter)
Re: Valid condition for multiplicative generator? (Terry Ritter)
Re: compression ratio as a predicter of cipher strength ("Douglas A. Gwyn")
Re: compression ratio as a predicter of cipher strength ("Douglas A. Gwyn")
Re: Compression-encryption with a key (Mok-Kong Shen)
Re: Data dependent arcfour via sbox feedback (Terry Ritter)
His in-law needs TLA (STEELEYE)
Re: Data dependent arcfour via sbox feedback (Mok-Kong Shen)
Arick wants to eat gentle carrots (Anonymous)
[INFO] Uppnorth asks to code PGP code (Nomen Nescio)
[INFO] FBI requires CIA ("A. Melon")
[WARNING] Xganon wants to fist-fuck PGP code ("Public " <[EMAIL PROTECTED]>)
[ANNOUNCE] CIA absolutely needs those Aids-infected NSA ("Public "
<[EMAIL PROTECTED]>)
Arick needs TLA (Anonymous)
Tr: Tuttle would love all NSA (Frog2)
My brother fucking wants gentle jews (Frog2)
My brother sure loves to print terrible republicans (Frog2)
Randseed certainly used some politically correct niggers (Frog2)
Cracow2 used some MIX keys (Nomen Nescio)
----------------------------------------------------------------------------
From: Albert P. Belle Isle <[EMAIL PROTECTED]>
Subject: Re: Best encryption program for laptop?
Date: Sun, 25 Mar 2001 14:49:54 -0500
Reply-To: [EMAIL PROTECTED]
On Sun, 25 Mar 2001 04:38:30 GMT, [EMAIL PROTECTED] wrote:
>My job is changing, and is going to require me to do some travelling.
>I would like to purchase a laptop, and continue to keep my home
>finances, and other private data, on it.
>what would be the best way to keep data safe, in case the laptop was
>stolen? Which encryption program? And, should it be encryption alone,
>or encryption coupled with a secure os like NT?
>Thanks.
Mr. Wilson:
As you may know, no product can provide "access control" to data on a
hard disk by merely restricting the booting or use of the particular
PC to which that disk is presently connected.
"Access" to your hard disk is by means of a standard connector into
which ANY other PC's drive controller cable may be plugged. Whether
the particular one of the millions of Windows machines currently
attached to that plug is yours or someone else's is pretty much
irrelevant.
You can, of course, cryptographically protect the data stored on your
hard drive, IF you eliminate all of Windows' extra "temporary" copies
of the plaintext, not just the one you replaced with an encrypted
version. This is the fundamental difference between encrypting e-mail
and using encryption as part of storage INFOSEC.
Any supposed data storage security product that doesn't eliminate ALL
copies of plaintext and keying material per DOD 5220.22-M, including
those made by Windows itself in TEMP space and the swapfile (and the
fragments captured into the tail clusters of new files, or into the
interiors of compound files like Word or Excel documents) is an
INFOSEC placebo.
On the other hand, NO product (including ours) can provide "security"
- merely eliminate specific INSECURITIES.
I'd suggest that you try to more precisely define the kinds of threats
which you wish to counter. You might find
http://www.CerberusSystems.com/INFOSEC/threats.htm
useful in starting the definition of your particular threat profile.
I hope you find the tutorials and federal cryptographic standards on
our web-site helpful in filtering various possibilities that are open
to you. If you'd like to try our product offerings, that'd be even
better <g>.
Albert P. BELLE ISLE
Cerberus Systems, Inc.
================================================
ENCRYPTION SOFTWARE with
Forensic Software Countermeasures
http://www.CerberusSystems.com
================================================
------------------------------
From: "John A. Malley" <[EMAIL PROTECTED]>
Subject: Re: compression ratio as a predicter of cipher strength
Date: Sun, 25 Mar 2001 12:13:48 -0800
Curtis Williams wrote:
>
> Hi,
>
> An encryption product claims that a ciphertext file should be compressed
> and the compression ration is a predictor of cipher strength (i.e. encrypt a
> file then zip it. if the compression ratio is 0, the encryption is strong).
> Is this valid or snakeoil?
>
Inability to compress the ciphertext output indicates the absence of
patterns or order in the ciphertext. This is a desirable property. The
detection of patterns or order in the ciphertext output is only as good
as the compression algorithm applied to the cipher, however.
How this relates to a scale of cipher "strength" is not clear. It tells
us something "relative" but not absolute AFAIK and it can't be used in
isolation from other information. The ability to compress the ciphertext
output of a cipher for all ciphertexts tells us the cipher is "weak."
The inability to compress the ciphertext output of a cipher does not
tell us anything about the absolute strength of the cipher.
For example:
The ciphertext output of a monoalphabetic substitution cipher is just as
compressible as the plaintext fed into it. And a monoalphabetic
substitution cipher is relatively "weak."
The ciphertext output of a Vigenere cipher is somewhat compressible but
not anywhere near as much as the simple monoalphabetic substitution
cipher. So it's stronger than the simple substitution cipher in this
comparison.
The ciphertext output of a one-time pad is incompressible. It's
relatively stronger than the previous two ciphers.
Encrypt two equal length messages with the same one-time pad and send
them to the same recipient. Both resulting ciphertexts are
incompressible. Sounds like this system is very strong - but - the fact
that we used the same OTP key twice seriously compromised both messages
and made it much easier for third parties to crack our encryption.
Inability to compress ciphertext output is a desireable property, but
this property by itself is not a complete indicator of cipher strength.
Hope this helps,
John A. Malley
[EMAIL PROTECTED]
------------------------------
From: Frank Gerlach <[EMAIL PROTECTED]>
Subject: Re: compression ratio as a predicter of cipher strength
Date: Sun, 25 Mar 2001 21:45:41 +0200
Uncompressibility is a required precondition, but is in no means satisfactory.
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Crossposted-To: alt.privacy.anon-server,alt.security.pgp
Subject: Re: New PGP Flaw Verified By Phil Zimmerman, Allows Signatures to be Forged
Date: 25 Mar 2001 20:19:38 GMT
In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (Free-man) writes:
>I expect the PGP team at NAI to respond soon with a patch because they
>did so when that ADK bug was found in 653
No. As I understand this, this is not a problem with the NAI PGP per se, but a problem
with
the Open PGP standard specification. That is not owned by NAI. It is the
specification which needs to be changed. Now any particular
implimentation can impliment additional checks to try to get around this
bug in the standards, but a change in standardss would be much better.
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: compression ratio as a predicter of cipher strength
Date: Sun, 25 Mar 2001 12:51:02 -0800
Curtis Williams <[EMAIL PROTECTED]> wrote in message
news:l0rv6.10793$[EMAIL PROTECTED]...
> Hi,
>
> An encryption product claims that a ciphertext file should be compressed
> and the compression ration is a predictor of cipher strength (i.e. encrypt
a
> file then zip it. if the compression ratio is 0, the encryption is
strong).
> Is this valid or snakeoil?
Well:
- A strong ciphertext might be compressable if the encryptor delibrately
produced a nonuniform output. The most obvious example of this is PGP in
"ASCII-Armor" mode. In this mode, the ciphertext (apart from headers)
consists of 66 different characters, and thus is moderately compressable.
This compressability has nothing to do with how strong PGP ciphertexts are.
- Assuming that the ciphertext file is produced raw (with all bytes
equiprobable, and often with minimal or no ciphertext expansion), it will be
uncompressable -- any compressibility will indicate patterns that are almost
surely exploitable by an attacker. However, existing compression routines
are rather naïve when detecting patterns -- certainly not nearly as good as
a human attacker -- and so this is an extremely low bar for testing
encryption products. Any encryption product that doesn't pass this is a
total loser, but passing it is no particular guarantee.
--
poncho
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: 64 versus 128 (or bigger) bits cipher data block
Date: Sun, 25 Mar 2001 21:00:17 GMT
On Sat, 24 Mar 2001 20:32:24 -0800, in
<99jsvh$gn7$[EMAIL PROTECTED]>, in sci.crypt "Scott Fluhrer"
<[EMAIL PROTECTED]> wrote:
>Peter <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> Someone can explain me main reasons (or all) for which 128 bits block
>> is better than 64 bits block?. I had made think on this and I found
>> some goals for use bigger block but I still dont know if they are
>> primary.
>Well, it mostly has to do with security when encrypting a large number of
>blocks with the same key.
I see several issues beyond that:
First, I think a block should be large enough to contain more
plaintext entropy than the key. A reasonable approach might assume 1
bit per character, which would imply 80 characters or more, a 640 bit
block, minimum. Alternately, for a 256-bit block, we would need about
3 times the expected entropy in our plaintext, which may be achievable
with appropriate compression.
Next, I think a block should be large enough to efficiently support
fields of "extra data," beyond the plaintext itself:
One use for "extra data" would be as a keying field to hold a
block-by-block validation or authentication value. That could be as
simple as a static hash of the key, or as complex as a stream cipher
keying sequence. The idea would be for some secret value to be
enciphered along with the plaintext. Then, if the resulting
ciphertext were modified, deciphering would not produce the secret
value, and the modification would be detected.
Another use for "extra data" would be as a homophonic field. This
would be some dynamic random value, which need not be known at the
receiving end. This would produce a plethora of different ciphertext
blocks each of which would represent exactly the same plaintext. In
this way, identical plaintexts probably would not produce the same
ciphertext, and would not need a "mode of operation."
The implication of "efficient support" for an extra 80 + 80 = 160 bits
might be a block at least 1600 bits. I would suggest compromising on
4096 bits, which is a convenient 512-byte block, to reduce a 20-byte
overhead to under 5 percent.
Maybe we could choose one scheme or the other, or find a way to do
both in the same 80 bits. But that would still be almost 25 percent
of a 256-bit block, which I would call substantial overhead.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Valid condition for multiplicative generator?
Date: Sun, 25 Mar 2001 21:02:03 GMT
On Sat, 24 Mar 2001 17:08:30 -0500, in <[EMAIL PROTECTED]>,
in sci.crypt Steve Portly <[EMAIL PROTECTED]> wrote:
>Frank Gerlach wrote:
>
>> BTW. have you ever played with RNGs based on the frequency difference drift
>> between CPU clock and timer clock ? Didn't find anything related to that on
>> your page.
>
>I think Terry Ritter is the resident expert on clock drift. A while back I
>started to propose a PRNG based on the RDTSC instruction. Terry pointed out
>that most if not all of the variations I was seeing in my output were probably
>due to phase oscillation. I had developed a crude parity based decoherence
>method that yielded symmetrical bit bucket output and was thinking that perhaps
>I had mined some genuine random bits. Terry explained that since the phase
>oscillations from my scheme are also symmetrical it did not prove a that my
>output was random. A PRNG Based on RDTSC has got to be better than one based on
>a lava lamp though. :-)
While the idea does seem less amusing than a Lava Lamp, a Lava Lamp
does at least involve a huge and complex -- thus nondeterministic in
detail -- physical system. In contrast, a computer is nothing if not
absolutely deterministic. So, if the desire is for unknowable
randomness, a Lava Lamp at least brings something to the party.
On sci.crypt, we have been through "clock drift" and "phase noise"
discussions in extensive detail (tens of postings) three or more times
in the past decade. In retrospect, the discussions have been quite
roundabout, which I ascribe to two false yet strongly-believed
assumptions: 1) usable amounts of unknowable randomness "must" exist
in computer clock signals; and, 2) that randomness can somehow be
collected on an ordinary PC.
But where does these ideas come from? Why *should* relatively stable
crystal-controlled clocks be seen as a useful source of unknowable
randomness? When did a computer with a multitasking OS suddenly
become a real-time measurement facility?
The idea that different clocks often run at different rates was
universal practical knowledge prior to the development of
quartz-controlled watches and clocks. If we measure a rate difference
between clocks, that might be an arguably random value -- once. But
what could possibly be increasingly random about two clocks running at
two different but generally fixed rates? In practice, the rates will
vary somewhat, but with crystal-controlled sources, do we really
expect the variations to be large enough to be worthwhile? Is it
reasonable to expect these variations to not correlate to temperature
in a repeatable way? Why *should* anyone imagine this to be a good
source of entropy?
But the *main* issue is that it is necessary to measure the clock rate
on a stock PC. Since a normal PC has no hardware timers which would
automatically measure the width of a lower-speed clock, the
measurement must involve software. Typically, one might loop while
the measured signal is high (or low, or for a full cycle) and either
count loopings, or afterward sample the processor cycle counter.
Unfortunately, a multitasking OS will be answering interrupts during
the counting period, resulting in an unknown and widely-varying
latency for detecting the end of cycle. There will be interrupts for
I/O, interrupts for timing, interrupts for task-change, and interrupts
for memory refresh. All these interrupts will involve execution which
will delay end-of-cycle detection. And all these interrupts are part
of a complex but nevertheless deterministic system which could be more
or less predicted externally with less than cryptographic effort.
Where would any fundamental randomness come from? How could it be
detected on a stock PC?
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: compression ratio as a predicter of cipher strength
Date: Sun, 25 Mar 2001 21:03:08 GMT
Tom St Denis wrote:
> FOR X = 0 to 10000
> FOR Y = 0 to 255
> OUTPUT (2X + 1)Y mod 256
> NEXT Y
> NEXT X
> That data is far from random yet completely uncompressible.
Not so -- you have already compressed it to around 70 characters,
and further compression is possible. It probably *does* fool some
specific compression algorithms, which is enough to make your point.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: compression ratio as a predicter of cipher strength
Date: Sun, 25 Mar 2001 21:04:47 GMT
Frank Gerlach wrote:
> Uncompressibility is a required precondition, ...
No. A ciphertext can be completely secure against cryptanalysis
and still be compressible. An example is easy to concoct; I
leave it as an exercise for the sake of enlightenment..
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Compression-encryption with a key
Date: Sun, 25 Mar 2001 23:00:54 +0200
Tom St Denis wrote:
>
> "Mok-Kong Shen" <[EMAIL PROTECTED]> wrote:
> > The question is whether Scott's idea reduces the total
> > amount of effort to crack, in that you don't need to
> > check plausible plaintext. As said, I don't know the
> > answer. Maybe Scott would argue with you.
>
> Oh I agree it takes a little more work in his method. The problem is that
> it's symmetric ammount of work and is linear. I.e by adding a layer of
> compression you make it slower (jsut as slow) for legitimate users as
> attackers and increase the complexity of a search linearly (i.e like using
> multiple encryptions with the same key).
>
> A smart person would say "why not use a bigger key?" It's assymetric in the
> time requirements and exponentially harder (in theory) for the attacker.
You have to look at it a bit differently. It is at first
a decision whether you want compression. If no, the
argument about 1-1 (terminology of of Scott) doesn't
exist from the very beginning. If yes, then Scott claims
that a 1-1 scheme is advantageous. The question is
how much is that advantage in the context of all means
available to an opponent. (I don't know the answer.)
Given that you use a certain chosen block cipher with
some fixed size of keys, the use of compression can be
an option, but not the use of a larger key, I suppose.
(Of course, you could use multiple encryptions.)
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Data dependent arcfour via sbox feedback
Date: Sun, 25 Mar 2001 21:10:44 GMT
On Sun, 25 Mar 2001 13:17:22 +0200, in
<[EMAIL PROTECTED]>, in sci.crypt Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>John Savard wrote:
>>
>> Ken Savage <[EMAIL PROTECTED]> wrote:
>>
>> >Any thoughts? Replies via newsgroup or email -- I read both :)
>>
>> Making something like RC4 dependent on the plaintext will collide with
>> Terry Ritter's Dynamic Substitution patent.
>
>Using intermediate results during processing to do feedback
>is in my humble view what scientists and engineers have been
>doing since time immemorable in countless cases as matters
>entirely self-evident. Specific examples: step size adjustment
>in solving differential equations, temperature reading to
>control air-conditioning of rooms. In general: iterations,
>servo-mechanisms, etc. (I am aware, though, of stuffs
>like Hitachi's rotation patent.)
So, in your humble-yet-informed opinion, with a knowledge of US patent
law, and having studied the specific patent in question, it would not
apply in this situation. How great it is to have an expert who is
willing to share with us his informed opinion.
Now if you would only share the details of your analysis, I'm sure we
would all benefit.
Actually, the Dynamic Substitution patent is quite broad and general,
as one would expect from the first patent in a new technology area.
The issue is not whether some general analogy can be found in all
previous technology; the issue is whether this specific approach to
cryptography had previously been published.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
Date: Sun, 25 Mar 2001 23:24:41 +0200
From: STEELEYE <[EMAIL PROTECTED]>
Subject: His in-law needs TLA
Crossposted-To: alt.privacy.anon-server,alt.security.pgp
[ANNOUNCE] Arick certainly uses to decypher remaining of priapic perl
scripts
0,207489 0,1211056 0,2859564 -2001/03/25 16:41:25-
Script-Kiddie MASTER of APAS/ADRU/SM/AUK
For a 21st Century completely REMAILER-FREE
That CRAP brought to you by request from Thomas J. BOSCHLOO
[EMAIL PROTECTED]
LefArris requires to eat some terrible MIX keys
Stealth absolutely asks to encode radishes
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Data dependent arcfour via sbox feedback
Date: Sun, 25 Mar 2001 23:19:06 +0200
Terry Ritter wrote:
>
> Mok-Kong Shen<[EMAIL PROTECTED]> wrote:
>
> >John Savard wrote:
> >>
> >> Ken Savage <[EMAIL PROTECTED]> wrote:
> >>
> >> >Any thoughts? Replies via newsgroup or email -- I read both :)
> >>
> >> Making something like RC4 dependent on the plaintext will collide with
> >> Terry Ritter's Dynamic Substitution patent.
> >
> >Using intermediate results during processing to do feedback
> >is in my humble view what scientists and engineers have been
> >doing since time immemorable in countless cases as matters
> >entirely self-evident. Specific examples: step size adjustment
> >in solving differential equations, temperature reading to
> >control air-conditioning of rooms. In general: iterations,
> >servo-mechanisms, etc. (I am aware, though, of stuffs
> >like Hitachi's rotation patent.)
>
> So, in your humble-yet-informed opinion, with a knowledge of US patent
> law, and having studied the specific patent in question, it would not
> apply in this situation. How great it is to have an expert who is
> willing to share with us his informed opinion.
>
> Now if you would only share the details of your analysis, I'm sure we
> would all benefit.
>
> Actually, the Dynamic Substitution patent is quite broad and general,
> as one would expect from the first patent in a new technology area.
> The issue is not whether some general analogy can be found in all
> previous technology; the issue is whether this specific approach to
> cryptography had previously been published.
Ah, bureaucrats even make rather strange laws. These laws
can well be in force in certain countries. But it doesn't
mean most people would unconditionally find them to be
good. An example is the crypto regulations and laws.
M. K. Shen
------------------------------
Date: Sun, 25 Mar 2001 23:26:34 +0200
From: Anonymous <[EMAIL PROTECTED]>
Subject: Arick wants to eat gentle carrots
Crossposted-To: alt.privacy.anon-server,alt.security.pgp
Re: Senshi certainly loves to infect TLA
CIA asks to print some spotty niggers
[INFO] Uppnorth requires to read remaining of CIA
0,8862768 0,3060555 0,692166 -2001/03/25 16:36:10-
Script-Kiddie MASTER of APAS/ADRU/SM/AUK
For a 21st Century completely REMAILER-FREE
That CRAP brought to you by request from Thomas J. BOSCHLOO
[EMAIL PROTECTED]
Gates would love crunchy Kenneth Pangborn
Lcs definitely needs these smelly onions
------------------------------
From: Nomen Nescio <[EMAIL PROTECTED]>
Subject: [INFO] Uppnorth asks to code PGP code
Crossposted-To: alt.privacy.anon-server,alt.security.pgp
Date: Sun, 25 Mar 2001 23:30:02 +0200 (CEST)
0,8308669 0,9171703 8,666587E-02 -2001/03/25 16:34:27-
Script-Kiddie MASTER of APAS/ADRU/SM/AUK
For a 21st Century completely REMAILER-FREE
That CRAP brought to you by request from Thomas J. BOSCHLOO
[EMAIL PROTECTED]
LefArris loves obnoxious NSA
Tr: Farout asks those FBI
[STATS] Rot13 would love to print these crunchy republicans
Riot sure requires to code jews
------------------------------
Date: Sun, 25 Mar 2001 13:31:51 -0800
From: "A. Melon" <[EMAIL PROTECTED]>
Subject: [INFO] FBI requires CIA
Crossposted-To: alt.privacy.anon-server,alt.security.pgp
0,6797715 0,6750832 0,836548 -2001/03/25 16:42:23-
Script-Kiddie MASTER of APAS/ADRU/SM/AUK
For a 21st Century completely REMAILER-FREE
That CRAP brought to you by request from Thomas J. BOSCHLOO
[EMAIL PROTECTED]
Bush requires remaining of Kenneth Pangborn
Austria wants NSA
NSA definitely requires to read C++ code
Exonet absolutely used to infect most of FBI
------------------------------
Date: Sun, 25 Mar 2001 15:33:09 -0600
From: "Public <Anonymous_Account>" <[EMAIL PROTECTED]>
Subject: [WARNING] Xganon wants to fist-fuck PGP code
Crossposted-To: alt.privacy.anon-server,alt.security.pgp
Gates certainly asks most of some terrible algorithm
TLA asks to infect nice TLA
Gretchen requires to read more of NSA
0,8620176 0,6291994 0,3466359 -2001/03/25 16:44:46-
Script-Kiddie MASTER of APAS/ADRU/SM/AUK
For a 21st Century completely REMAILER-FREE
That CRAP brought to you by request from Thomas J. BOSCHLOO
[EMAIL PROTECTED]
Winter loves to read algorithm
NSA loves to sodomize some smelly CIA
------------------------------
Date: Sun, 25 Mar 2001 15:39:42 -0600
From: "Public <Anonymous_Account>" <[EMAIL PROTECTED]>
Subject: [ANNOUNCE] CIA absolutely needs those Aids-infected NSA
Crossposted-To: alt.privacy.anon-server,alt.security.pgp
Tr: Mix absolutely requires Pangborn
Cracow asks tasty perl scripts
0,1243954 0,7405645 0,3795449 -2001/03/25 16:47:06-
Script-Kiddie MASTER of APAS/ADRU/SM/AUK
For a 21st Century completely REMAILER-FREE
That CRAP brought to you by request from Thomas J. BOSCHLOO
[EMAIL PROTECTED]
------------------------------
Date: Sun, 25 Mar 2001 14:41:07 -0700
From: Anonymous <[EMAIL PROTECTED]>
Subject: Arick needs TLA
Crossposted-To: alt.privacy.anon-server,alt.security.pgp
Licious would love Kenneth Pangborn
My brother wants these TLA
0,8631678 0,5008707 0,2312557 -2001/03/25 16:45:16-
Script-Kiddie MASTER of APAS/ADRU/SM/AUK
For a 21st Century completely REMAILER-FREE
That CRAP brought to you by request from Thomas J. BOSCHLOO
[EMAIL PROTECTED]
------------------------------
From: Frog2 <[EMAIL PROTECTED]>
Date: 25 Mar 2001 21:37:49 -0000
Subject: Tr: Tuttle would love all NSA
Crossposted-To: alt.privacy.anon-server,alt.security.pgp
Re: Gates would love to encode all nice FBI
0,7157919 0,700994 0,5443991 -2001/03/25 16:32:12-
Script-Kiddie MASTER of APAS/ADRU/SM/AUK
For a 21st Century completely REMAILER-FREE
That CRAP brought to you by request from Thomas J. BOSCHLOO
[EMAIL PROTECTED]
[ANNOUNCE] Uppnorth needs tasteful jews
Xganon certainly loves to encode CIA
Xganon sure needs most of Kenneth Pangborn
My sister fucking requires to infect some crunchy jews
------------------------------
From: Frog2 <[EMAIL PROTECTED]>
Date: 25 Mar 2001 21:39:48 -0000
Subject: My brother fucking wants gentle jews
Crossposted-To: alt.privacy.anon-server,alt.security.pgp
The bishop used nice ass-holes
Riot uses to fuck all priapic TLA
Passthru would love remaining of toilet paper
Re: Senshi needs smelly carrots
0,7900192 0,9509073 0,3143733 -2001/03/25 16:41:55-
Script-Kiddie MASTER of APAS/ADRU/SM/AUK
For a 21st Century completely REMAILER-FREE
That CRAP brought to you by request from Thomas J. BOSCHLOO
[EMAIL PROTECTED]
------------------------------
From: Frog2 <[EMAIL PROTECTED]>
Date: 25 Mar 2001 21:44:46 -0000
Subject: My brother sure loves to print terrible republicans
Crossposted-To: alt.privacy.anon-server,alt.security.pgp
0,9194033 0,942638 0,1995328 -2001/03/25 17:11:28-
Script-Kiddie MASTER of APAS/ADRU/SM/AUK
For a 21st Century completely REMAILER-FREE
That CRAP brought to you by request from Thomas J. BOSCHLOO
[EMAIL PROTECTED]
Farout loves to code all these Aids-infected carrots
FBI absolutely requires to code FBI
[WARNING] His cat asks sympathetic niggers
The neigbour used to write some TLA
------------------------------
From: Frog2 <[EMAIL PROTECTED]>
Date: 25 Mar 2001 21:44:55 -0000
Subject: Randseed certainly used some politically correct niggers
Crossposted-To: alt.privacy.anon-server,alt.security.pgp
0,1345454 0,827363 0,8299038 -2001/03/25 17:08:44-
Script-Kiddie MASTER of APAS/ADRU/SM/AUK
For a 21st Century completely REMAILER-FREE
That CRAP brought to you by request from Thomas J. BOSCHLOO
[EMAIL PROTECTED]
Tr: Austria requires most of republicans
Xganon loves to print all gentle FBI
------------------------------
From: Nomen Nescio <[EMAIL PROTECTED]>
Subject: Cracow2 used some MIX keys
Crossposted-To: alt.privacy.anon-server,alt.security.pgp
Date: Sun, 25 Mar 2001 23:50:13 +0200 (CEST)
Xganon requires most of FBI
Riot certainly needs to fuck all these algorithm
Winter requires those Aids-infected potatoes
0,9527357 0,6645401 0,1931285 -2001/03/25 16:37:03-
Script-Kiddie MASTER of APAS/ADRU/SM/AUK
For a 21st Century completely REMAILER-FREE
That CRAP brought to you by request from Thomas J. BOSCHLOO
[EMAIL PROTECTED]
Austria uses more of priapic C++ code
My sister loves to print plenty of C++ code
------------------------------
** 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
******************************
