Cryptography-Digest Digest #302, Volume #14 Sun, 6 May 01 12:13:00 EDT
Contents:
Re: Tiny s-boxes (Tim Tyler)
Re: LUCIFER ("Tom St Denis")
Re: Cryptanalysis Question: Determing The Algorithm? ("Tom St Denis")
Re: Best encrypting algoritme ("Tom St Denis")
Re: Tiny s-boxes ("Tom St Denis")
Re: LUCIFER (Tim Tyler)
Re: LUCIFER (John Savard)
Re: LUCIFER ("Tom St Denis")
My algorithm and problem. ([EMAIL PROTECTED])
Re: Tiny s-boxes ("Henrick Hellstr�m")
Re: My algorithm and problem. ("Tom St Denis")
Re: Note on combining PRNGs with the method of Wichmann and Hill (David Hopwood)
Re: Comp Results: Thomas Boschloo FAILS to prove himself, as everyone expected all
along... (Stop Boschloo posting diarrhea)
Re: Stretching and strengthening (Re: A practical idea to reinforce (David Hopwood)
----------------------------------------------------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Tiny s-boxes
Reply-To: [EMAIL PROTECTED]
Date: Sun, 6 May 2001 14:24:38 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
: "Tim Tyler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
:> Tom St Denis <[EMAIL PROTECTED]> wrote:
:> : "Tim Tyler" <[EMAIL PROTECTED]> wrote in message
: If you're round function is a random 32x32 I would bet nobody can crack
: your cipher. On the other hand nobody can *use* your cipher. I've
: mentioned DES but also Serpent and ICE are two others ciphers that
: wouldn't be ideal with random boxes.
Well, their s-boxes are not "large". This stuff about random s-boxes only
applies as the size of the s-box becomes large.
:> To be honest I haven't yet investigated in any depth how best to
:> implement tiny s-boxes in software.
: Generally in software you group the bits. I.e two 4x4's into one 8x8 etc...
Yuck ;-) If someone told me that I had to do things like that then I
reckon I would be hard-pressed to make a case for using small s-boxes.
:> : If you want some ideal ciphers with small sboxes look at Square,
:> : Rijndael, Twofish, DES, Serpent...
:>
:> I think your idea of "small" must include 8x8 boxes...
: To me 8x8's are small.
Personally, I'm calling 4x4 "small" and 3x3 "tiny". You can get
quite respactable non-linearity in an 8x8 s-box, and don't need
to rely so much on iteration to produce confusion - but you may
well be right in that - as s-boxes go - 8x8 ones /are/ at the small
end of the spectrum.
[snip algebraic s-boxes]
:> : You're right that small (i.e 4x4 => 8x8) sboxes should be used more
:> : often then larger ones [...]
:>
:> Well, as far as I understand it, this isn't terribly widely accepted.
: How so? Twofish, Serpent, Rijndael, DES, GOST, SAFER, etc... are all
: ciphers using 4x4 to 8x8 sized transforms.
Well, you're right - though AFAICS relatively few cyphers go down to 4x4,
there are quite a number that use 8x8 boxes.
Then we have things like Ralph Merkle saying things like "The S-boxes in
DES are small [...]. Now that memory is larger, s-boxes should grow."
[Khufu/Khafre design criteria].
LOKI has 12x8-bit s-box. Blowfish and CAST have 8x32-bit s-boxes.
IDEA has a sort-of 16x16 bit algebraic s-box. *If* small is beautiful,
there are certainly designers out there who think otherwise.
--
__________ http://rockz.co.uk/ http://alife.co.uk/ http://hex.org.uk/
|im |yler http://atoms.org.uk/ http://mandala.co.uk/ [EMAIL PROTECTED]
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: LUCIFER
Date: Sun, 06 May 2001 14:54:08 GMT
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> However an encryption program can get along on 32 bits.
> as a sub unit if they are not directly visable to the out side.
> I think scott19u with its use of 19bit blocks is orders of magnitude
> more secure than any to the 5 finailists in AES. But then they are
> forced to use fast small keyed programs. So the NSA can still stay
> on top of things.
Why do you think this? What breaks do you have on AES?
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Cryptanalysis Question: Determing The Algorithm?
Date: Sun, 06 May 2001 14:59:37 GMT
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] (Tom St Denis) wrote in
> <mAbJ6.26992$[EMAIL PROTECTED]>:
>
>
> Appearently you could not follow the thread and
> the concept is above you. I had hoped your still young
> enough to use your brain a little but I see thats
> a little to much to hope for.
What thread? You have never explained your "non-blind search" method?
Sometimes I swear you're just trying to get a rise out of people.
> >I bet you can't and won't and you will go on a wild tangent about how
much
> >BICOM is better. (please prove me wrong here!)
>
> No little boy I will not mentioned it in my response to you
> obviously the concepts in it are far over your head.
What concepts? You have only done hand waving and insults so far. You have
to prove anything.
> So I will
> stop playing your childish games.
You're not one to talk.
> If you want to learn something
> about bijective compression encyrption systems let me know.
Yeah I tried to ask but I got this as a reply. You have yet to show that
your method is any better. Just conjecture and insults do not constitute a
proof of security (or insecurity in the case of non-bijective systems).
> and as you can see I proved you wrong again.
How so? By asking you to back up your claims with math? Oops.
> I will not tell
> you how much better a certain product is.
Because you honestly don't know. Admit it you have no clue whether your
conjectures have any basis in reality or not.
>It would be like telling
> a 5 year old and accomplish the same results. You seem incapable
> of staying on thread and fly off on wild tangents.
What the heck. This whole thread is about you showing us how todo a key
search other than thru a blind search.
>I can descibe
> simple systems based on 2 bit keys and such. I don't have the time
> or money to expand the concpets up to keys of more than a few bits.
Well I can show how a 2-bit cipher is insecure too. You have claimed that
AES is weak unless bijective encodings are used. Prove your claim.
> If you thinkg the NSA doesn't your a bigger fool than I thought,
Why do you keep brining the NSA into this? Public cryptanalysis is fairly
state of the art as compared to 30 years ago. Just because your a laymen
(like me) doesn't mean everyone else is!
> If you think that problems explained with small keys sytems don't
> apply to large systems unless you see a break before your eyes we
> are just wasting time writting to each other.
Well you have yet to show an attack on AES (or any cipher for that matter)
faster than a blind search (assuming not enough texts are available for some
iterrative shortcut attack).
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Best encrypting algoritme
Date: Sun, 06 May 2001 15:05:04 GMT
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] (Tom St Denis) wrote in
> <1UbJ6.27172$[EMAIL PROTECTED]>:
>
> >
> >"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
> >news:[EMAIL PROTECTED]...
> >> [EMAIL PROTECTED] (Tom St Denis) wrote in
> >> <BR4J6.25523$[EMAIL PROTECTED]>:
> >>
> >> >
> >> >I still don't get your main points. If the system is a FSM (Finite
> >> >State Machine) such as any computer program (they must be finite)
> >> >then there are only a *finite* amount of states the program can be
> >> >in. This means that no matter what you do, if it's a FSM then I can
> >> >write a program to brute force it. There is no way to escape this
> >> >logic. You can only make brute force impractical (i.e huge key, or
> >> >something to that effect).
> >>
> >> Tom what you lack and refuse to learn or even seem to engage your
> >> brain is. I could write a cyrpto system with even a 1 byte block
> >> size. and 2 bits of key space. Lets say I take my messages I don't
> >> have many but I compress them done using bijective compression.
> >> and then encrypt that bijectively compressed message with a 2 bit
> >> key using bijective encryption.If you write a super duper brute force
> >> machine you may get all of the 4 message I may of sent. There may have
> >been
> >> 407 messages. You have reduced it to 4. Know which message is it.
> >> The four are all equally likely.
> >
> >Yeah but you can't break a real cipher even in ECB mode with a single
> >block. If you gave me say 15, 1-byte blocks with this 2-bit key I could
> >figure out what the key is. No matter what you do.
>
> Actaully Tom we are in the bar room betting area. If you
> can find a trusted person by both of us. I will write a cyrpto
> system then use a bijective type of compression encryption system.
> to map a message to at least 15 bytes. You then have a one in four
> chance of winning money. How about 20 dollars. I don't like barroom
> bets unless I have the odds in my favor.
I will bet 1000 dollars that with a 2-bit key and a 15-byte message I could
find the real key 100% of the time. Assuming the message is infact english.
Let's change this around.
I bet that with under 1000 known pairs (i.e a 8kb text message) I could
break RC5 with a 32 bit key in under a day even if a bijective mode is used.
Simply look at the digraph, trigraph sets of the plaintexts to see if it
follows an english distribution. I then wade thru the keys remaining with
stricter rules.
For example in your system perhaps all ascii outputs will arise from all
2^32 keys. But not all keys will decrypt 8kb of text with the proper
digraphs (i.e th is more frequent then tz or tp or ta, etc...)
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Tiny s-boxes
Date: Sun, 06 May 2001 15:13:15 GMT
"Tim Tyler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> : "Tim Tyler" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> :> Tom St Denis <[EMAIL PROTECTED]> wrote:
> :> : "Tim Tyler" <[EMAIL PROTECTED]> wrote in message
>
> : If you're round function is a random 32x32 I would bet nobody can crack
> : your cipher. On the other hand nobody can *use* your cipher. I've
> : mentioned DES but also Serpent and ICE are two others ciphers that
> : wouldn't be ideal with random boxes.
>
> Well, their s-boxes are not "large". This stuff about random s-boxes only
> applies as the size of the s-box becomes large.
Ah ok.
>
> :> To be honest I haven't yet investigated in any depth how best to
> :> implement tiny s-boxes in software.
>
> : Generally in software you group the bits. I.e two 4x4's into one 8x8
etc...
>
> Yuck ;-) If someone told me that I had to do things like that then I
> reckon I would be hard-pressed to make a case for using small s-boxes.
No, it's flexibility. In GOST for example the 4x4's are ideal for hardware
and embedded platforms. In software you can compute the entire round
function with four 8x32 lookups and three OR's. That's fast.
> :> : If you want some ideal ciphers with small sboxes look at Square,
> :> : Rijndael, Twofish, DES, Serpent...
> :>
> :> I think your idea of "small" must include 8x8 boxes...
>
> : To me 8x8's are small.
>
> Personally, I'm calling 4x4 "small" and 3x3 "tiny". You can get
> quite respactable non-linearity in an 8x8 s-box, and don't need
> to rely so much on iteration to produce confusion - but you may
> well be right in that - as s-boxes go - 8x8 ones /are/ at the small
> end of the spectrum.
Random 8x8's are hardly every ideally confusing. The average sbox has a
DPmax of 16/256 and a LPmax of 36/256 compared to the best 4/256 and 16/256
respectively. There are better designs.
For example, in GF(2^8) you can make 255 family sboxes from doing F(x) =
(ax)^-1 mod p, where a is != 0. Each of these sboxes has the same LP and DP
maximums but are different in their orderings. In fact you can make
(255)(256)=65280 new 8x8's by decorrelating the input completely via F(x) =
(ax + b)^1 mod p, a!= 0. That's nonlinear and decorrelated :-) Better yet
though is that you can precompute these if need be or compute them on the
fly using about 9 GF mults and an xor operation. That would be slow but the
sbox would be very ideal and you could use the pair (a,b) as a round key of
some sort or something.
> [snip algebraic s-boxes]
>
> :> : You're right that small (i.e 4x4 => 8x8) sboxes should be used more
> :> : often then larger ones [...]
> :>
> :> Well, as far as I understand it, this isn't terribly widely accepted.
>
> : How so? Twofish, Serpent, Rijndael, DES, GOST, SAFER, etc... are all
> : ciphers using 4x4 to 8x8 sized transforms.
>
> Well, you're right - though AFAICS relatively few cyphers go down to 4x4,
> there are quite a number that use 8x8 boxes.
Serpent and GOST use 4x4's...
> Then we have things like Ralph Merkle saying things like "The S-boxes in
> DES are small [...]. Now that memory is larger, s-boxes should grow."
> [Khufu/Khafre design criteria].
>
> LOKI has 12x8-bit s-box. Blowfish and CAST have 8x32-bit s-boxes.
> IDEA has a sort-of 16x16 bit algebraic s-box. *If* small is beautiful,
> there are certainly designers out there who think otherwise.
Yes but notice that both LOKI and Blowfish have breaks based on their
non-ideal sboxes. CAST is just a bad cipher allaround ...
Tom
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: LUCIFER
Reply-To: [EMAIL PROTECTED]
Date: Sun, 6 May 2001 15:04:41 GMT
SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
: [EMAIL PROTECTED] (Paul Rubin) wrote in
:>Don Coppersmith described Lucifer briefly in his talk on DES at Crypto
:>2000. It was a 32-bit block cipher with 128-bit keys(?), but I don't
:>remember more. The 32-bit block size is the part that seems amusing now.
: Well unless JS is full of crap. The pointer to his page provided by
: tim says "LUCIFER enciphered blocks of 128 bits, and it used a 128-bit key."
: I don't see that it was a 32 bit block size. [...]
I understand that "LUCIFER" was used to refer to more than one thing.
AC, p.303 describes LUCIFER - and says that Biham and Shamir analysed a
32-bit block size version of LUCIFER - as well as a 128-bit version.
It does not rate the strength of any of the versions of LUCIFER.
--
__________ http://rockz.co.uk/ http://alife.co.uk/ http://hex.org.uk/
|im |yler http://atoms.org.uk/ http://mandala.co.uk/ [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: LUCIFER
Date: Sun, 06 May 2001 15:28:02 GMT
On 6 May 2001 00:10:54 -0800, [EMAIL PROTECTED] (Ryan Sorensen) wrote,
in part:
>I would appreciate it if someone could point me to a paper outlining LUCIFER.
>I've read the "Cryptography and Computer Privacy" article, but that wasn't
>directly on LUCIFER.
>If the only way I can find a paper on it, specifically "LUCIFER, A
>Cryptographic Algorithm", is by purchasing the back issue of Cryptologia,
>let me know.
That is the only published paper I know of that includes a full
description of LUCIFER, but there was a paper about the cryptanalysis
of LUCIFER by Eli Biham that described it fairly well.
However, my web site, at
http://home.ecn.ab.ca/~jsavard/crypto/co0401.htm
includes a full, detailed description of the LUCIFER algorithm also.
John Savard
http://home.ecn.ab.ca/~jsavard/
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: LUCIFER
Date: Sun, 06 May 2001 15:26:36 GMT
"Tim Tyler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
> : [EMAIL PROTECTED] (Paul Rubin) wrote in
>
> :>Don Coppersmith described Lucifer briefly in his talk on DES at Crypto
> :>2000. It was a 32-bit block cipher with 128-bit keys(?), but I don't
> :>remember more. The 32-bit block size is the part that seems amusing now.
>
> : Well unless JS is full of crap. The pointer to his page provided by
> : tim says "LUCIFER enciphered blocks of 128 bits, and it used a 128-bit
key."
> : I don't see that it was a 32 bit block size. [...]
>
> I understand that "LUCIFER" was used to refer to more than one thing.
>
> AC, p.303 describes LUCIFER - and says that Biham and Shamir analysed a
> 32-bit block size version of LUCIFER - as well as a 128-bit version.
> It does not rate the strength of any of the versions of LUCIFER.
I believe their "conditional" cryptanalysis can break LUCIFER. At any rate
better designs already exist.
Tom
------------------------------
From: [EMAIL PROTECTED]
Subject: My algorithm and problem.
Date: 6 May 2001 15:16:29 GMT
Hi,
Below is a brief description of my data encryption algorthm(simplified form
here) and my question. Please help to evaluate my algorithm and answer my
question. Thanks.
INPUT:
char Data[10000];
int Password;
(here int means 32 bit int)
OUTPUT:
char SecretData[10000];
Encryption Algorithm:
1. Generate a sequence from the password, which has the same length as the
Data and should has the largest entropy:
for(i=0;i<10000;i++)
Sequence[i]=int(cos(i+Password)*1234567890) mod 256
2. Then "cover" the original data with the Sequence to get the Secret
Data.
for(i=0;i<10000;i++)
SecretData[i]=Data[i]+Sequence[i];
It is that simple. When decrypting, just change the "+" signal to
"-".
And I've tested compressing the SecretData[], no compression utility can
compress it for even a bit. So I think the result is secure.
However, there are two leaks I found in the algorithm described above.
1. If a spy got for example SecretData1[], and SecretData2[], which are
encrypted using the same password, he would be able to get info by
substracting the two sequences.
for(i=0;i<10000;i++)
d[i]=SecretData2[i]-SecretData1[i];
I have already solved this problem. When encrypting a file, add a random
factor to the Password, and save the random factor into the secret file
together. So each time it encrypts a file, the chaos sequences are different
even same password is used.
2.As you see, cos is used in the code, and here lies my questino.
I don't know whether the CPUs ensure everytime it computes cos(a) it will
produce the same results. Will the last digit get unstable? If yes, how to
solve?
Thank you very much for reading my post and best wishes,
Yan.
mailto:[EMAIL PROTECTED]
----- Posted via NewsOne.Net: Free (anonymous) Usenet News via the Web -----
http://newsone.net/ -- Free reading and anonymous posting to 60,000+ groups
NewsOne.Net prohibits users from posting spam. If this or other posts
made through NewsOne.Net violate posting guidelines, email [EMAIL PROTECTED]
------------------------------
From: "Henrick Hellstr�m" <[EMAIL PROTECTED]>
Subject: Re: Tiny s-boxes
Date: Sun, 6 May 2001 17:38:37 +0200
"Tom St Denis" <[EMAIL PROTECTED]> skrev i meddelandet
news:UAaJ6.26797$[EMAIL PROTECTED]...
> It depends on the structure of the cipher. You can't just play the big
> numbers game and wait for someone to show you why!
Exactly.
--
Henrick Hellstr�m [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: My algorithm and problem.
Date: Sun, 06 May 2001 15:46:42 GMT
<[EMAIL PROTECTED]> wrote in message
news:9d3psd$g0q$[EMAIL PROTECTED]...
> Hi,
> Below is a brief description of my data encryption algorthm(simplified
form
> here) and my question. Please help to evaluate my algorithm and answer my
> question. Thanks.
>
> INPUT:
> char Data[10000];
> int Password;
> (here int means 32 bit int)
Right away that's a problem if long term or even modertate term security is
required.
> OUTPUT:
> char SecretData[10000];
>
> Encryption Algorithm:
>
> 1. Generate a sequence from the password, which has the same length as the
> Data and should has the largest entropy:
>
> for(i=0;i<10000;i++)
> Sequence[i]=int(cos(i+Password)*1234567890) mod 256
Again this suffers from several problems. 1234567890 =
(2)*(3)^2*(5)*(3803)*(3607) none of which are 256 in fact 1234567890 mod 256
= 210 which means 210 symbols are more frequent then others. Second you
must ensure that all implementations give the exact same result for cos.
Most will not (to 10 digits perhaps... I dunno) otherwise the stream is
broken.
Also your effect key space is only 2pi anyways. Try cos(i + 2npi) the
cosine is the same for all values of 'n' and fixed 'i'.
So your effective keyspace is only really 0,1,2,3,4,5,6 or 7 values or so.
So it's not a 32-bit key anymore it's a 3-bit key.
<snip>
TOm
------------------------------
Date: Sun, 06 May 2001 16:51:30 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers
Subject: Re: Note on combining PRNGs with the method of Wichmann and Hill
=====BEGIN PGP SIGNED MESSAGE=====
Bryan Olson wrote:
> The modification destroys an important property of
> the basic combination method: as long as the streams
> are independent, if any of the streams are uniform
> then the sum is uniform.
Mok-Kong Shen wrote:
> David Hopwood wrote:
> > We assume that there is *at least one* uniform independent stream.
> > Bryan Olson's point is absolutely correct: it is obvious that the
> > modified Wichmann-Hill scheme, with weights that are not all
> > non-zero integers, does not have the property stated above.
> >
> > (Counter-example: if the only uniform stream has a weight that is not
> > a non-zero integer, then after weighting it is not uniform. If the
> > other streams are also non-uniform, then in general the sum is not
> > uniform either.)
(Note that it was clear from context that "uniform" here, and in
Bryan Olson's post, meant uniform on [0, 1.0).)
> In a rather early follow-up I already mentioned that from
> theory the result is uniform if one of the streams is
> uniform.
That is obviously false. If you want a more concrete counterexample,
consider 1.0*r1 + 0.9*r2, where r1 is always zero and r2 is uniform on
[0, 1.0); clearly the result is the uniform distribution on [0, 0.9)
(and hence not on [0, 1.0) as would be the case if Bryan Olson's
property held).
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOvN6jDkCAxeYt5gVAQFXlwf/Ufg+k9QmuBwcpkSHbCyxsnhnWjRybr4r
VCExW/V+IL+aAeH/VxnTR+KgyjSbaXb9zjMQv8z8WVaT5JpkN/id3Pp8YJM5VmUb
ZrYLqC1BsT0TwkCzhZsjnaFB0G0E6euxr8BfLN77aKx3giZAjG0S0xGS/5n0lgZo
DOKCrGPZ84BhezizRAdkMEjBxHId5Mnrql3eERmGW8jD8MHqzNXcGEHGUIgsIj5p
FZhKNc6Z7flthP3kBFRzhVurZ/10vfjTRl8PTuGbR0DuLerA6deXmDr8m6J4wsYW
Ou5sVwdatUvjPCjBrmVBsIuKY+VY1e5pwQLBKm2n5zGZ+xHyj8a5LQ==
=bRg4
=====END PGP SIGNATURE=====
------------------------------
Date: Sun, 6 May 2001 11:51:10 -0400
Subject: Re: Comp Results: Thomas Boschloo FAILS to prove himself, as everyone
expected all along...
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss,alt.privacy.anon-server
From: Stop Boschloo posting diarrhea <[EMAIL PROTECTED]>
NOTICE: This message may not have been sent by the Sender Name
above. Always use cryptographic digital signatures to verify
the identity of the sender of any usenet post or e-mail.
On Sun, 06 May 2001, "Thomas J. Boschloo" <[EMAIL PROTECTED]> wrote:
Stop Boschloo posting diarrhea
Boschloo STINKS
Boschloo TOO MUCH
Boschloo NO
Boschloo TOO MUCH
Boschloo is a TROLL
Boschloo is a CLOWN
Against Boschloo
Neuter Boschloo
SCREW Boschloo
Stop Boschloo NUTS
Stop Boschloo NONSENSE
Stop Boschloo RAT
Stop Boschloo insanity
Boschloo is a PLAGUE
NONSENSE from Boschloo, as usual,
trying to occupy frontstage with his pretense of knowledge
HISTORY:
That Boschloo bozo is a clown and a troll who has been looming around for nearly a
year.
Don't mistake a "regular" (troll) with a knowledgeable person: that self-proclaimed
"security expert" is not even a remailer user. In the past, he proved himself unable
to check a PGP signature, and got ridicule from every single technical topic he wanted
to talk about.
Besides false or inaccurate or misleading technical misinformation, his posts are
about his avowed mental illness, or for bashing remops or real freedom fighters: he
likes to quarrel with every one, and stir shit. Sometimes, it is even pure delirium
(when he misses his pills?)
One of his last actions was to stage a hoax about his own suicide, just to try to grab
some sympathy, after he had been exposed as a troll and technically incompetent.
The worst being his teasing of Script-Kiddie until it triggered a new flood on apas.
Of course, he refuses to apologize.
Actually, the level of contempt he shows for remailer users:
they don't give their names, while he does
that can't do anything against him, without giving their names
is in no way different from what is displayed by Pangborn, Burnore and the like
Ignore him completely, killfile him, respect others' killfiles
KILLFILE:
To put him in your killfile, put "Author: Boschloo"
That will make disappear both him and people who warn about him
If you want to tell him to buzz off, or warn about him,
use a nickname containing "Boschloo" (Boschloo Hater, Boschloo Sucks,...)
to accomodate such killfile for "regulars", and still warn newbies
COURAGE:
Boschloo is getting _no_ answer from apas any more.
He has to crosspost to various newsgroups to try to grab some attention.
In a few months, it will be gone.
Stop Boschloo diarrhea
Stop Boschloo posting diarrhea
Fight Boschloo
Stop Boschloo MADNESS
Stop Boschloo RAT
Stop Boschloo INSANITY
Stop Boschloo NONSENSE
Stop Boschloo NUTS
Boschloo TOO MUCH
Boschloo is a PLAGUE
SCREW Boschloo
Neuter Boschloo
Boschloo is a CLOWN
Boschloo TOO MUCH
Stop Boschloo posting diarrhea
Boschloo STINKS
Boschloo NO
Boschloo PLAGUE
------------------------------
Date: Sun, 06 May 2001 16:51:57 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Subject: Re: Stretching and strengthening (Re: A practical idea to reinforce
=====BEGIN PGP SIGNED MESSAGE=====
Paul Crowley wrote:
> David Hopwood <[EMAIL PROTECTED]> writes:
>
> > Harald Korneliussen wrote:
> > > My idea is that upon selecting a password, X bits of
> > > random data is added to the password. [...]
> >
> > This is called "key stretching" [...]
> >
> > Another idea that achieves a similar effect by different means
> > is "key strengthening", which is intentionally using a
> > computationally expensive function to derive a key from the
> > password. [...]
> I'm afraid you have these two the wrong way around!
Indeed I did. Thanks for the correction.
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOvRPCzkCAxeYt5gVAQF/fQgAkOk13DVkMrhvybxNbZlXV03qkwbRicqH
h1bSe30LKIZBBnevlzMtOFKoVaRDya4cJOsOR4dH6S7idDmrrm0XxmsAP/xo7vL5
VGX5HIUn0+YouC3exQXx+SxDEqoDZv0JnowBM6ea6864KQHvI8s8ePy1PNSnBkKO
VcZWgkL03L1OZimENNLaFSgyrjj5mEeidpfoqa48gxvK76CXRU11bU0cV/PbkPAW
rBxIreUBw8LOWsOU+2zxt2TkiwbeozMQ95NWqxJ8GK9OZ4UIh6KoIOLOp2QhoJLk
gKsDTtk0EOVyaFQnVt3/r1l5alwllyrqT1Um1B3i26/YpYYuBesp2w==
=cH+v
=====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
******************************
