Cryptography-Digest Digest #874, Volume #11 Sat, 27 May 00 21:13:01 EDT
Contents:
Re: Anti-Evidence Eliminator messages, have they reached a burn-out po
(Joe@Joe's.bar&grill.org)
Re: Another sci.crypt Cipher (Mark Wooding)
Re: Another possible 3DES mode. (zapzing)
Re: Another possible 3DES mode. (zapzing)
Re: Another sci.crypt Cipher (tomstd)
Self Shrinking LFSR (tomstd)
Re: Anti-Evidence Eliminator messages, have they reached a burn-out po (Griffin)
Re: Another sci.crypt Cipher (Mark Wooding)
----------------------------------------------------------------------------
From: Joe@Joe's.bar&grill.org
Crossposted-To: alt.privacy,alt.privacy.anon-server,alt.security.pgp
Subject: Re: Anti-Evidence Eliminator messages, have they reached a burn-out po
Date: Sun, 28 May 2000 00:01:08 +0100
On Sat, 27 May 2000 22:15:07 GMT, [EMAIL PROTECTED] (Steve) wrote:
>On Sat, 27 May 2000 17:38:32 +0100, Joe@Joe's.bar&grill.org
>wrote:
>
>>And exactly how are they to defend themselves against the constant
>>barrage of lies regarding their software? If they do not defend
>>themselves, the lies will become truth in the minds of most.
>
>Every EE thread I've seen for weeks now has been started by EE
>spam.
Get real! They reply to scurrilous attacks. Unless you wish to claim
that they themselves are "planting" these attacks.
>The only "lies" I have seen have been EE claims that their
>stuff defeats forensic software "costing thousands of dollars",
>followed by a consistent refusal to name the software they
>tested it against.
>
They have repeatedly told people to download the forensic ware and see
for themselves. I personally have not seen one reply where their
detractors have tried forensic methods on EE and said it failed the
test. As usual on Usenet, it's easier to shoot off your mouth than to
produce real proof.
>Fake controversy calculated to draw attention is all I see in the
>EE threads.
Oh, then you DO accuse them of planting these attacks on themselves.
> That, and a couple of people who had their system
>registy eaten by an early, buggy version of EE,
This could have been the result of many other pieces of software on
their machines. Windows itself is the buggiest piece of crap in the
world.
> and a bunch of people pissed off at EE for spamming.
>
Defending themselves against mean spirited agendists such as you is
NOT spam.
>>Make no mistake about it -- some people are out to deliberately
>>destroy this product. EE is not merely indulging themselves in the
>>art of spamming. I think they are fighting for their corporate life.
>
>If they are fighting for their corporate lives, it is because
>they shoot themselves in the foot every time they fire up a news
>reader and say, "oh goody free advertising, that's what
>newsgroups are for".
>
>Which reminds me to mention:
>
>Eraser does 99% of the job EE does, for free, without added
>system overhead.
Eraser is an overly complicated technoid's toy, worthless and
dangerous in the hands of the naive. Naive meaning most of us who
don't give a rat's behind how things are done as long as they are done
and done right. Eraser's Help section is a technnoid's delight, but a
laymen's nightmare. Not all of us give a fig about registry streams,
let alone know that they even exist. This is one reason EE shines.
Their Help section is a delight in clarity. Their program knows what
has to be done and does it. I don't have to know squat. The latter
is called good marketing. How far would the Web gotten if every thing
was still non gui -- meaning DOS or UNIX?
> Just add any files and directories you consider
>sensitive to the task list, and choose whether to wipe them on
>schedule or on demand. http://www.tolvanen.com/eraser/
>
Yeah, right. Like some of us even knew or cared that a RECENT
directory even existed.
>Remember, a dollar spent with EE, is a vote for spam in
>newsgroups.
>
A dollar spent for EE is a vote for individual freedom of thought and
the right to privacy.
>
>>I bought it awhile back and use it everyday. I think it's one the
>>most indispensable pieces of software I own.
>>
>>Did it ever occur to you that maybe some of EE's chief detractors wear
>>badges?lll
>
>If you have a real reason to worry about people who wear badges,
>you better start worrying about your ISP logging all your
>internet traffic, and handing over your archived e-mail
>(typically four to six months of it), both of which are routinely
>done by most ISPs at the request of any officer of the court.
>You should also worry about packet sniffers, keyloggers, remote
>administration tools, and BTW check your network and file share
>settings.
>
There are some thing one can cure; there are other things one has to
live with on the Web. Proxies, encryption, are some of the ways
around many of the problems. The problem really is that the average
Web user is only beginning to find out how vulnerable they are on the
Web. EE is a clear solution in helping them be less so.
>
>Evidence Eliminator does not eliminate evidence, it just
>overwrites files and clears some registry keys.
That's hooey! Your getting really desperate now.
> Any advantage
>this might present in defending a criminal case, is more than
>outweighed by the psychological impact on the jury of the name
>"Evidence Eliminator". If you are counting on it to keep you out
>of jail, be afraid. Be very afraid.
>
Oh, now you offer as "proof" your mind reading ability in regard to
juries? In other words, like the O.J. pack of idiots, all juries
don't listen to "evidence." They simply go on hunches and their gut
feelings. Boy, are we taxpayers wasting money on prosecutors and
evidence. With this knowledge, we can now save ourselves the expense
of the cops having all these forensic labs at their disposal. Who
needs evidence? After all, would a cop lie? Ha! They're the biggest
liars on the face of the earth.
- Joe -
P.S. I think this summer I'll get a T shirt made that says, " I LOVE
my EE"
>:o)
>
>
>Steve
>
>---Support privacy and freedom of speech with---
> http://www.eff.org/ http://www.epic.org/
> http://www.cdt.org/
>
>PGP keys: RSA - 0x4912D5E5 DH/DSS - 0xBFCE18A9
>Both expire 5/15/01
>RSA key available on request
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Another sci.crypt Cipher
Date: 28 May 2000 00:12:37 GMT
tomstd <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Mark Wooding) wrote:
> >Having fixed the problem, I can't find a characteristic for the whole
> >cipher with probability higher than 2^-66.
>
> You mean you can't find 'better or worse' characteristics? I
> would imagine if the probability was higher that you found
> *better* chars.
I can't find a more probable characteristic than 2^-66. This is good
from your point of view.
> >That said, there are a number of 13-round characteristics which are
> >looking dangerous. [...] Both lead to 13-round characteristics with
> >probability 2^-54.
>
> I am missing something, you noted three rounds in the char, but
> say it is a 13r char for the entire cipher? How does that
> work? Is it just a 3r char repeated thru 13r?
If you repeat the characteristic 4 times, you get 12 rounds with p =
2^-48. Sticking one extra round on brings the total to 13 with p =
2^-54.
> >David Wagner pointed out to me that looking at differentials rather
> >than characteristics might be profitable. While there are multiple
> >paths for some differentials, the others tend to have sufficiently
> >much lower probabilities as to not be worthwhile.
>
> What is the "difference" (excuse the wordage) between a
> characteristic and differential?
A differential specifies just an input and output difference between two
points in the evolution of the cipher. A characteristic describes all
of the intermediate differences too. The probability of a
characteristic provides a lower bound on the differential probability.
See, for example, Knudsen's analysis of RC2.
> So you basically tried random bit patterns and observed the
> output difference?
No.
* An output difference with low Hamming weight may only activate one
S-box in the next round. The lower the Hamming weight the more
likely this is; with single-bit output differences it's certain.
* For each S-box and input difference, find all output differences
which affect only one S-box in the next round, with their
probabilities. Sort these differences, put them in a list, and
index the list by the input S-box and difference.
* Now the work begins. Start with two 32-bit words x and y, such that
(a) at least one of x and y is nonzero, and (b) at most one byte of
each of x and y is nonzero.
* Recursively analyse characteristics from here. If x is zero, we get
a free ride to the next round by swapping x and y. If y is zero,
any output difference is acceptable; otherwise the output difference
of x must affect only the byte of y which is already nonzero. Bump
the probability; if it's too high, we've bust, so try some other
approach. If we've reached the end of the cipher, and the
probability is better than anything else so far, then display the
characteristic in a terse but almost readable format.
I'll mail you my program if you like.
> Here's a question: If I did two convolutions per round say
>
> a = a ^ F(F(b ^ k[...]))
>
> Would the characteristic remain?
Let's try.
Hmm. You lower the probabilities quite a bit. I still have some
13-round characteristics but they have probability 2^-63. For example:
0: 00000000 00000400
1: 00000400 00000000 (04[1] -> 04[1], p = 2/256)
2: 00000400 00000400 (04[1] -> 04[1], p = 2/256)
3: 00000000 00000400
4: 00000400 00000000 (04[1] -> 04[1], p = 2/256)
5: 00000400 00000400 (04[1] -> 04[1], p = 2/256)
6: 00000000 00000400
7: 00000400 00000000 (04[1] -> 04[1], p = 2/256)
8: 00000400 00000400 (04[1] -> 04[1], p = 2/256)
9: 00000000 00000400
10: 00000400 00000000 (04[1] -> 04[1], p = 2/256)
11: 00000400 00000400 (04[1] -> 04[1], p = 2/256)
12: 00000000 00000400
13: 00000400 00000000 (04[1] -> 04[1], p = 2/256)
14: 00000400 00000400
and
0: 00000000 e9000000
1: e9000000 00000000 (e9[3] -> 05[3], p = 4/256)
2: 05000000 e9000000 (05[3] -> 05[3], p = 2/256)
3: ec000000 05000000 (ec[3] -> 05[3], p = 4/256)
4: 00000000 ec000000
5: ec000000 00000000 (ec[3] -> 05[3], p = 4/256)
6: 05000000 ec000000 (05[3] -> 05[3], p = 2/256)
7: e9000000 05000000 (e9[3] -> 05[3], p = 4/256)
8: 00000000 e9000000
9: e9000000 00000000 (e9[3] -> 05[3], p = 4/256)
10: 05000000 e9000000 (05[3] -> 05[3], p = 2/256)
11: ec000000 05000000 (ec[3] -> 05[3], p = 4/256)
12: 00000000 ec000000
13: ec000000 00000000 (ec[3] -> 05[3], p = 4/256)
14: 05000000 ec000000
(This is from a quick hack to my program. I might have got it wrong.)
> Independantly I tried expanding the sboxes so that each of the
> four sboxes occur four times in the output (instead of one) in
> different bit orders... For example one of the 8x32 sboxes may be
>
> a0a1a2a3a4a5a6a7, a7a5a6a4a1a3a2a0, etc..
>
> Then I xor'ed them together, however I found that there was
> still a good input difference (namely (0, 0x00000000c)) with an
> output difference prob 1.
I don't follow exactly what you think you're doing here. It doesn't
sound like a good idea if you've got probability-1 characterics, though!
> The best input-output xor is 8/256 or 2^-5, but your char
> (above) has a probability of 2^-6, so it's not the "best" that
> could be done.
Interestingly, your `worst' characteristics don't point to useful bits
of the rest of the structure.
How did you design the permutation, by the way?
-- [mdw]
------------------------------
From: zapzing <[EMAIL PROTECTED]>
Subject: Re: Another possible 3DES mode.
Date: Sun, 28 May 2000 00:11:10 GMT
In article <8ggrlo$8mg$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (David A. Wagner) wrote:
> In article <8gfo3a$l88$[EMAIL PROTECTED]>, zapzing
<[EMAIL PROTECTED]> wrote:
> > In the faq, the following idea was
> > suggested as a way of accomplishing
> > 3DES on an enlarged block:
> >
> > F(x)=Tran(E(k1,Tran(E(k2,Tran(E(k3,Tran(x)))))))
>
> I believe there are weaknesses in this -- Paul Crowley found
> an especially pretty attack -- and I do not recommend its use.
> See http://www.hedonism.demon.co.uk/paul/crypto/dtdtd.html.
>
I believe that some of the things I proposed
make that attack impossible. For one thing,
every single DES encryption has its own key.
If you have three layers of encryption and
four blocks in a superblock, then there are
twelve keys. You could also make sure all
the transpositions are keyed. I'm not saying
this can't be attacked, just that it would be
pretty difficult, I think. It would of course
depend on the key expansion algorithm you
used. SHA-1 has been suggested as a
replacement for BBS which I proposed, and
that is probably a good idea.
--
If you know about a retail source of
inexpensive DES chips, please let
me know, thanks.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: zapzing <[EMAIL PROTECTED]>
Subject: Re: Another possible 3DES mode.
Date: Sun, 28 May 2000 00:15:19 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>
> zapzing wrote:
>
> > In this implementation three keys are used.
> > But I was thinking, what if a key expansion
> > algorithm was used and each individual DES
> > encryption had its own unique key. For example
> > if the enlarged block consisted of 32 bytes,
> > then there would be 12 DES encryptions to
> > encrypt the large block. What if each of those
> > 12 encryptions had its own key?
>
> I proposed sometime back in this group to use variable keys
> for block ciphers, i.e. different keys for different blocks (or sets
> of blocks, should that be more preferable). That obviates a certain
> number of much researched and published techniques of attack
> that rely on the availability of large amounts of materials processed
> with the same key.
Rekeying would be another pssibility, but some
chips don't like to be rekeyed, takes a long
time. Not that it's a bad idea, I think that
we should give cryptanalysts as much to do
as possible.
--
If you know about a retail source of
inexpensive DES chips, please let
me know, thanks.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Subject: Re: Another sci.crypt Cipher
From: tomstd <[EMAIL PROTECTED]>
Date: Sat, 27 May 2000 17:39:56 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Mark Wooding) wrote:
>tomstd <[EMAIL PROTECTED]> wrote:
>> [EMAIL PROTECTED] (Mark Wooding) wrote:
>> >Having fixed the problem, I can't find a characteristic for
the whole
>> >cipher with probability higher than 2^-66.
>>
>> You mean you can't find 'better or worse' characteristics? I
>> would imagine if the probability was higher that you found
>> *better* chars.
>
>I can't find a more probable characteristic than 2^-66. This
is good
>from your point of view.
Woohoo :-), I just wanted to clear that up.
>> >That said, there are a number of 13-round characteristics
which are
>> >looking dangerous. [...] Both lead to 13-round
characteristics with
>> >probability 2^-54.
>>
>> I am missing something, you noted three rounds in the char,
but
>> say it is a 13r char for the entire cipher? How does that
>> work? Is it just a 3r char repeated thru 13r?
>
>If you repeat the characteristic 4 times, you get 12 rounds
with p =
>2^-48. Sticking one extra round on brings the total to 13 with
p =
>2^-54.
Ok makes sense.
>> >David Wagner pointed out to me that looking at differentials
rather
>> >than characteristics might be profitable. While there are
multiple
>> >paths for some differentials, the others tend to have
sufficiently
>> >much lower probabilities as to not be worthwhile.
>>
>> What is the "difference" (excuse the wordage) between a
>> characteristic and differential?
>
>A differential specifies just an input and output difference
between two
>points in the evolution of the cipher. A characteristic
describes all
>of the intermediate differences too. The probability of a
>characteristic provides a lower bound on the differential
probability.
>See, for example, Knudsen's analysis of RC2.
Hmm, where can I find that? Is that in the FSE-RC2 that floats
around?
>> So you basically tried random bit patterns and observed the
>> output difference?
>
>No.
>
> * An output difference with low Hamming weight may only
activate one
> S-box in the next round. The lower the Hamming weight the
more
> likely this is; with single-bit output differences it's
certain.
Gotcha so far.
> * For each S-box and input difference, find all output
differences
> which affect only one S-box in the next round, with their
> probabilities. Sort these differences, put them in a list,
and
> index the list by the input S-box and difference.
So you grab the input differences from step #1 then feed it
through all possible output differences to find output
differences with low hw?
> * Now the work begins. Start with two 32-bit words x and y,
such that
> (a) at least one of x and y is nonzero, and (b) at most one
byte of
> each of x and y is nonzero.
>
> * Recursively analyse characteristics from here. If x is
zero, we get
> a free ride to the next round by swapping x and y. If y is
zero,
> any output difference is acceptable; otherwise the output
difference
> of x must affect only the byte of y which is already
nonzero. Bump
> the probability; if it's too high, we've bust, so try some
other
> approach. If we've reached the end of the cipher, and the
> probability is better than anything else so far, then
display the
> characteristic in a terse but almost readable format.
Hmm... I will have to let this osmosify into my brain.
>I'll mail you my program if you like.
See below.
>> Here's a question: If I did two convolutions per round say
>>
>> a = a ^ F(F(b ^ k[...]))
>>
>> Would the characteristic remain?
>
>Let's try.
>
>Hmm. You lower the probabilities quite a bit. I still have
some
>13-round characteristics but they have probability 2^-63. For
example:
2^-63 is better then the single composition isn't it?
> 0: 00000000 00000400
> 1: 00000400 00000000 (04[1] -> 04[1], p = 2/256)
> 2: 00000400 00000400 (04[1] -> 04[1], p = 2/256)
> 3: 00000000 00000400
> 4: 00000400 00000000 (04[1] -> 04[1], p = 2/256)
> 5: 00000400 00000400 (04[1] -> 04[1], p = 2/256)
> 6: 00000000 00000400
> 7: 00000400 00000000 (04[1] -> 04[1], p = 2/256)
> 8: 00000400 00000400 (04[1] -> 04[1], p = 2/256)
> 9: 00000000 00000400
>10: 00000400 00000000 (04[1] -> 04[1], p = 2/256)
>11: 00000400 00000400 (04[1] -> 04[1], p = 2/256)
>12: 00000000 00000400
>13: 00000400 00000000 (04[1] -> 04[1], p = 2/256)
>14: 00000400 00000400
>
>and
>
> 0: 00000000 e9000000
> 1: e9000000 00000000 (e9[3] -> 05[3], p = 4/256)
> 2: 05000000 e9000000 (05[3] -> 05[3], p = 2/256)
> 3: ec000000 05000000 (ec[3] -> 05[3], p = 4/256)
> 4: 00000000 ec000000
> 5: ec000000 00000000 (ec[3] -> 05[3], p = 4/256)
> 6: 05000000 ec000000 (05[3] -> 05[3], p = 2/256)
> 7: e9000000 05000000 (e9[3] -> 05[3], p = 4/256)
> 8: 00000000 e9000000
> 9: e9000000 00000000 (e9[3] -> 05[3], p = 4/256)
>10: 05000000 e9000000 (05[3] -> 05[3], p = 2/256)
>11: ec000000 05000000 (ec[3] -> 05[3], p = 4/256)
>12: 00000000 ec000000
>13: ec000000 00000000 (ec[3] -> 05[3], p = 4/256)
>14: 05000000 ec000000
>
>(This is from a quick hack to my program. I might have got it
wrong.)
Just change the F function... :-)
>> Independantly I tried expanding the sboxes so that each of the
>> four sboxes occur four times in the output (instead of one) in
>> different bit orders... For example one of the 8x32 sboxes
may be
>>
>> a0a1a2a3a4a5a6a7, a7a5a6a4a1a3a2a0, etc..
>>
>> Then I xor'ed them together, however I found that there was
>> still a good input difference (namely (0, 0x00000000c)) with
an
>> output difference prob 1.
>
>I don't follow exactly what you think you're doing here. It
doesn't
>sound like a good idea if you've got probability-1
characterics, though!
What I was trying todo is for each 8x32 sbox I would take one
8x8 sbox. Then I would spread the output of the 8x8 sbox over
the 32 bit space. I.e by duplicating each output of the 8x8
four times. I would mix them up so they wouldn't appear in the
same order in each of the four output bytes.
It turns out to be no better, simply because I am using the same
low hw permutation. I think... er...
>> The best input-output xor is 8/256 or 2^-5, but your char
>> (above) has a probability of 2^-6, so it's not the "best" that
>> could be done.
>
>Interestingly, your `worst' characteristics don't point to
useful bits
>of the rest of the structure.
>
>How did you design the permutation, by the way?
You can find my code to make the permutation right here
http://www.tomstdenis.com/perm.c
It's a dirty hack but it does the job. It makes random
permutations then checks to see if only two bits per byte goto
another byte. Then I precompute the sbox and output it.
BTW you can email your source to [EMAIL PROTECTED] I think if I
see what you are doing it will help.
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: Self Shrinking LFSR
From: tomstd <[EMAIL PROTECTED]>
Date: Sat, 27 May 2000 17:41:49 -0700
At http://www.tomstdenis.com/slfsr.c I have my implementation
of a self-shrinking semi-dense 64 bit LFSR. The code is really
compact, doesn't require any keysetup :)
It outputs about 8mbit/sec on my K6 as compiled by DJGPP.
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: Griffin <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy,alt.privacy.anon-server,alt.security.pgp
Subject: Re: Anti-Evidence Eliminator messages, have they reached a burn-out po
Date: Sat, 27 May 2000 18:46:11 -0500
On Sat, 27 May 2000 17:38:32 +0100, Joe@Joe's.bar&grill.org wrote:
>And exactly how are they to defend themselves against
>the constant barrage of lies regarding their software? If
>they do not defend themselves, the lies will become
>truth in the minds of most.
Hundreds of security products on the internet and EE's the only one
that some sinister force is "trying to destroy".
<SARCASM>
Must be because it's so good someone's quaking in their shoes. huh?
</SARCASM>
Nobody has to attack the product to make it look bad. EE Support's
smart-ass trolls have done more to harm the program's reputation than
the CIA could ever hope for.
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Another sci.crypt Cipher
Date: 28 May 2000 00:59:21 GMT
tomstd <[EMAIL PROTECTED]> wrote:
> Hmm, where can I find that? Is that in the FSE-RC2 that floats
> around?
In his web pages seems like the best place to look. I think it was
there that I found it.
> So you grab the input differences from step #1 then feed it through
> all possible output differences to find output differences with low
> hw?
I grind through each of your permuted S-boxes (the one you supplied with
your C source) and check to see if the output difference is contained
exactly within one byte. If it is then I remember it; otherwise it's
rejected. In my final structure, for each S-box and input difference
there's a linked list, sorted in descending probability order, of nodes
containing the output target S-box, the difference in that S-box, and
the probability of the characteristic. For the busting logic, there's
also an approximation of -10000 * log_2(p), because log_2(6/256) isn't a
nice number.
It may be that it's a win to have more than one S-box active in one
round, because it lets you use higher-probability characteristics in
other rounds. That starts getting too complex to analyse simply,
though.
> Just change the F function... :-)
I wasn't actually using your F function before. I do now, and I just
applied it twice.
> It's a dirty hack but it does the job. It makes random permutations
> then checks to see if only two bits per byte goto another byte. Then
> I precompute the sbox and output it.
I think that, at the very least, you need to choose your permutation to
limit the damage of low Hamming-weight output differences. Also, you
could optimize your S-box so that low weight output differences were
less probable than ones with high weight -- that'd help. I think that
David Wagner's suggestion of an MDS matrix multiply is a better idea,
though. It wouldn't quite be Onefish since the S-box isn't key-
dependent, but it'd certainly give you better diffusion than a simple
bit-permutation.
> BTW you can email your source to [EMAIL PROTECTED] I think if I
> see what you are doing it will help.
I've done that. By the way, it's not secret or anything, so if anyone
else wants it you can just ask me. Oh, it's not very pretty or well-
commented: I wrote it during a lunch break.
-- [mdw]
------------------------------
** 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
******************************
